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

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 von Hansa:

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

von allem ein bisschen

sorry das musste raus[/OT]

raik

[marabu]

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