ID-Vergabe eher der DB überlassen oder selbst manuell vergeben?

[mysqlfan]

Hallo!

Ich habe eine MySQL-Tabelle, wo zu jedem Dateneintrag einer Tabelle logischerweise zur Identifizierung des Datensatzes eine ID vorhanden sein muss.
Da ich die Datensätze alle per csv-Import einspiele, brauche ich folgenden Rat:

Soll die ID eines Datensatzes besser per auto_increment automatisch vergeben werden oder aber lieber manuell schon in der xls(csv)-Datei?

Mein Problem ist:

ID und Anfangs-Buchstabe des Datensatzes sollen zusammenhängen.
ID 1-10000 sollte Buchstabe A zugeordnet werden, ID 10001-20000 Buchstabe B usw.

Hätte man aber die IDs fortlaufend vergeben, würde ein nach dem Buchstaben Z hinzugefügter Datensatz, der mit A beginnt logischerweise nicht mehr in die ID-Range 1-10000 passen, sondern irgendwo bei 270000 liegen.

Da die Daten ständig ausgetauscht werden müssen durch erneuten csv-Import (die Daten werden immer in Excel verändert, nicht in SQL selbst), wäre es doch eigentlich ratsamer, sogenannte ID-Puffer vorzuhalten, oder?

Sprich: Buchstabe A besteht aus ID 1-9700 und dann lässt man für späteres Hinzufügen 300 IDs an Puffer frei und fängt mit Buchstabe B erst bei ID 10001 an.

Oder spricht da etwas dagegen?

[mrjerk]

Hallo,

Mein Problem ist:

ID und Anfangs-Buchstabe des Datensatzes sollen zusammenhängen.

Du kennst Deine Anwendung natürlich besser, aber ich würde an dieser Stelle nochmal darüber nachdenken, ob das wirklich so sein muss. Es erscheint mir jedenfalls sehr eigenartig, dass ein Datenbankfeld in so einer Form von einem anderen zwingend abhängen muss - hab ich noch nie so gesehen.

Sprich: Buchstabe A besteht aus ID 1-9700 und dann lässt man für späteres Hinzufügen 300 IDs an Puffer frei und fängt mit Buchstabe B erst bei ID 10001 an.

Oder spricht da etwas dagegen?

Ja, es ist nicht skalierbar...woher weisst Du, dass Du nie mehr als 300 zusätzliche IDs benötigen wirst?

Generell:
Ich würde IDs in der Regel von der Datenbank erzeugen lassen, wenn über diese ID auch nur innerhalb der genutzten Datenbank-Anwendung zugegriffen werden muss.
Benötigst Du die ID hingegen auch an anderer Stelle (weil das CSV-File z.b. auch genutzt wird, um andere Systeme zu steuern), würde ich die ID über das CSV importieren, dann allerdings in der Datenbank ZUSÄTZLICH ein eigenes Feld mit einer automatisch generierten ID vorsehen (UUID und ID oder so etwas).

Viele Grüße,
Jörg

[mysqlfan]

Hallo Jörg!
Schon mal danke für die schnelle Hilfe.

Das mit der UUID ist ein sehr guter Ansatz, den ich wahrscheinlich auch so umsetzen werde.

Das Problem ist der Ablauf von Datenpflege (Änderung) und Abhängigkeit in der DB.

1. Die Daten werden in Excel alle 4 Wochen aktualisiert, dann in csv konvertiert und in SQL importiert.

2. Die Tabellen stehen mit der ID in Abhängigkeit zueinander.
Ich habe eine Tabelle model und eine registration.
Die model-ID verweist auf registration-ID. Ändert sich die registration-ID oder model-ID, werden die Datensätze nicht mehr richtig kombiniert.
Da die Daten in Excel gepflegt werden, ist es mir lieber, ich kann die Daten mit

SELECT registration WHERE id=1-10000 aufrufen, löschen und dann abgeändert neu einspielen.

