Autoincrement-Felder sinnvoll?

[alcaeus]

Zitat von WoGe:

Das deckt sich mit meine Meinung: Ein Autoincrement-Feld ist nur unter seltenen Randbedingungen wirklich hilfreich.

Seltene Randbedingungen?

Nur mal als Beispiel: das gesamte phpBB arbeitet mit autoinc-Spalten fuer IDs, in wirklich allen Tabellen.
In einigen Faellen (Themen- und Beitrags-tabellen, User- und Benutzer-tabellen) ist es noetig, die Insert-ID aus der ersten Tabelle in die zweite zu schreiben. Dies geschieht in MySQL z.B. ueber mysql_insert_id. Das ganze funktioniert natuerlich perfekt, und es ist auch sehr geschickt, wenn ich mir nicht zuerst eine unbenutzte ID raussuchen muss, sondern mir gar keine Gedanken drueber machen muss. Weiters sind die IDs immer eindeutig, d.h. ich muss mir auch nicht ueber eine evtl. inkonsistente DB Sorgen machen.

Greetz
alcaeus

[alzaimar]

Ich habe hier bei der Diskussion das Wort 'Mehrbenutzerumgebung' und 'Sicherstellung der Singularität' vermisst. Vermutlich habe ich es übersehen. Ich finds beruhigend, diese elementare Operation auf DBMS Seite in guten Händen zu wissen.

Es gibt eigentlich nur zwei Sorten von Tabellen, wo ich auf AutoIncs verzichte:
1. Wenn ich die ID (aus welchen Gründen auch immer) manuell vergeben will.
2. Bei einer Tabelle, die eine m:n Relation zwischen zwei Tabellen speichert.
Ansonsten sind AutoIncs die sicherste (und vor allen Dingen schnellste) Möglichkeit, IDs zu befüllen. Der Zeitpunkt (vor dem Insert per Generator oder nach dem Insert) ist irrelevant, da Relationen ausschliesslich innerhalb von Transaktionen definiert werden sollen.

Zum Thema Speed: Ich wurde mal zu einem Projekt als Nothilfe gerufen, wobei die ID per Hand erzeugt wurden: Eine extra Tabelle enthielt lauter Zähler, und bei einem Insert wurde vorher ein neuer Zähler von der Tabelle geholt. Das Erste, was ich tat, war das auf AutoIncs zu ändern, was die Insert-Performance um den Faktor 100 schneller machte. Pervers genug, das diese Zählermethode von einem IT-Experten empfohlen war. Kann man mal sehen, was sich alles IT-Exschpedde nennen darf...

Ausser aus theoretischen Überlegungen verschwende ich keinen Gedanken mehr an AutoIncs. Sie gehören dazu. Man macht es so. Es klappt. Fertig.

[Sharky]

Hai marabu,

entweder ist es zu spät oder ich habe heute nicht genügend Kaffee gehabt

Zitat von marabu:

...
Zur Verdeutlichung stelle dir einen DatenDialog vor, der die actions Save, Cancel, Apply anbietet. Nach einem Apply werden die Daten zwar persistent gemacht, aber der Verarbeitungskontext dieser Daten ist nicht aufgelöst worden. So eine Tabelle darf keine AutoInc-Spalte besitzen. ....

Kannst Du dieses Beispiel einmal näher erleutern?

Ganz allgemein bleibe ich bei meiner Aussage aus dem anderen Thread. Das wichtigste ist ersteinmal das ich einen PK in jeder Tabelle habe. Wie dieser erzeugt wird ist dann mehr eine Frage der gewünschten:

• Geschwindigkeit
• Flexibilität
• von der DB zur verfügung gestellten Möglichkeiten

[WoGe]

Zitat von alcaeus:

das gesamte phpBB arbeitet mit autoinc-Spalten fuer IDs
In einigen Faellen (Themen- und Beitrags-tabellen, User- und Benutzer-tabellen) ist es noetig, die Insert-ID aus der ersten Tabelle in die zweite zu schreiben. Dies geschieht in MySQL z.B. ueber mysql_insert_id.

