Tabelle ohne Primary Key?

[hawkmaster]

Hallo zusammen,

ich habe eine Tabelle "daten" die momentan eine Spalte DatenID als Autoincrement und Primary hat. Es gibt noch weitere Spalten wie "AutragsID", "Werte", "Bemerkung" .
Eigentlich benötigt kein Programm diese Spalte "DatenID" mit dem Autoincrement Wert. Eigentlich wird nur mit der "AuftragsID" gearbeitet. (Diese ist wiederum PrimaryKey einer anderen Tabelle)

Gibt es irgend welche Nachteile wenn man diese Autoincrement Spalte ganz löscht?

PS: es handelt sich sowohl um MySQL als auch um SQlite

vielen Dank und viele Grüße
hawk

[Matthias Apsel]

Om nah hoo pez nyeetz, hawkmaster!

Eigentlich benötigt kein Programm diese Spalte "DatenID" mit dem Autoincrement Wert. Eigentlich wird nur mit der "AuftragsID" gearbeitet. (Diese ist wiederum PrimaryKey einer anderen Tabelle)

Gibt es irgend welche Nachteile wenn man diese Autoincrement Spalte ganz löscht?

Pauschal lässt sich diese Frage sicher nicht beantworten, Fakt ist, eine Tabelle braucht nicht zwingend einen PK zu haben, es schadet aber nicht, wenn sie einen hat.

Vielleicht brauchst du ja später mal irgendwann eine Abfrage, die durch das Fehlen genau dieses PK unnötig kompliziert wird?

Gibt es irgend welche Nachteile wenn man diese Autoincrement Spalte ganz löscht?

Erwartest du Vorteile, wenn du das tust?

Matthias

[hawkmaster]

Hallo zusammen,

vielen Dank für die Anregungen.
Ich arbeite normalerweise auch immer mit PrimaryKeys bzw. Autoincrement Spalten pro Tabelle.

Es handelt sich hier auch nicht um eine "normale" Bestellung oder Auftrag sondern um Druckdaten.
Es kommt nie vor das einzelne Optionen verändert oder gelöscht werden. Wenn dann wird ein Delete auf die "AuftragsID" gemacht.

Mir geht es auch eigentlich nicht so um den Speicherplatz.

Hintergrund der Frage, ob löschen der Spalte "DatenID"
Wir hatten momentan ein merkwürdiges Verhalten mit SQLite entdeckt.
Hier machte die Spalte DatenID merkwürdige Sprünge. Beispiel : die letzte ID war 32000, dann hatte sie plötzlich 250000. Wir wissen noch nicht so genau warum dies passiert. (sind noch am forschen)

[Matthias Apsel]

Om nah hoo pez nyeetz, hawkmaster!

Wir hatten momentan ein merkwürdiges Verhalten mit SQLite entdeckt.
Hier machte die Spalte DatenID merkwürdige Sprünge. Beispiel : die letzte ID war 32000, dann hatte sie plötzlich 250000. Wir wissen noch nicht so genau warum dies passiert. (sind noch am forschen)

Kümmere dich nicht um die Interna des DBMS. Eine ID muss lediglich eindeutig sein. Sonst nichts.

Matthias

[Tom]

Hello,

Kümmere dich nicht um die Interna des DBMS. Eine ID muss lediglich eindeutig sein. Sonst nichts.

Was für eine dämliche Haltung ist das denn?

Ich möchte es mal etwas zuspitzen: Kümmere dich nicht um den Inhalt von TLS, es muss nur TLS draufstehen, ob es funktioniert, ist doch egal...

Wenn man meint einen Fehler entdeckt zu haben, darf man dem selbstverständlich nachgehen. Die theoretische Meinung, die Du hier verbreitest (die hier leider bezüglich Autoincrement oft verbreitet wird) steht doch der praktischen Umsetzung entgegen. Und da weder MySQL noch SQLite den Primray-Key auswürfeln, sondern ihn hochzählen, wird man als auch fragen dürfen, woran die Abweichung liegt.

Die vorgesehenen Abweichungen sind dokumentiert.
* Schlüsselbereich erschöpft
* Einspielen von Daten mit höheren PKs, als bidher vorhanden
* Vorgabe eines Start-PK

Wenn man im laufenden Betrieb aber keine dieser Randbedingungen vorliegen hatte, ist die Incrementierung verlässlich - oder:
* der Arbeitsspeicher hat eine Macke?
* ...

Da fängt das Suchen dann berechtigterweise an!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Kümmere dich nicht um die Interna des DBMS. Eine ID muss lediglich eindeutig sein. Sonst nichts.

Was für eine dämliche Haltung ist das denn?