Bei autoincrement würden in der model Tabelle von der DB ständig neue IDs vergeben, die aber dann nicht mehr auf die registration-IDs verweisen.

[mrjerk]

Hallo,

Da die Daten in Excel gepflegt werden, ist es mir lieber, ich kann die Daten mit

SELECT registration WHERE id=1-10000 aufrufen, löschen und dann abgeändert neu einspielen.

Hm, ok. Also "registration_id" ist eine ID, die auch mit Buchstaben befüllt sein kann, richtig?

Also Du hast etwas wie:
Regsitration-ID: mrjerk
ID: 4711

Und Du willst bei Bedarf alle IDs, die Registration-IDs mit bestimmten Anfangsbuchstaben haben, löschen (bzw. modifizieren, anzeigen,...) richtig?
Z.b. alle User, die zum Buchstaben "m" gehören?

Das könntest Du doch dann auch mit:
SELECT registration WHERE registration_id LIKE 'm%'
erreichen?

Damit würde sich die Abhängigkeit zur numerischen ID erübrigen.

Oder versteh ich Dich falsch?

Viele Grüße,
Jörg

[mysqlfan]

Hm, ok. Also "registration_id" ist eine ID, die auch mit Buchstaben befüllt sein kann, richtig?

Theoretisch ja, allerdings habe ich sie mit normalen fortlaufenden Zahlen angelegt.

In der Tabelle model habe ich

model-ID: 1
registration-ID: 1234567

Wenn ich also model-ID 1 aufrufe, soll bei SELECT beider Tabellen automatisch der Datensatz 1234567 der Tabelle registration mit ausgelesen werden.

model-ID: 1 und registration-ID: 1234567 dürfen somit in ihrer Ziffernkombination nie verändert werden, da sonst zu einer model-ID die falschen Registration-Daten ausgegeben werden.

Und Du willst bei Bedarf alle IDs, die Registration-IDs mit bestimmten Anfangsbuchstaben haben, löschen (bzw. modifizieren, anzeigen,...) richtig?
Z.b. alle User, die zum Buchstaben "m" gehören?
Das könntest Du doch dann auch mit:
SELECT registration WHERE registration_id LIKE 'm%'
erreichen?

Ja genau.
Mir ist es aus Sicherheitsgründen aber irgendwie lieber, ich lösche die Datensätze anhand der ID heraus. Das Problem ist, dass die Datensätze beim Löschen 100%ig genau definiert werden müssen, um zu vermeiden, dass andere Datensätze mit herausgelöscht werden.
Die Datensätze 1-10000 fangen mit A an, die von 10001-10500 mit A7.
Die mit A sollen gelöscht werden, die mit A7 nicht und manchmal auch umgekehrt.

Wenn ich da mit WHERE registration_id LIKE 'a%' die Datensätze lösche, sind A und A7 verschwunden und das darf nicht sein.

Ich halte es für sicherer, wenn ich dann weiß A = 1-10000 und lösche auch nur Datensätze in diesem Bereich und alles andere bleibt unberührt.

[Ilja]

moin,

ich kann immer nur davon rten, einen primärschlüssel nicht für fachlichkeiten zu verwenden und genau das hast du vor. lass den schlüssel schlüssel sein, sprich er erfüllt die aufgaben einen datensatz eindeutig zu identifizieren, nicht mehr und nicht weniger. was du willst ist eine zusätzliche spalte, welche die geladenen datensätze entsprechend gruppiert. sprich beim laden der daten werden sie über eine zusätzliche spalte ihrer gruppe entsprechend zugeordnet. dort steht dann zum beispiel A7 und wenn du nur diese löschen willst, dann gibst du in der delete klaausel eben diese daten an. damit wären sie zu 100% genau identifiziert und du musst keinen unsinn mit dem primärschlüssel anrichten. grundsätzlich ist es auch besser, die vergabe der datenbank zu überlassen, zuem beispiel weil sie dadurch session unabhängig passiert.

Ilja

[fastix®]

Moin!

