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@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