Wenn ich mir hier anschau was der Befehl macht sehe ich keinen direkten Widerspruch zu meiner Aussage. Nur der Mechanismus wie du an den Wert für den Foreignkey kommst differiert ein wenig. Aber wenn ich da die Warnungen und User-Kommentare lese, scheint es mir nicht sonderlich sicher zu sein.

mfg
wo

[alzaimar]

Wenn ich mich einmischen darf: Das mySQL hier vielleicht (KA ) nicht sicher ist, hat ja Nichts mit deiner These zu tun, Autoincs seien nur "unter seltenen Randbedingungen wirklich hilfreich". Mich würde interessieren,
1. was sind das für Randbedingungen
2. wie machst Du es denn?

[marabu]

Hallo Sharky,

noch mal mit anderen Worten: mein von dir zitiertes Beispiel erfordert, dass der bei Ausführung von Apply (INSERT) neu vergebene Schlüssel für ein späteres Save (UPDATE) bekannt sein muss, solange der Bearbeitungsdialog existiert. Solche Kontexte existieren in DB-Anwendungen häufig.

Zitat von Sharky:

Das wichtigste ist ersteinmal das ich einen PK in jeder Tabelle habe.

Das ist unter Datenbankexperten kein Diskussionsthema, aber für die Mitlesenden sei nochmal auf die Bibel (Codd: The Relational Model for Database Management) verwiesen:

Zitat von E.F.Codd:

For each and every base R-table, the DBMS must require that one and only one primary key be declared...

Das R bezieht sich dabei auf das IBM System R, den Urvater aller modernen RDBMS.

Aber nochmal: hier ging es um eine einzige Frage von WoGe - und zu der wollte ich was gesagt haben.

Gute Nacht, bin müde jetzt. Werde morgen lesen, was ihr im Halbschlaf noch so alles geschrieben habt...

marabu

[WoGe]

Zitat von alzaimar:

1. was sind das für Randbedingungen
2. wie machst Du es denn?

Wenn mich der Datensatz auf unbestimmte Zeit nicht mehr interessiert - wie marabu es schon deutlich gesagt hat z.B. für Logdateien - also für jede Sorte Daten die in einer Tabelle sinnvoll abgebildet werden können und nicht sofort bearbeitet werden sollen, dann nehme ich ein durch die DBMS befülltes ID-Feld (konkret Generator und Trigger)

In allen Fällen, wo ich den Datensatz entweder sofort nochmals bearbeiten muss oder wenn über seine ID eine andere Tabelle verlinkt ist, hohle ich mir den Wert vom Generator und trage ihn selbst in die ID ein.

In meinem initialen Beitrag habe ich das Beispiel von MS-Access gebracht. Hier haben sich die Autoren auf einen Mechanismus verlassen den MS über Bord gekippt hat. Hätten die kein Autoincrementfeld benutzt, wäre gar kein Problem aufgetreten.

mfg
wo

[nieurig]

Hallo Leute,
meine Anmerkungen zu dem Thema.

Ich verfahre wie von alzaimar beschrieben. Alle Tabellen (bis auf Tabellen die nur Foreign Key's enthalten) bekommen einen Autoincrement Wert zusätzlich zu dem inhaltlich vorgegebenen Unique Key (Hansa hat Recht ). Dieser ist aber nicht immer PK, denn zur Beschleunigung von Abfragen ist es u.U. sinnvoll die inhaltlichen Schlüssel für die Tabellenverknüpfung zu nutzen.

Ich habe allerdings in letzter Zeit statt des Autoincrements öfter mal eine GUID als ID verwendet. Ursache hierfür sind Probleme bei der Datenübernahme aus anderen Datenbanken. Wenn in der fremden DB eine ID gewählt wurde, die in der eigenen bereits besteht, muss für den importieren Datensatz eine neue ID erzeugt werden. Das ist dann ein Problem wenn auch verknüpfte Datesätze aus der fremden Datenbank übernommen werden müssen. Damit die Verweise konsitent bleiben ist immer etwas Nacharbeit erforderlich. Dies erspare ich mir mit GUID's.

Ich wünsche allen eine schönen Tag!
Niels