1. Die Daten werden in Excel alle 4 Wochen aktualisiert, dann in csv konvertiert und in SQL importiert.

Das ist, war und bleibt Schrott, genauer ein Relikt der Turnschuhnetzwerke mit vielen Insellösungen aus einer Zeit als verschiedene Tätigkeiten mit nicht vernetzten Einzelplatz-PCs erledigt wurden. Selbst danach wurde dateibezogen und nicht datenbezogen weiter gedacht und gemacht und es entstehen immer weitere Inseln und ein gigantischer Aufwand mit vielen Fehlern (siehe das Gruppierungsmerkmal mit den Anfangsbuchstaben)

Da die Daten in Excel gepflegt werden, ist es mir lieber, ich kann die Daten mit SELECT registration WHERE id=1-10000 aufrufen, löschen und dann abgeändert neu einspielen.

Selbst Excel kann mit Daten aus externen Quelle - ausdrücklich auch MySQL oder andere DBMS via ODBC - ganz gut umgehen. Wenn Excel nicht mehr reichen sollte ist selbst MS-Access eine ganz nette (wenn auch nicht ideale) Oberfläche um mit Daten in MySQL-Datenbanken zu arbeiten. Wozu also der Unsinn diese zu pflegen und periodisch über den Umweg CSV-Datei und unter tausend fehlerträchtigen Handgriffen (wie dem vorherigen Löschen geänderter Datensätze) in die Datenbank zu importieren? Das erzeugt Aufwand, Fehler und KOSTEN. Hier ist es definitiv besser irgendwann mal - möglichst vor der Pleite - "tabula rasa" zu machen und den historisch gewachsenen Mist zu bereinigen. Wenn man das rechtzeitig und planvoll macht, dann kann man den Zeitpunkt nämlich selbst bestimmen und diesen in eine Periode verlegen in welcher der eigentliche Arbeitsanfall erfahrungsgemäß niedriger ist um in der nächsten Streßphase davon zu profitieren.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Encoder]

ID 1-10000 sollte Buchstabe A zugeordnet werden, ID 10001-20000 Buchstabe B usw.

Dafür legst du doch lieber einen Index auf die Buchstaben. Was du da planst halte ich nicht nur für unschön sondern auch für gefährlich. Immerhin hast du dann die selbe Tatsache (nämlich den Aufbau deiner Wörter) auch in der ID, somit wäre eines davon überflüssig.

[EKKi]

Mahlzeit mysqlfan,

Soll die ID eines Datensatzes besser per auto_increment automatisch vergeben werden oder aber lieber manuell schon in der xls(csv)-Datei?

Eine ID hat im Regelfall genau eine Funktion: einen Datensatz eindeutig zu identifizieren. Sonst nichts. Vor allem ist es absolut falsch, vom Wert oder Inhalt dieses rein technischen Schlüssels noch irgendwelche Ableitungen zu machen oder darauf basierend irgendwelche fachlichen Schlüsse zu ziehen.

Deswegen solltest Du auch dem DBMS die Erzeugung und Verwaltung dieser ID überlassen - das kann es selbst am besten. Darüber hinaus solltest Du diesem rein technischen Schlüssel keine weitere sonstige Bedeutung zumessen, die er einfach qua definitionem nicht hat.

Mein Problem ist:

ID und Anfangs-Buchstabe des Datensatzes sollen zusammenhängen.
ID 1-10000 sollte Buchstabe A zugeordnet werden, ID 10001-20000 Buchstabe B usw.

Das ist in der Tat ein Problem ... eines, das Du schleunigst eliminieren solltest. Ein rein technischer Schlüssel sollte *NIEMALS* eine solche Bedeutung haben!

(die Daten werden immer in Excel verändert, nicht in SQL selbst)

Wie bereits gesagt: warum? Auch mit Excel kann man (mehr oder weniger prima) auf externe Datenquellen zugreifen.

Oder spricht da etwas dagegen?

Ja. Vieles.

MfG,
EKKi