Wenn man meint einen Fehler entdeckt zu haben, darf man dem selbstverständlich nachgehen. Die theoretische Meinung, die Du hier verbreitest (die hier leider bezüglich Autoincrement oft verbreitet wird) steht doch der praktischen Umsetzung entgegen. Und da weder MySQL noch SQLite den Primray-Key auswürfeln, sondern ihn hochzählen, wird man als auch fragen dürfen, woran die Abweichung liegt

Im Normalfall schaut man in solche Tabellen ja nicht hinein. Offensichtlich gab es auch keine Ausgabe einer Warnung. Aus einer Inkrementierung, die nicht wie erwartet läuft, weil vielleicht die Daten intern anders organisiert werden, zu schlussfolgern, dass man ja den PK löschen kann, ist, denke ich, die völlig falsche Idee.

Matthias

[Tom]

Hello Matthias,

Kümmere dich nicht um die Interna des DBMS. Eine ID muss lediglich eindeutig sein. Sonst nichts.

Was für eine dämliche Haltung ist das denn?

Wenn man meint einen Fehler entdeckt zu haben, darf man dem selbstverständlich nachgehen. Die theoretische Meinung, die Du hier verbreitest (die hier leider bezüglich Autoincrement oft verbreitet wird) steht doch der praktischen Umsetzung entgegen. Und da weder MySQL noch SQLite den Primray-Key auswürfeln, sondern ihn hochzählen, wird man als auch fragen dürfen, woran die Abweichung liegt

Im Normalfall schaut man in solche Tabellen ja nicht hinein. Offensichtlich gab es auch keine Ausgabe einer Warnung. Aus einer Inkrementierung, die nicht wie erwartet läuft, weil vielleicht die Daten intern anders organisiert werden, zu schlussfolgern, dass man ja den PK löschen kann, ist, denke ich, die völlig falsche Idee.

Es könnte aber auch noch in der Applikation ein Fehler versteckt werden, da ja MySQL und mWn auch SQLite die dedizierte Zuweisung auf Autoincrement-Spalten zulassen.

Das ist mNm verbesserungswürdig. Ein zusätzlicher Typ "Autoincrement_autark" oder so ähnlich wäre da hilfreich :-O

Di MySQLs sind ja zum Glück etwas aufgeschlossener, als die PHPler. Die nehmen öfter mal eine Anregung aus der Prakis auf, so z.B. das Signalling in Triggers und Stored Routines. Das wollte ich heute eigentlich in meine diversen Trigger einbauen und die Schmuddellösung rausnehmen, aber ich bin zu nix gekommen... Muss ja auch in der API (PHP, Perl) entsprechend wieder umgebaut werden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[T-Rex]

ich habe eine Tabelle "daten" die momentan eine Spalte DatenID als Autoincrement und Primary hat. Es gibt noch weitere Spalten wie "AutragsID", "Werte", "Bemerkung" .
Eigentlich benötigt kein Programm diese Spalte "DatenID" mit dem Autoincrement Wert. Eigentlich wird nur mit der "AuftragsID" gearbeitet. (Diese ist wiederum PrimaryKey einer anderen Tabelle)

Also es gibt einen Auftrag und dieser Auftrag hat Positionen. Da ein Auftrag mehrere Positionen haben kann, brauchst du neben der Zuweisung zum Auftrag (AuftragsID) noch eine Spalte, die eindeutig für die Position steht. Das brauchst du spätestens dann, wenn du genau diese Position ändern oder löschen willst.
Wie man mir in meiner Ausbildung beibringen wollte braucht man nicht zwingend eine zählende Spalte. Meine Berufserfahrung hat aber gezeigt das diese Spalte die Behandlung von Daten in der Datenbank enorm vereinfacht. Und Speicherplatz kostet es fast nix.

Also ich stelle gerne Fragen und Hinterfrage Dinge. Bei einer zählenden Spalte in einer Tabelle habe ich aber aufgehört zu fragen und benutzt sie einfach.

Gruß
ohne Fragen
T-Rex

[Auge]

Hallo

Eigentlich benötigt kein Programm diese Spalte "DatenID" mit dem Autoincrement Wert. Eigentlich wird nur mit der "AuftragsID" gearbeitet. (Diese ist wiederum PrimaryKey einer anderen Tabelle)

Diue AuftragsID könnte als Fremdschlüssel mehrfach in der Tabelle vorkommen. Sie spielt in der Verarbeitung und Verknüpfung der Daten offensichtlich die Hauptrolle, ist aber nicht geeignet, einzelne Datensätze zu identifizieren.

Gibt es irgend welche Nachteile wenn man diese Autoincrement Spalte ganz löscht?

Wenn du keine andere Spalte hast, die definitiv und dauerhaft eindeutig ist, beraubst du dich des Identifikationsmerkmals für die Datensätze.

Wie schon gesagt, MySQL erlaubt es, ohne PK zu arbeiten, das ist in den meisten Fällen aber nicht sinnvoll. Der Index, meist ein Integer (4Byte pro Zeile), frisst zudem kein Brot.

Tschö, Auge