Hallo Peter
Hallo Peter,
On 11/20/2012 01:31 PM, Peter Putzer wrote:
Am 20. November 2012 13:09 schrieb Marco Fleckinger
<marco.fleckinger(a)wikipedia.at <mailto: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!
Bitte genau lesen! GUIDs waren ein Beispiel. Diese kann man verwenden,
muss aber nicht! Was ich sagen wollte, ist, dass alles was eindeutig ist
als ID verwendet werden kann, also auch eine aufsteigende Zahlenreihe.
Übrigens schützt die Verwendung eines Spreadsheets oder auch eines
"Papersheets" überhaupt nicht vor inhaltlicher Manipulation, das Prinzip
der Transaktionen aber zumindest teilweise und das eindeutig besser als
andere Lösungen.
Manipulation kann – wenn überhaupt – in einem DBMS jedenfalls viel
leichter verhindert werden, da ich keine Einzelaktionen durchführen
kann, nur eine ganze Transaktion. Da es eben um diese Verhinderung ging,
sehe ich die Antwort nicht am fachlichen Thema vorbei.
Grüße
Marco