nicht angemeldet
welche funktion für primärschlüssel
Hallöchen erstmal,
ich hätte gern mal gewusst, welche funktion am besten für einen eineindeutigen primärschlüssel f. die mysql-DB geeignet ist, und wie ich ihn verwende. die time()-funktion ist z.b. für ein einfügen mehrerer Sätze innerhalb einer schleife ungeeignet, da es durchaus zu gleichen schlüsseln kommen kann
danke im voraus
-
Hi,
welche funktion am besten für einen eineindeutigen primärschlüssel f. die mysql-DB geeignet ist,
Datenbank-Funktionen überlässt man am besten der Datenbank. Im Fall von MySQL: auto_increment
und wie ich ihn verwende.
Bei jedem INSERT wird ein neuer, eindeutiger Wert von der Datenbank selbst generiert. Es gibt garantiert keine Verdopplungen (sofern Du die Spalte breit genug definiert hast). Begehe bitte nicht den populären Fehler, etwas anderes in den Werten zu sehen als nur die Eindeutigkeit - jedwede andere Verwendung ist ein Fehler deinerseits.
Bisher beherrscht MySQL übrigens keine Foreign Keys oder anderen Constraints. Das wird ab Version 4.1(?) voraussichtlich anders sein.
Cheatah
-
jo, danke für die zahlreichen infos
-
nochwas:
muss ich dann beim sql befehl das erste feld weglassen?
z.B.
vorher: INSERT INTO t_files VALUES ($id, $name, $size);
danach: INSERT INTO t_files VALUES ($name, $size);
-
nochwas:
muss ich dann beim sql befehl das erste feld weglassen?
z.B.
vorher: INSERT INTO t_files VALUES ($id, $name, $size);
danach: INSERT INTO t_files VALUES ($name, $size);
Hallo Rico,
bei den Datenbanken, die ich kenne, ja (leider weiß ich bei MySQL nicht so Bescheid, würde aber davon ausgehen).
Gruß Frank
-
vorher: INSERT INTO t_files VALUES ($id, $name, $size);
danach: INSERT INTO t_files VALUES ($name, $size);
Das ID-Feld mußt Du schon weglassen, allerdings müßtest Du dann das Statement um die Feldnamen erweitern [1]:
INSERT INTO t_files (name,size) VALUES($name,$size);
(Ohne jetzt die Feldnamen wirklich zu kennen)Grüße
Klaus[1] wobei ich es vorziehe, immer alle Feldnamen ausdrücklich anzugeben. Das erleichtert einerseits die Fehlersuche, andererseits kann des bei Strukturänderungen auch von Vorteil sein.
-
mit dem kleinen nebengeschmack, das sich die sql-befehle dann über 4 zeilen erstrecken, aber grundsätzlich geb ich dir recht.
Also danke nochmal allen für die unterstützung
-
Hallo,
mit dem kleinen nebengeschmack, das sich die sql-befehle dann über 4 zeilen erstrecken, aber grundsätzlich geb ich dir recht.
Ich schreibe meine Statements meist über mehrere Zeilen, ungefähr in der Form:
SELECT
tabelle1.feld1,
tabelle1.feld2,
tabelle1.feld3,
tabelle1.feld4,
tabelle2.feld1,
tabelle2.feld2,
tabelle2.feld3
FROM
tabelle1, tabelle2
WHERE
tabelle1.id = tabelle2.foreignkey
AND
tabelle1.feld5 = 1
AND
tabelle1.feld6 > 1000Dadurhc wird die Struktur besser lesbar, eventuelle Fehler aufgrund DB-Fehlermeldungen wie 'error at line 12' genauer lokalisierbar, und überhaupt besser wartbar.
Grüße
Klaus-
Moin!
Ich schreibe meine Statements meist über mehrere Zeilen, ungefähr in der Form:
Ausgerechnet ein ganz blödes Beispiel nimmst du da. Deine Abfrage macht sich besser so:
SELECT
tabelle1.feld1,
tabelle1.feld2,
tabelle1.feld3,
tabelle1.feld4,
tabelle2.feld1,
tabelle2.feld2,
tabelle2.feld3
FROMtabelle1
JOIN
tabelle2
ON
tabelle1.id = tabelle2.foreignkeyWHERE
tabelle1.feld5 = 1
AND
tabelle1.feld6 > 1000Ich würde sogar behaupten, die weiteren WHERE-Abfragen lassen sich auch noch in den ON-Teil integrieren. Vorteil ist Performancegewinn, da die entstehende Zwischentabelle kleiner ist.
- Sven Rautenberg
-
Hallo Sven,
Ausgerechnet ein ganz blödes Beispiel nimmst du da. Deine Abfrage macht sich besser so:
Ich habe mir schon überlegt, ob ich es mit JOIN oder nicht formulieren sollte. Dann habe ich mir gedacht, JOINs findet man sowieso alle Nase lang irgendwo, also mache ich es einmal so, daß es auch mit Datenabnken funktioniert, in welchen JOIN nicht implementiert ist (AFAIK ist Oracle das prominenteste Beispiel).
Außerdem gings mir sowieso eher um die Formatierung;-)SELECT
tabelle1.feld1,
tabelle1.feld2,
tabelle1.feld3,
tabelle1.feld4,
tabelle2.feld1,
tabelle2.feld2,
tabelle2.feld3
FROM
tabelle1
JOIN
tabelle2
ON
tabelle1.id = tabelle2.foreignkey
WHERE
tabelle1.feld5 = 1
AND
tabelle1.feld6 > 1000Ich würde sogar behaupten, die weiteren WHERE-Abfragen lassen sich auch noch in den ON-Teil integrieren. Vorteil ist Performancegewinn, da die entstehende Zwischentabelle kleiner ist.
Hmm, könntest Du einmal näher erläutern, wie Du Dir das so vorstellst?
Grüße
Klaus-
Hallo Sven,
Ausgerechnet ein ganz blödes Beispiel nimmst du da. Deine Abfrage macht sich besser so:
Ich habe mir schon überlegt, ob ich es mit JOIN oder nicht formulieren sollte. Dann habe ich mir gedacht, JOINs findet man sowieso alle Nase lang irgendwo, also mache ich es einmal so, daß es auch mit Datenabnken funktioniert, in welchen JOIN nicht implementiert ist (AFAIK ist Oracle das prominenteste Beispiel).
Das (SELECT x,y,z FROM tab1,tab2) _ist_ ein JOIN, auch wenn das Wort "JOIN" nirgendwo auftaucht. Oracle hat für JOINs eine andere Syntax - Oracle scheint mir sowieso in vielen Dingen ganz anders gestrickt zu sein, als z.B. mySQL.
Außerdem gings mir sowieso eher um die Formatierung;-)
Das ist voll angekommen.
SELECT
tabelle1.feld1,
tabelle1.feld2,
tabelle1.feld3,
tabelle1.feld4,
tabelle2.feld1,
tabelle2.feld2,
tabelle2.feld3
FROM
tabelle1
JOIN
tabelle2
ON
tabelle1.id = tabelle2.foreignkey
WHERE
tabelle1.feld5 = 1
AND
tabelle1.feld6 > 1000Ich würde sogar behaupten, die weiteren WHERE-Abfragen lassen sich auch noch in den ON-Teil integrieren. Vorteil ist Performancegewinn, da die entstehende Zwischentabelle kleiner ist.
Hmm, könntest Du einmal näher erläutern, wie Du Dir das so vorstellst?
Der Unterschied zwischen
SELECT x,y,z FROM tab1,tab2 WHERE tab1.id=tab2.id
und
SELECT x,y,z FROM tab1 LEFT JOIN tab2 ON tab1.id=tab2.id
(zumindest bei mySQL!) ist: Bei Version 1 wird zunächst eine Zwischentabelle angelegt, in der alle Einträge aus Tabelle 1 mit allen Einträgen aus Tabelle 2 verknüpft werden (wobei soviele Zeilen entstehen, wie das Produkt der Zeilen der beiden Tabellen groß ist. Hat tab1 100 Zeilen, und tab2 50, entstehen 100x50=5000 Zeilen). Aus dieser Tabelle werden dann alle Zeilen herausgefischt, welche der Bedingung entsprechen (die IDs sind gleich).
Bei Version 2 wird gleich beim Entstehen der Tabelle die Bedingung für die Zusammensetzung der Tabelle geprüft, es entstehen also garnicht erst soviele Zeilen, die hinterher wieder verworfen werden müssen.
Bei kleinen Tabellen macht das nichts aus (zumindest merkt man es nicht). Aber bei großen Tabellen dürfte es schon interessant sein, ob die Zwischentabelle nur 10.000 Zeilen groß ist (weil das die größte oder kleinste beteiligte Einzeltabellengröße ist, je nach Query), oder ob die Zwischentabelle 10.000x10.000=100.000.000 Zeilen groß ist.
- Sven Rautenberg
-
Hallo,
Ich habe mir schon überlegt, ob ich es mit JOIN oder nicht formulieren sollte. ...
Das (SELECT x,y,z FROM tab1,tab2) _ist_ ein JOIN, auch wenn das Wort "JOIN" nirgendwo auftaucht.
Das ist mir schon klar. Ich habe mich eher auf das Schlüsselwort JOIN in Datenbanken wie mySQL bezogen, nicht auf das Verknüpfen mehrerer Tabellen bei Abfragen an sich.
Oracle hat für JOINs eine andere Syntax -
Ja, nämlich
select blablabal
from tabelle1, tabelle2
where tabelle1.id = tabelle2.fk(das trifft zumindest auf alle Versionen bis einschließlich 8 zu, die 9er kennt AFAIK inzwischen auch die JOIN-Syntax )
Oracle scheint mir sowieso in vielen Dingen ganz anders gestrickt zu sein, als z.B. mySQL.
Das ist wohl wahr.
Aber welche Datenbank kennst Du eigentlich, die nicht ihr eigenes Süppchen kocht?Ich würde sogar behaupten, die weiteren WHERE-Abfragen lassen sich auch noch in den ON-Teil integrieren. Vorteil ist Performancegewinn, da die entstehende Zwischentabelle kleiner ist.
Hmm, könntest Du einmal näher erläutern, wie Du Dir das so vorstellst?
Der Unterschied zwischen [...] oder ob die Zwischentabelle 10.000x10.000=100.000.000 Zeilen groß ist.
Nein, das meinte ich nicht. Ich wollte wissen, wie Du die anderen WHERE-Bedingungen [1] auch mit 'JOIN ON' abbilden willst. Oder habe ich da was falsch verstanden?
Grüße
Klaus[1]
WHERE
tabelle1.feld5 = 1
AND
tabelle1.feld6 > 1000-
Yo!
Oracle scheint mir sowieso in vielen Dingen ganz anders gestrickt zu sein, als z.B. mySQL.
Das ist wohl wahr.
Aber welche Datenbank kennst Du eigentlich, die nicht ihr eigenes Süppchen kocht?Eigentlich jede. Es wird berichtet, ANSI-SQL würde nirgendwo real verwendet.
Nein, das meinte ich nicht. Ich wollte wissen, wie Du die anderen WHERE-Bedingungen [1] auch mit 'JOIN ON' abbilden willst. Oder habe ich da was falsch verstanden?
Naja, JOIN tab2 ON tab1.id=tab2.id AND tab1.feld5=1 AND tab1.feld6>1000
Die ON-Bedingung muß ja nicht ausschließlich zwei Tabellen vergleichen.
Ich gebe aber gern zu, daß ich dieses Vorgehen noch nicht getestet habe. Es ist also möglicherweise total falsch. Außerdem wäre es eigentlich von der Logik her besser, wenn die Tabellenverknüpfung im ON-Teil steckt, und die eigentliche Datensatzselektion im WHERE.
- Sven Rautenberg
-
-
-
-
-
-
-
Hi Klaus,
Das ID-Feld mußt Du schon weglassen, allerdings
müßtest Du dann das Statement um die Feldnamen
erweitern [1]:
INSERT INTO t_files (name,size) VALUES($name,$size);
(Ohne jetzt die Feldnamen wirklich zu kennen)das ist einer der Gründe, weshalb ich so gegen AutoInkrement-Werte wettere: Sie machen die intuitive Mengen-Eigenschaft von Tabellen kaputt.
[1] wobei ich es vorziehe, immer alle Feldnamen
ausdrücklich anzugeben. Das erleichtert einerseits
die Fehlersuche, andererseits kann das bei
Strukturänderungen auch von Vorteil sein.Bei SQL-Statements im Quelltext irgendwelcher Anwendungen magst Du recht haben.
Aber ich erlebe oft genug, daß ich mal eben schnell einen Teil einer Tabelle "klonen" will, so in der Art
CREATE TEMPORARY TABLE X AS
SELECT * FROM <tabellenname>
WHERE <bedingung>;UPDATE X
SET <feldname> = <wert>;INSERT INTO <tabellenname>
SELECT * FROM X;Wobei <feldname> dann ggf. der Primärschlüssel (oder ein Teil desselben) ist.
Wenn ich mit Mengen arbeiten darf, dann sind solche Operationen ganz prima möglich. Habe ich aber auch nur eine einzige AutoInkrement-Spalte, dann kann ich so etwas vergessen.
Und ich muß dann im Quelltext meiner Anwendung auch tatsächlich die komplette Liste der Spaltennamen einbrennen (und diese bei jeder Änderung des Tabellenformats mit anpassen), die mich an dieser Stelle doch gar nicht interessieren sollte ...
Viele Grüße
Michael
(der "seinen" Operateuren einen Benutzerkennung-Kloner mit CGI-GUI geschrieben hat, damit diese die Probleme von Kunden reproduzieren können, ohne sich mit deren Benutzerkennung und Passwort anmelden zu müssen - denn erstens kennen die Operateure das nur verschlüsselt gespeicherte Passwort des Kunden nicht und zweitens ist mehrfaches paralleles Login verboten - aber leider keinen Einfluß auf die Tabellenformate des verwendeten Fremdprodukts hatte und sich über die AutoInkrement-Spalte aus den beschriebenen Gründen mächtig geärgert hat)-
Hallo Michael,
das ist einer der Gründe, weshalb ich so gegen AutoInkrement-Werte wettere: Sie machen die intuitive Mengen-Eigenschaft von Tabellen kaputt.
Für mich gibt es im Datenbankdesign grundsätzlich zwei verschiedene Arten von Tabellen. Die einen mit wirklichem Inhalt, und da möchte ich jeden Datensatz so einfach wie möglich referenzieren können. Und das ist IMHO nun mal am Besten mit einem unique integer als Primärschlüssel zu bewerkstelligen.
Und dann gibt es Tabellen, welche im Wesentlichen nur Verknüpfungsinformationien enthalten (m:n-Beziehungstabellen). Hier gibt es nicht zwangsläufig einen Primärschlüssel, und wenn dann meist einer, der alle notwendigen Felder, welche Foreinkeys auf die verknüpften Tabellen sind, beinhaltet. (Was für eine Satzkonstruktion *tststs*)Klar könnten sich oft auch in den 'Inhaltstabellen' andere Primärschlüssel definieren lassen. Aber die Datensatzreferenzierung wird dadurch meist erheblich komplizierter.
Und da sind wir dann bei der Generierung eines eindeutigen Primärschlüssels. IMHO muß das eine atomare Funktion sein, da sonst bei Mehrprozeßanwendungen (und welche Anwenungen sind das heute nicht) kein zuverlässiger Primärschlüssel generiert werden kann.
Mir persönlcih gefällt die mySQL-Lösung auch nicht. (Wobei ich anmerken will, daß mir vieles bei mySQL fehlt)
Ich arbeite lieber mit Mechanismen wie Trigger und Generatoren, wenn es die Datenbank nur zuläßt. Damit wäre übrigens Dein Beispiel recht elegant zu lösen, auch wenn ein automatisch inkrementiertes Feld im Spiel ist.
CREATE TEMPORARY TABLE X AS
SELECT * FROM <tabellenname>
WHERE <bedingung>;»»
UPDATE X
SET <feldname> = <wert>;»»
INSERT INTO <tabellenname>
SELECT * FROM X;Wenn ich mit Mengen arbeiten darf, dann sind solche Operationen ganz prima möglich. Habe ich aber auch nur eine einzige AutoInkrement-Spalte, dann kann ich so etwas vergessen.
Nur solltest Du Workaroundlösungen, die durch Applikationsmängel notwendig werden, nicht zur Be/Abwertung eines bestimmten Konzepts heranziehen. Andere Datenbanken bieten durchaus Lösungen für die Realisierung beider Ansätze. (Habe ich schon gesagt, daß mir bei mySQL vieles fehlt?)
Und ich muß dann im Quelltext meiner Anwendung auch tatsächlich die komplette Liste der Spaltennamen einbrennen (und diese bei jeder Änderung des Tabellenformats mit anpassen), die mich an dieser Stelle doch gar nicht interessieren sollte ...
Irgendwann muß Du doch auch konkret werden. IMHO ist es egal, ob eine Anwendung nur weiß, in welcher Reihenfolge welche Feldinhalte in einem INSERT-Statment vorkommen müssen, oder auch deren Namen. Und 'select * form Tabelle' kann auch durchaus derart unperformant sein, daß man es besser bleiben läßt.
(der "seinen" Operateuren einen Benutzerkennung-Kloner mit CGI-GUI geschrieben hat, damit diese die Probleme von Kunden reproduzieren können, ohne sich mit deren Benutzerkennung und Passwort anmelden zu müssen - denn erstens kennen die Operateure das nur verschlüsselt gespeicherte Passwort des Kunden nicht und zweitens ist mehrfaches paralleles Login verboten - aber leider keinen Einfluß auf die Tabellenformate des verwendeten Fremdprodukts hatte und sich über die AutoInkrement-Spalte aus den beschriebenen Gründen mächtig geärgert hat)
Womit wir wieder beim RL wären, in dem sowieso jegliche sinnvolle theoretische Überlegung durch die mangelhafte Implementierung (anderer *g*) zunichte gemacht wird :-(
Grüße
Klaus
-
-
-
-
-
Hi Cheatah,
welche funktion am besten für einen eineindeutigen primärschlüssel
f. die mysql-DB geeignet ist,Datenbank-Funktionen überlässt man am besten der Datenbank.
Im Fall von MySQL: auto_incrementgenau so pauschal, wie Du das empfiehlst, antworte ich:
"Ganz schlechte Idee". Denn das, was Du selbst an so vielen Postings kritisierst, tust Du hier selbst: Du lieferst eine Schein-Lösung.Ein Mechanismus einer Datenbank ersetzt mitnichten einen sauberen
relationalen Entwurf der zu verwendenden Tabellen. Und ich habe noch nicht einen einzigen Fall gesehen, in dem ein AutoInkrement-Wert als Primärschlüssel die beste Lösung war.Entweder die Daten geben selbst einen besseren Primärschlüssel her,
oder sie geben möglicherweise überhaupt keinen Primärschlüssel her.
Eine Tabelle muß nicht zwingend einen Primärschlüssel haben.Viele Grüße
Michael-
Hi,
Und ich habe noch nicht einen einzigen Fall gesehen, in dem ein AutoInkrement-Wert als Primärschlüssel die beste Lösung war.
ich muss gestehen, dass ich mit MySQL noch nichts komplexeres gemacht habe; aber wenn auto_increment sich nicht wesentlich von Sequenzen in Oracle unterscheidet, kann ich dies nicht nachvollziehen.
Entweder die Daten geben selbst einen besseren Primärschlüssel her,
Oft bestehen Tabellen aus einer Vielzahl von Spalten, die allenfalls in ihrer Gesamtsumme einen Primary Key ergeben - und manchmal sind sie auch dann nicht unique.
oder sie geben möglicherweise überhaupt keinen Primärschlüssel her.
Richtig, dafür wird dann einer generiert :-)
Eine Tabelle muß nicht zwingend einen Primärschlüssel haben.
Nein, natürlich nicht. Den braucht sie nur, wenn von woanders aus darauf referenziert wird (wobei ich gerade bei Kreuztabellen nichts dagegen habe, statt eines Unique-Constraints gleich einen Primary Key zu verwenden, aber das ist wohl Geschmackssache). Meiner Erfahrung nach ist es nicht nur aus Gründen der Übersichtlichkeit in aller Regel besser, ab mehreren Spalten, die zusammen den PK ergeben würden, und ab längeren VARCHAR-Feldern eine ID zu vergeben - andernfalls müsste man die Daten redundant in anderen Tabellen speichern, was die Performance und den Platzverbrauch sicher auch nicht wesentlich verbessern.
Aber klar, Du hast recht: Alle Pauschalaussagen sind falsch und dumm ;-) Vielleicht weißt Du über auto_increment aber auch mehr als ich, weshalb ich Deinen Einwand darüberhinaus nicht verstehe...
Cheatah
-
-
-
Hallo,
ich hätte gern mal gewusst, welche funktion am besten für einen eineindeutigen primärschlüssel f. die mysql-DB geeignet ist, und wie ich ihn verwende. die time()-funktion ist z.b. für ein einfügen mehrerer Sätze innerhalb einer schleife ungeeignet, da es durchaus zu gleichen schlüsseln kommen kann
Du kannst z.B. autoincrement nehmen, da wird automatisch immer um eins hochgezählt. Oder Du nimmst innerhalb Deiner Schleife eine eigene Variable (z.B. um eins grösser als die Anzahl der bereits vorhandenen Datensätze), die bei jedem Durchlauf um eins erhöht wird.
Viele Grüsse
Alexa-
... Oder Du nimmst innerhalb Deiner Schleife eine eigene Variable (z.B. um eins grösser als die Anzahl der bereits vorhandenen Datensätze), die bei jedem Durchlauf um eins erhöht wird.
Bedenke, daß es sich um eine Mehrbenutzerdatenbank handelt. Daher sind solche 'Kunstgriffe' unbedingt zu vermeiden. Was enn zwei Prozesse gleichzeitig Daten nach diesem Konzept in die Datenbank einfügen? Da kann das nur schief gehen. Nein, der Mechanismus für eine eindeutige Datensatzidentifikation muß für alle Prozesse zentral sein. Und das ist im Falle von mySQL eben auto_increment.
Grüße
Klaus-
... Oder Du nimmst innerhalb Deiner Schleife eine eigene Variable (z.B. um eins grösser als die Anzahl der bereits vorhandenen Datensätze), die bei jedem Durchlauf um eins erhöht wird.
Bedenke, daß es sich um eine Mehrbenutzerdatenbank handelt. Daher sind solche 'Kunstgriffe' unbedingt zu vermeiden. Was enn zwei Prozesse gleichzeitig Daten nach diesem Konzept in die Datenbank einfügen? Da kann das nur schief gehen. Nein, der Mechanismus für eine eindeutige Datensatzidentifikation muß für alle Prozesse zentral sein. Und das ist im Falle von mySQL eben auto_increment.
auto_increment war auch das, was mir zuerst eingefallen ist. Dann fiel mir aber auch ein, dass hier im Forum mal davon abgeraten wurde. Wie könnte man denn ein autoincrement erreichen, ohne es selber zu benutzen?
Alexa
-
Hallo,
auto_increment war auch das, was mir zuerst eingefallen ist. Dann fiel mir aber auch ein, dass hier im Forum mal davon abgeraten wurde.
Ich kann mir denken, daß des öfteren davon abgeraten wird, Felder, welche mit auto_increment befüllt werden, zu etwas anderes als zur Datensatzidentifikation zu benutzen.
Wie könnte man denn ein autoincrement erreichen, ohne es selber zu benutzen?
Es muß IMHO in der Datenbank selbst passieren. Einige Datenbanken (z.B. Interbase) benutzt eigene Generatoren, welche auch dafür sorgen, daß eine ID nicht zweimal vergeben werden kann. Auch könnte, wenn die Datenbank das unterstützt, auch mit komplexeren Insert-Statements, welche subselects absetzen, so etwas simuliert werden. Aber das geht nicht mit der derzeitigen Version von mySQL nicht, soweit ich weiß.
Nein, ich denke doch, daß auto_increment für die Datensatzidentifikation das beste ist, aber eben nur dafür.
Grüße
Klaus
-
-
-
Hallo,
du MUßT einen Wert mit der eigenschaft auto_increment/unique /primary ehmen...
alles andere kann zu doppelten einträgen führen...
ich kann die das tool phpmyadmin empfehlen...
hier kannst du alles nötigen datenbank/tabelleneinstellungen vornehmen, ohne jedesmal einen sql-string selbst zu erfinden...in einer config-datei stellst du deine server und db werte ein, lädst es auf den server hoch und los gehts...allerdings würde ich dieses verzeichnis noch mit .htaccess schützen, da man sonst von usern ein paar schöne tabellen zusammengeklickt bekommt...
Odium
-