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.