Verfahrensweise "Persönliche Daten"

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Verfahrensweise "Persönliche Daten"

    Hallo,

    zur Zeit werden persönliche Daten in drei Tabellen gespeichert und per Cronjob alle 12 Stunden abgeglichen. Die erste ist die User-Tabelle, die zweite die Kunden-Tabelle und die dritte die Verein-Tabelle. Das ganze hat aber den Haken, dass bei Kunden und Verein die Daten per PostIdent geprüft werden. Bisher mit dem Cronjob kein Problem, denn die Reihenfolge ist Verein > Kunden > User. Allerdinsg finde ich das ganze mit einem Cronjob nicht so schön und stelle mir eher eine zentrale Datenbank vor. Eigentlich auch kein Problem, wenn da nicht PostIdent wäre. Nun dachte ich mir, dass ich Daten, die im UserCP geändert werden, nur dort geändert werden; Änderungen bei Kunden oder Verein aber auf alle Bereiche Auswirkungen hat.

    Es ist noch anzumerken, dass bei dem Cronjob auch das Problem fehlerhafter Daten auftauchen kann, wenn z.B. die Kundendaten, aber nicht die Daten des Vereins, aktualisiert werden. Bei der anderen Methode ist zu bedenken, dass daten erst übernommen werden sollen/können, wenn bei einer Änderung aus dem Kunden- oder Vereinssystem die Daten erfolgreich geprüft wurden.


    Wie würdet ihr das lösen? Gibt es einen besseren Ansatz?
  • Sorry, das Problem ist noch zu abstrakt für mich.

    Also User kann jeder werden - und erst nach dem PostIdent Verfahren wird man Kunde.
    Also User und Kunde haben eine 1 zu 1 Beziehung. Wobei ein Kunde noch weitere Daten haben kann.

    Was hat es mit dem Verein auf sich? Kann ein Verein ein Kunde sein, oder kommen mehrere Kunden (oder Benutzer?) zu einem Verein zusammen?
  • Nein, da ist wohl etwas durcheinander geraten. Grundsätzlich kann jeder - wie es natürlich dem Konzept von GneX entspricht - User werden und die Plattform als User auch nutzen. Dazu werden Name und Ort, Geschlecht und Geburtsdatum als persönliche Daten erhoben.

    Mit in das System eingebaut ist ein Kundensystem, welches den Online-Verkauf von Eintrittskarten (Elektronische Eintrittskarte) via GneX ermöglicht. Wir stellen diese aus und bieten dem Kunden ein Interface, um Karten anhand der CardNr oder dem QrCode zu prüfen. Kaufen kann jeder registrierte User auf GneX. Um Kunde zu werden und so Eintrittskarten zu einem Event anbieten zu können, muss man zunächst als normaler User auf GneX bekannt sein und kann dann in einem Formular die erforderlichen Daten (Name, Straße, Ort, ...) eingeben und so Kunde werden. Nachdem die PostIdent-Prüfung erfolgreich war, aktivieren wir den KundenAccount, der zwar mit dem UserAccount verknüpft, aber dennoch unabhängig ist - heißt: Auch als Kunde ist man normaler User und kann die Plattform so nutzen, nur hat man zusätzlich noch das Kundensystem zur Verfügung.

    Ebenfalls enthalten ist das Vereinssystem, welches zur vollständigen Verwaltung des Vereins dient. Wer Vereinsmitglied werden möchte, muss zunächst User auf GneX sein, kann dann ebenfalls ein Formular ausfüllen (wie beim Kundensystem), es erfolgt eine PostIdent-Prüfung und nach erfolgreicher Prüfung entscheidet der Vorstand über die Aufnahme des Mitglieds in den Verein. Auch als Vereinsmitglied ist man normaler User und kann die Plattform so nutzen, nur hat man zusätzlich noch das Vereinssystem und zur Verfügung und ist eben Vereinsmitglied.

    Man könnte diese Systeme als Zusatzsysteme bezeichnen - Sie bieten zusätzliche Leistungen für diejenigen, die mehr mit GneX machen möchten, als die Plattform normal zu nutzen.


    P.S.: Es handelt sich um einen echten Verein, der letztes Jahr gegründet wurde ;)
  • naja, da Vereinsmitglied und Kunde verschiedene Anforderungen haben, würde ich beiden eine Spalte PostIdent-"ID" hinzufügen und damit aus die Daten einer PostIdent-"Tabelle" verweisen.

    Man muss nicht unbedingt immer den kleinsten gemeinsamen Nenner finden. Wenn Kunde und Vereinsmitglied sich unterscheiden, nutze ruhig mehrere Tabellen.
    Wenn sie sich kaum unterscheiden und sich in absehbarer Zeit auch nicht unterscheiden werden (denke mal an den Wachstum), dann musst du nur eine Tabelle benutzen und eine Rolle einführen.

    Lg
  • Danke für deine Einschätzung. Im Grunde geht es immer um die selben persönlichen Daten, wobei natürlich jedes System die Daten anders benötigt. Das Problem, dass sich für mich immer noch stellt ist eben das mit PostIdent. Bei den Kundendaten ist es unerlässlich, dass diese geprüft werden - Beim Verein könnte man noch drauf verzichten.

    Daher muss man einen Weg finden, dass Daten geändert - aber auch gleichzeitig geprüft - werden können.

    Eine Möglichkeit, die mir spontan einfällt, wäre, dass es eine zentrale Datenbank gibt und bei einer Änderung der Daten, diese per PostIdent bestätigt werden müssen. Das gilt aber nur, wenn man Kunde und/oder Vereinsmitglied ist. Dazu könnte ich dann das selbe Formular im UserCP, im Kunden- und Vereinsbereich eingliedern. Egal wo nun die Änderung durchgeführt wird, werden die Daten aktualisiert und eine PostIdent-Prüfung verlangt.
  • Sitze bereits daran, die Systeme mit dem neuen "PersonalData"-Verfahren zu versehen. Es wird eine Datenbank mit allen Prüfungen geben, da ich auch auf noch offene Prüfungen überprüfen möchte/muss/werde - Es macht schließlich keinen Sinn, dass jemand seine Daten ändern kann, wenn eine Prüfung noch nicht abgeschlossen ist bzw. neue Prüfungsunterlagen bekommt, wenn es noch eine Prüfung gibt (was sich ja gegenseitig ausschließt). Da das ganze recht Komplex von der Programmierung ist (Komplex im Sinne von "Wie das Verfahren laufen soll und alle Punkte richtig zu prüfen), können sich natürlich sehr leicht Fehler einschleichen - auch wenn ich es mehrmals durchgegangen bin. Folgendermaßen wird es von mir umgesetzt (eventuell entdeckst Du noch Denkfehler):

    Die Datenfelder in den drei Tabellen bleiben erhalten, zusätzlich gibt es eine zentrale Datenbank, die die Daten verwaltet.
    - Wenn nun ein User Kunde oder Vereinsmitglied werden möchte, wird der Account sofort aktiviert, wenn es eine erfolgreiche Prüfung gibt (Erfolgreiche Prüfung = Geprüft und keine offenen Prüfungen). Gibt es bisher keine Prüfung, wird eine neue angelegt und es erfolgt eine Aktivierung, wenn diese erfolgreich war.
    - Erfolgt ein Update der Daten, werden Kunden- und/oder Vereinsaccount deaktiviert und eine neue Prüfung angelegt. Dies geschieht nur, wenn eine Prüfung notwendig ist (also dann, wenn der User Kunde und/oder Vereinsmitglied ist). Auch hier erfolgt dann eine automatische Aktivierung.

    Da jede Änderung der Daten für einen Kunden Geld kostet (Prüfung per PostIdent kostet ca. 9,-), wird - wenn der User Kunde ist (unabhängig davon, ob er auch Vereinsmitglied ist) - zunächst die Rechnung verschickt. Wenn diese verbucht wurde, wird eine neue Prüfung angelegt. Auch hier erfolgt dann eine automatische Aktivierung.


    Wie gesagt, dass ganze ist ziemlich Komplex und hier so einfach nicht darzustellen. Eventuell wäre ein Test nicht schlecht.
  • Naja, soll den bei einer erneuten prüfung wirklich der account deaktiviert werden? Und was ist wenn die neuen daten fehlsxhlagen, kann man dann nicht einfach zurück zu seinen alten kehren? Ich glaube mit einer 1-n beziehung hast du deutlich mehr lösungen und kannst viel mehr fälle abdecken, an die du jetzt vielleicht noch gar nicht denkst.

    Aber du hast natürlich recht, dass das system damit komplexer und fehleranfälliger wird.
    Lg
  • Der Account wird dahingehend deaktiviert, dass der Kunde in dieser Zeit die KundenAccount-Funktionen nur eingeschränkt nutzen kann. Wenn eine Prüfung fehlgeschlagen ist, wird die Prüfung als erledigt markiert, die Daten sind aber nicht geprüft. Sicherlich könnte ich dann die alten Daten wieder eintragen und diese als geprüft ausgeben. Aber wenn jemand seine Daten ändern, stimme die alten ja nicht und sind so eigentlich auch nicht richtig geprüft. Es ist schon relativ wichtig, dass die Daten stimmen, da Rechnungen ausgestellt und - bei Kunden - dieser als Veranstalter hinterlegt sein muss.

    Ansonsten wüsste ich auch nicht wirklich weiter.