Hallo Marco!
Am 20. November 2012 13:09 schrieb Marco Fleckinger <
marco.fleckinger(a)wikipedia.at>gt;:
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