MySql Kundennr = ID ???

[destin]

Hallo zusammen,
baue gerade eine Kundendatenbank auf, und jetzt stelle ich mir die Frage ob man als Kundennr die Id nehmen sollte oder lieber ein extra Feld und dann bei jedem Neueintrag die letzte Eingetragene Nummer zu nehmen. Wie ist es denn üblich, werden die Nummern von gelöschten Kunden neu besetzt oder sind Kundennummern einmalig???

Danke für Eure Hilfe
Destin

[Cheatah]

Hi,

Wie ist es denn üblich, werden die Nummern von gelöschten Kunden neu besetzt oder sind Kundennummern einmalig???

als Kunde würde ich mich u.a. über zwei Dinge freuen: 1.) nicht mit Dingen behelligt zu werden, die irgend jemand anders mal gemacht hat, und 2.) dass meine Daten nicht wegen einer Verwechslung an andere geschickt werden.

Kundennummern sind für die Dauer der Existenz unseres Universums eindeutig zu halten. Nach Ablauf dieser Frist solltest Du noch einmal gründlich nachdenken, bevor Du das Prinzip änderst.

Cheatah

[destin]

Dankeschön,
hatte ich mir schon gedacht wollte nur nochmal eine Bestätigung haben. Tausend Dank
Destin

[Hans]

Hi,

hatte ich mir schon gedacht wollte nur nochmal eine Bestätigung haben.

hmm, vielleicht habe ich es ja nicht verstanden, aber was genau wurde dir denn gerade bestätigt?

Hans

[Alexander (HH)]

Moin Moin!

hatte ich mir schon gedacht wollte nur nochmal eine Bestätigung haben.

hmm, vielleicht habe ich es ja nicht verstanden, aber was genau wurde dir denn gerade bestätigt?

Das eine Kundennummer (oder jede andere ID) nur eins zu sein hat: Eindeutig, und das für alle Zeit, sowohl in der Vergangenheit als auch in der Zukunft.

Wiederverwenden von IDs ist falsch, insbesondere wenn es aus esthetischen Gründen oder aus vermeindlicher Sparsamkeit passiert.

Alexander

[Hans]

Hi,

hatte ich mir schon gedacht wollte nur nochmal eine Bestätigung haben.

hmm, vielleicht habe ich es ja nicht verstanden, aber was genau wurde dir denn gerade bestätigt?

Das eine Kundennummer (oder jede andere ID) nur eins zu sein hat: Eindeutig, und das für alle Zeit, sowohl in der Vergangenheit als auch in der Zukunft.

Nicht dir bestätigt , Ihm ;-)

Wiederverwenden von IDs ist falsch, insbesondere wenn es aus esthetischen Gründen oder aus vermeindlicher Sparsamkeit passiert.

Genau dabei glaube war seine Frage ganz anders gemeint, aber mal sehen wenn er antwortet.

Hans

[destin]

Hallo zusammen,

Genau dabei glaube war seine Frage ganz anders gemeint, aber mal sehen wenn er antwortet.

Doch, genau das was Cheatah aufgeklärt hat, meinte ich. Das eine Kundennummer immer eindeutig ist und bleibt, dass wenn ich z.B. einen Kunden lösche, seine Nummer nie wieder besetzt werden kann.

Grüße
Destin

[Auge]

Hallo

Genau dabei glaube war seine Frage ganz anders gemeint, aber mal sehen wenn er antwortet.

Doch, genau das was Cheatah aufgeklärt hat, meinte ich. Das eine Kundennummer immer eindeutig ist und bleibt, dass wenn ich z.B. einen Kunden lösche, seine Nummer nie wieder besetzt werden kann.

Je nach Anwendungsfall würde ich einen ehemaligen Kunden nicht mal löschen, sondern ihn nur als ehemalig kennzeichnen, seine Daten aber im System belassen. Es kann durchaus passieren, dass man die Daten dieses Kunden auch nach Beendigung des Geschäftsverhältnisses noch braucht, z.B. wegen der Steuerabrechnung, Garantieabwicklung etc. pp..

Tschö, Auge

[Alexander (HH)]

Moin Moin!

Je nach Anwendungsfall würde ich einen ehemaligen Kunden nicht mal löschen, sondern ihn nur als ehemalig kennzeichnen, seine Daten aber im System belassen.

Richtig, deswegen machen meine Anwendungen beim Lösch-Kommando meistens nur ein "UPDATE ... SET deleted=true WHERE id=?" statt eines "DELETE FROM ... WHERE id=?"

Das hat auch den großen Vorteil, dass man sich beim versehentlichen Löschen nicht gleich ein großes Loch in den Fuß schießt. Das Feature hat schon so manchem armen Praktikanten beim Kunden den Ar... gerettet.

