Hallo Marco!

Am 20. November 2012 13:09 schrieb Marco Fleckinger <marco.fleckinger@wikipedia.at>:

Die Tabelle lässt sich so anlegen, dass bei Einfügen eines Datensatzes ein Zähler automatisch nach oben gezählt wird. Man kann aber auch andere IDs verwenden. Dafür verwendet man einen Trigger für BEFORE INSERT der die ID vergibt.

Dann kann man z.B. eine GUID (globl eindeutige ID) vergeben. Dies macht bei mehreren verteilten, nicht dauerhaft miteinander verbundenen DBs Sinn, die den Datenbestand regelmäßig in eine Zentrale synchronisieren. Man kann aber auch jede andere beliebige ID vergeben lassen, wie auch nach dem Format YYYYMMDDxx.

Ich hoffe, ich konnte helfen, einige wenige Vorteile einer Datenbank einer einfachen Tabelle gegenüber zu vermitteln. Schwieriger aufzusetzen ist es, das ist klar, aber wir haben ja das Know-How.

Die aktuelle Lösung halte ich persönlich für (fast) ideal – unschön ist, das wir eben nicht die CiviCRM-ID verwenden. Die chronologische Sortierung ist mE nicht ganz so wichtig, dafür gibt es doch sicher das Feld (die Tabellenspalte) "Date" oder zumindest so ähnlich.

Das war jetzt eine klassische Technikerantwort - technisch korrekt, aber am fachlichen Problem vorbei. Die ACID-Prinzipien stellen die technische Integrität des Datenstands sicher, schützen per se aber nicht vor inhaltlicher Manipulation. Grundsätzlich ist es natürlich sinnvoll, statt einer Tabellenkalkulation gleich ein echtes DBMS zu verwenden. Worum es Heinz aber ging (soweit ich das verstanden habe), daß eine fortlaufende lückenlose Numerierung der Mitglieder eine nachträgliche Manipulation leichter sichtbar machen würde (überspitzt: "Was ist mit den Mitgliedern 5 bis 7 passiert?"). Das hat mit GUIDs und anderen Aspekten der technischen Datensicherheit nichts zu tun!

Liebe Grüße
Peter