Autoincrement-Felder sinnvoll?

[WoGe]

Hei Leute,

weil ich in diesem Thread Atomatischer Primärschlüssel immer von Autoincrement Feldern lesse, bitte ich mal um Kommentare ob solche Felder nicht prinzipiell tödlich sind, wenn es abhängige Tabellen gibt.

Ich hatte gerade den Fall: Ich habe ein Programm in Pflege bekommen, wo die ursprünglichen Programmierer abhängige Datensätze vor dem eigentlichen Hauptdatensatz speichern wollten.

Es handelt sich hierbei zwar um MS-Access in Verbindung mit MS-SQL2000 und bei Access2000 ging das sogar, aber Acess2003 verhält sich da eher so wie man es erwarten sollte.

Ich würde also, ausser bei Einzel-Tabellen immer den PK selbst befüllen.

mfg
wg

[Hansa]

Zitat:

Zitat von WoGe

...immer von Autoincrement Feldern lesse, bitte ich mal um Kommentare ob solche Felder nicht prinzipiell tödlich sind, wenn es abhängige Tabellen gibt...

Mann, mann WoGe. So etwas nicht zu verwenden hat genau den umgekehrten Effekt. Das ist ein Todesurteil für das Programm !! Du mußt dir auf jeden Fall eine Hintertür auflassen, um an eindeutige Daten dranzukommen !

[WoGe]

@Hansa

vielleicht habe ichs nicht deutlich genug gesagt:

Selbstverständlich bin ich für Eindeutige - sogar von Generatoren erzeugte Werte im Primärschlüsselfeld.

Aber ich möchte hier beleuchten, ob es sinnvoll ist, das befüllen eines solchen Feldes der DBMS zu überlassen.

Ich denke, ich mach das lieber selber und wollte hier eigentlich nur Eure Meinung dazu hören

mfg
wg

[mschaefer]

Moin, moin,

tja ist halt mal wieder eine Frage der Verfahrensweise. Bei einzelnen Tabellen erleichternsie das Arbeiten, da man sich damit nicht herumschlagen muß. Bei verknüpften Tabellen ändert sich damit die Arbeitsweise

Mit AutoInc-Feld

1. Haupttabebelle Datensatz speichern
2. AutoInc-ID Haupttabelle holen
3. abhängige Referenztabelle anlegen
4. AutoInc-Referenztabelle kann ignoriert werden
4. AutoInc-ID-Haupttabelle in Referenz-ID-Feld eintragen


Ohne AutoInc-Feld

1. erhöhten Generatorwert holen und in aktuellen Satz imSpeicher eintragen
2. Datensatz mit Haupttabellen-PID, (erhöhter Generatorwert) eintragen
3. erhöhten Generatorwert der Referenztabelle holen und PID im Speicher ablegen
4 PID der Haupttabelle im Referenz-ID Feld im Speicher eintragen
5. Speichern des Refereztabellendatensatzes

Vergleich:
mit AutoInc muß man sich nur um die Referebzfelder kümmern, hat aber einen Zugriff auf den Hauptdatensatz mehr.
Das ist bei eindeutiger Ordnung leicht (hole den letzten/ersten) aber bei nicht geordneten Datensätzen Suchaufwendig

ohne AutoInc muß man sich um das holen der PID kümmern, hat aber ein für jede Tabelle gleiches Arbeitschema
und die Zugriffe auf Generatoren sind im Vergleich zu Datensatzzugriffen schneller.

Fazit:
Bei einfachen Tabellenstrukturen mit festliegender Sortierung sind AutoInc-Fedler vorteilhaft.
Bei komplexeren Tabellenverknüpfungen und variablen Sortierungen sind Generatorsteuerungen aufgrund des gleichläufigen
Arbeitschemas leichter zu warten und die Datensatzeinfügezeiten sind auch bei Einsetzen des Datensatzes innerhalb ungeordneter Datenmengen schnell und unkompliziert ohne Sonderprogrammierungen.

So sehe ich das // Grüße // Martin

[Hansa]

Zitat:

Zitat von WoGe

Aber ich möchte hier beleuchten, ob es sinnvoll ist, das befüllen eines solchen Feldes der DBMS zu überlassen.

Wenn es für diesen Zweck einen wirklich unverzichtbaren Einsatzzweck gibt, dann den ! Prinzip : jede Tabelle hat ein ID-Feld und das wird automatisch hochgezählt !!

Das ist quasi Standard. Einmal bin ich davon abgewichen, weil da tatsächlich IMHO eine ID überflüssig war und prompt gab es Ärger. Wir reden lediglich über ein integer-Feld !

[marabu]

Hallo WoGe,

Zitat:

Zitat von WoGe

Ich würde also, ausser bei Einzel-Tabellen immer den PK selbst befüllen.

In Analogie zu OO-Datenbanken mache ich meine Vorgehensweise daran fest, ob sich der gespeicherte Datensatz noch in einem "aktiven" Zustand befindet.

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.

Eine Tabelle mit Log-Daten hat hingegen ein ausgeprägtes INSERT-Profil, da wäre eine AutoInc-Spalte zulässig und hilfreich.

Der thread, den du zitiert hast, macht auch mich nachdenklich. Datenbankprogrammierung ist eine eigene Disziplin mit eigenen Regeln - ohne ein solides Grundlagenwissen kann man da nicht produktiv sein - egal wieviel Hilfe man bekommt. Na ja - wird schon noch werden...

Grüße vom marabu

[Hansa]

Das mit der Extra-Disziplin ist ein guter Vergleich. Aber es ist keine kompett andere ! Ich würde mal sagen Weitsprung und Hochsprung. Für mich bliebe dann nur der Zehnkampf übrig. :lol:

Aber im Ernst : was spricht konkret gegen eine ID für jeden Datensatz, selbst wenn sie anscheinend vorerst nicht gebraucht wir ? Würde mich mal interessieren.

[kiar]

[OT]

Zitat:

Zitat von Hansa

Für mich bliebe dann nur der Zehnkampf übrig. :lol:

von allem ein bisschen :mrgreen:

sorry das musste raus[/OT]

raik

[marabu]

Zitat:

Zitat von Hansa

was spricht konkret gegen eine ID für jeden Datensatz

Nichts, im Gegenteil - aber das ist gar nicht die Frage von WoGe gewesen. Er wollte doch nur wissen, wer bereit ist die Kontrolle über den PK einem AutoInc/Identity-Mechanismus zu überlassen und unter welchen Bedingungen.

marabu

[WoGe]

Zitat:

Zitat von Hansa

Aber im Ernst : was spricht konkret gegen eine ID für jeden Datensatz, selbst wenn sie anscheinend vorerst nicht gebraucht wir ? Würde mich mal interessieren.

Nix!!!

Die Fragestellung ist ausschliesslich dem Zeitpunkt und dem Mechanismus des Hinzufügens des Wertes der ID gewidmet!

sowohl mschaefer alsauch marabu haben das sehr schön beleuchtet.

Zitat:

Zitat von marabu

Eine Tabelle mit Log-Daten hat hingegen ein ausgeprägtes INSERT-Profil, da wäre eine AutoInc-Spalte zulässig und hilfreich.

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

mfg
wg

[alcaeus]

Zitat:

Zitat von WoGe

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

Seltene Randbedingungen? :gruebel:

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 :stupid:

Zitat:

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:

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. :-D

mfg
wo

[alzaimar]

Wenn ich mich einmischen darf: Das mySQL hier vielleicht (KA :zwinker: ) 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:

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:

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:

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