Nicht, dass die jeweiligen Administratoren sofort gesagt hätten, dass das nicht weiter schlimm wäre. Wer trotz Sicherheitsabfragen größere Datenmengen rekursiv löscht, muß erstmal kräftig bibbern und bluten: "Ich weiß nicht, ob wir davon ein Backup haben. Wahrscheinlich werden Sie die 150.000 Datensätze ihrer Kollegen neu erfassen und eingeben müssen. Haben sie zufällig Koffein-Tabletten dabei? Die Daten müssen morgen früh im System sein, sonst stimmen die Auswertungen nicht, und die Chefetage läßt ein paar Köpfe rollen." Wenn der arme Tropf dann kurz vorm Heulkrampf war, hat man ihn in aller Regel darüber aufgeklärt, dass der Löschvorgang mit ein paar Klicks leicht rückgängig zu machen ist.

Ja, das ist gemein. Aber auf Dauer reduziert es den Undelete-Aufwand gewaltig. ;-)

Alexander

[Auge]

Hallo

Das hat auch den großen Vorteil, dass man sich beim versehentlichen Löschen nicht gleich ein großes Loch in den Fuß schießt. Das Feature hat schon so manchem armen Praktikanten beim Kunden den Ar... gerettet.

An "Fehlbedienungen" hab ich dabei noch garnicht gedacht. Meine Anwendungen sind entweder für den Eigenbedarf (da müsste ich damit leben), bzw., wenn sie für Kunden sind, war da noch nichts sicherheitskritisches dabei, wo dann das ganze System (über die DB hinaus) inkosistent geworden wäre ("Warum finde ich die Daten zu diesem oder jenem Vorgang nicht mehr?").

Ja, das ist gemein. Aber auf Dauer reduziert es den Undelete-Aufwand gewaltig. ;-)

Ja ja, Schwein sein ist schön. ;-)

Tschö, Auge

[dedlfix]

echo $begrüßung;

"Ich weiß nicht, ob wir davon ein Backup haben."

Wenn er geistesgegenwärtig ist, gibt er den Ball zurück und kritisiert euch wegen eures unzureichenden Backupkonzepts.

Die Daten müssen morgen früh im System sein, sonst stimmen die Auswertungen nicht, und die Chefetage läßt ein paar Köpfe rollen."

Bei solch wichtigen Daten ist es im Prinzip unverantwortlich, ohne getesteten Backupmechanismus zu arbeiten, der ausreichend aktuelle Daten bereitstellen kann.

Wenn der arme Tropf dann kurz vorm Heulkrampf war, hat man ihn in aller Regel darüber aufgeklärt, dass der Löschvorgang mit ein paar Klicks leicht rückgängig zu machen ist.

Der Adrenalinstoß wird trotzdem nicht umsonst gewesen sein. Backups gibt es nicht umsonst. Was er möglicherweise auch am Sinken des Betrags in seiner Geldbörse und dem Ansteigen desselben in eurer Kaffekasse merken wird.

echo "$verabschiedung $name";

[Alexander (HH)]

Moin Moin!

echo $begrüßung;

"Ich weiß nicht, ob wir davon ein Backup haben."

Wenn er geistesgegenwärtig ist, gibt er den Ball zurück und kritisiert euch wegen eures unzureichenden Backupkonzepts.

Die Daten müssen morgen früh im System sein, sonst stimmen die Auswertungen nicht, und die Chefetage läßt ein paar Köpfe rollen."

Bei solch wichtigen Daten ist es im Prinzip unverantwortlich, ohne getesteten Backupmechanismus zu arbeiten, der ausreichend aktuelle Daten bereitstellen kann.

Vollkommen richtig. Es gab aber immer ein Backup, das stand explizit in den Anforderungen für die Umgebung der Software drin. Die oben zitierte Aussage war ausschließlich dem Einschüchtern von Massenlöschern vorbehalten.

Wenn der arme Tropf dann kurz vorm Heulkrampf war, hat man ihn in aller Regel darüber aufgeklärt, dass der Löschvorgang mit ein paar Klicks leicht rückgängig zu machen ist.

Der Adrenalinstoß wird trotzdem nicht umsonst gewesen sein. Backups gibt es nicht umsonst. Was er möglicherweise auch am Sinken des Betrags in seiner Geldbörse und dem Ansteigen desselben in eurer Kaffekasse merken wird.

Ja, wenn wir ein kleiner Laden mit vielen kleinen Kunden gewesen wären. Wir waren aber nur ein kleiner Teil der IT eines großen Unternehmens, und die Software lief nicht bei uns, sondern bei den (verglichen mit einem Kistenschieber) wenigen Kunden. Dankbarkeit wurde aber gelegentlich in reichlich kcal ausgedrückt. ;-)

Alexander

[at]

Hallo.

Der Adrenalinstoß wird trotzdem nicht umsonst gewesen sein. Backups gibt es nicht umsonst. Was er möglicherweise auch am Sinken des Betrags in seiner Geldbörse und dem Ansteigen desselben in eurer Kaffekasse merken wird.

