Hallo Heinz,
Spreadsheets (Excel und Calc) sind gerade anfällig für solche Schummeleien. Hinter CiviCRM steckt eine Datenbank. Auf die Schnelle hab' ich's nicht gefunden, aber ich nehme an, MySQL.
Aber unabhängig davon, welches Produkt genau dafür eingesetzt wird, arbeiten Datenbanken mit Transaktionen. Diese müssen entweder vollständig durchgeführt werden, oder eben gar nicht.
Daher wird ein solcher Vorgang auch als atomar, also unteilbar, bezeichnet. Mehr dazu und auch zum gewährleisteten ACID-Prinzip findest du unter [[Transaktion_(Informatik)]]).
Datenbanken werden auch für Geldgeschäfte verwendet und gerade MySQL, wird an viel kritischeren Stellen eingesetzt. Wikipedia ist dabei nicht halb so kritisch.
So einfach es auch sein mag, Spreadsheets zu verwenden, aber empfehlen würde es kein Informatiker der Welt. Hier werden nämlich nicht alle ACID-Eigenschaften eingehalten, vor allem nicht die Isolation.
Im Klartext: Wie will man sicherstellen, dass es ganz sicher nur eine einzige Version dieses Sheets gibt? Wie arbeitet man simultan mit den selben Daten.
Ganz nebenbei sind die Aufgaben von Wikimedia Österreich bereits jetzt so komplex, dass diese gemeinsam bewältigt werden müssen. Das geht aber nur sehr schwer, wenn man kein zentrales Register hat, auf das jeder zugreifen kann.
Ich sehe da eine Analogie zu einem anderen Bereich:
Die Verwaltung der Auslagerungsdatei war früher kein Teil des Betriebssystems. Jeder Entwickler war darauf angewiesen, entsprechende Funktionen selbst zu implementieren. Das ist aber mit Fehlern behaftet.
Heute hat diese Aufgabe weitestgehend das Betriebssystem übernommen. Fehler können zwar nach wie vor passieren, doch jetzt ist es eine zentrale Funktion des Betriebssystems.
In dieser Rolle wird der entsprechende Teil ausgiebig auf Herz und Nieren getestet. Dem gegenüber steht ein Entwickler, der diese Funktion eigentlich nur als lästiges Beiwerk sieht, damit sein eigentlichen Produkt funktioniert. Dass das nicht so gut getestet wird sollte auf der Hand liegen.
Was will ich damit sagen?
Wenn die Mitgliederverwaltung tatsächlich per File stattfindet, dann muss man immer manuell auf Atomarität, Konsistenz, Isolation, Dauerhaftigkeit (ACID) achten, statt auf bereits implementierte, gut getestete, hervorragend erprobte Lösungen zu setzen.
Das ACID-Prinzip zu wahren ist aber ein lästiges Beiwerk, daher kann das nicht lange gut gehen. Falls es doch klappt, dann großen Respekt meinerseits, aber ich würde das niemals empfehlen.
Diese Transaktionen gewährleisten außerdem auch, dass man nichts so einfach hineinschummeln kann. Zum Anlegen von neuen Einträgen in einer Tabelle (d. Datenbank) wird INSERT verwendet. Bei dieser Transaktion wird die ID automatisch vergeben.
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.
Grüße
Marco
On 11/20/2012 12:04 PM, Hubertl wrote:
lb Manuel, du kannst viel schreiben. Auch über CivcRM etc.
Mir ist das auch völlig egal, mit welchem Programm die Verwaltung einer Mitgliederliste stattfindet. Ich würde dir raten, grundsätzlich gei einfachen Aufgaben auch die einfachsten Lösungen zu suchen. Excel oder LibreOffice Calc hätte eine Mitgliederverwaltung in einem Bruchteil der Zeit und vor allem auch Kosten, die bislang für CivicRM aufgewendet wurde, erledigt. Zumindest was die Verwaltung einer imposanten Zahl von 100 Mitgliedern betrifft.
Aber bitte beleidige nicht meine Intelligenz. Es geht darum, das einfachste nur denkbare System - nämlich die fortlaufende Durchnummerierung mit Zahlen - durchzuführen und zwar so, dass es unmöglich ist, zwischen zwei bestehenden Mitgliedsnummern unbemerkt weitere Nummern einzufügen oder zu einem anderen Zeitpunkt entfernen zu können.
Das aktuelle System erlaubt gerade das!
Ich denke, das ist nicht so schwer zu verstehen.
Ich glaube nicht dass CiviRM mit seinem System die Mitgliedsverwaltung revolutioniert hat bzw. vorhat, diese zu revolutionieren. Dahinter stecktauch nur eine Datenbank.
Mache es ganz einfach:
Schön in Reihenfolge der Antragseingänge (Datum!!) mit eins, zwei, drei, vier, fünf usw. Nichts sonst. Das erleichtert auch die Suche in einem Dokument, wenn man nur die Mitgliedsnummer kennt.
Wenn Dir das zu schwer ist, dann kann ich dir gerne helfen, ich erstelle dann aus den bestehenden Datensätzen eine csv-Datei, die kannst du dann einpflegen. Den Datenbestand sortiere ich ganz einfach nach dem Datum - aufsteigend - und vergebe dann in einer Spalte genau in dieser Reihenfolge die entsprechende Nummer. Und das aus allen bislang eingelangten Mitgliedschaftsanträgen. Austritte werden in einer eigenen Spalte (aktiv/nicht aktiv) entsprechend gekennzeichnet, bekommen aber gleichermaßen eine der fortlaufenden Nummern.
Ist das so schwer oder benötige ich höhere Mathematik dafür?
Oder müssen wir das wirklich an anderer Stelle klären? Der aktuell aktive Vorstand von WMAT hat die Wahl.
h.