Praktikanten mit nicht leerer Geldbörse? Mehr Geld in das Unternehmen tragen als man bekommt? Gutes Konzept. Vermietet ihr eure Paraktikanten auch? Ich hätte da eine zur Neige gehende Kaffekasse aufzufüllen.
MfG, at

[Hans]

Hi Destin,

Genau dabei glaube war seine Frage ganz anders gemeint, aber mal sehen wenn er antwortet.

Doch, genau das was Cheatah aufgeklärt hat, meinte ich. Das eine Kundennummer immer eindeutig ist und bleibt, dass wenn ich z.B. einen Kunden lösche, seine Nummer nie wieder besetzt werden kann.

Was jetzt für dich bedeutet du kannst die ID (damit meinst du vermutlich ein autoincrementfeld?) nicht nutzen?

Hans

[Destin]

Was jetzt für dich bedeutet du kannst die ID (damit meinst du vermutlich ein autoincrementfeld?) nicht nutzen?

Hans

Doch, genau das soll heißen das ich ein autoincrement Feld benutze.
Das mit dem löschen löse ich übrigens auch über ein Update, wobei ich da andersrum arbeite, und ein Feld auf null setzte welches bei Kunden auf 1 steht. Mir ging es eigentlich auch nur darum ob die Kundennummer immer fortlaufend und einmalig sind, oder ob man freie Nummern wieder besetzt.

Grüße,
Destin

[Hans]

Hallo Destin,

Doch, genau das soll heißen das ich ein autoincrement Feld benutze.

So habe ich das auch verstanden.

Das mit dem löschen löse ich übrigens auch über ein Update, wobei ich da andersrum arbeite, und ein Feld auf null setzte welches bei Kunden auf 1 steht. Mir ging es eigentlich auch nur darum ob die Kundennummer immer fortlaufend und einmalig sind, oder ob man freie Nummern wieder besetzt.

Das ist das wo ich mir nicht sicher bin was du meinst.
Wenn du Update benutzt und Status(bsp) auf auf NULL setzt, warum sollte dann deine "ID" verschwinden?

Aber mal angenommen du würdest nich update benutzen sondern wirklich löschen, was glaubst du dann passier mit der nicht mehr vorhandenen "ID"?

So wie ich dich verstehe denkst du dann, der Nächste Eintrag füllt die Lücke indem er die "ID" des gelöschten Eintrags annimmt?

Hans

[Destin]

So wie ich dich verstehe denkst du dann, der Nächste Eintrag füllt die Lücke indem er die "ID" des gelöschten Eintrags annimmt?

Hallo Hans,
jetzt verstehe ich auch was Du nicht verstehst. *g
Mir ist schon klar das die id nicht nochmal benutzt wird, bzw. werden kann. Sondern bei mir war gemeint, das wenn ich keine id verwende, sondern ein Feld, was weiß ich, z.b. "kundennummer" habe, und da dann per php immer die jeweilige kundennummer setzen lassen würde, dann könnte es ja theoretisch passieren, das die Nummer wieder besetzt würde.(klar, in dem Fall das man nicht löscht, nur updatet, kann es wieder nicht passieren, aber wie gesagt, mir ging es nur darum ob man die id dann als kundennummer nimmt oder ob es irgendwelche vor-/nachteile hat wenn man ein extra Feld nimmt.)

Danke für Eure Hilfe
und ein schönes Wochenende noch

Gruß
Destin

[Alexander (HH)]

Moin Moin!

Mir ist schon klar das die id nicht nochmal benutzt wird, bzw. werden kann. Sondern bei mir war gemeint, das wenn ich keine id verwende, sondern ein Feld, was weiß ich, z.b. "kundennummer" habe, und da dann per php immer die jeweilige kundennummer setzen lassen würde, dann könnte es ja theoretisch passieren, das die Nummer wieder besetzt würde.(klar, in dem Fall das man nicht löscht, nur updatet, kann es wieder nicht passieren, aber wie gesagt, mir ging es nur darum ob man die id dann als kundennummer nimmt oder ob es irgendwelche vor-/nachteile hat wenn man ein extra Feld nimmt.)

Es hat gewaltige Nachteile, die ID außerhalb der DB zu erzeugen. Es erfordert nämlich einigen Aufwand, dafür zu sorgen, dass zwei Instanzen der Anwendung (in diesem Fall zwei parallel abgearbeitete Requests) garantiert nie zwei identische IDs erzeugen. Man kann sich mit UUIDs / GUIDs herumschlagen, die recht unhandlich sind und verglichen mit einem 32- oder 64-Bit Integer viel Platz brauchen. Es ist daher in aller Regel wesentlich einfacher, diesen Job auf die DB abzuwälzen, dort haben in aller Regel sehr viele sehr kompetente Leute sehr viel Arbeit in genau dieses Problem investiert. Es lohnt sich einfach nicht, das Rad noch einmal neu zu erfinden.

Alexander