Korrektur struktureller Fehler

[tmaex]

Korrektur aller Abweichungen „Mitglieds-ID“ <-> „Mitgliedsnummer“ bzw. „Gruppierungs-ID“ <-> „Gruppierungsnummer“

Zulassen von allen benötigten Zeichen für
– Telefonnummern „/“
– Bankenname „-“ Zahlen Umlaute

[daniel]

Hi,

bzgl der IDs muss ich dich wahrscheinlich enttäuschen. Wir prüfen das gerne noch mal nach, aber so wie ich die Systemarchitektur in Erinnerung habe, die Interconcept (die NaMi Entwickler) uns gezeigt hat, werden die IDs automatisch von den Persistenzlayern erzeugt (z.B. Hibernate) und darauf hat die Applikation keinen Einfluss. Bei neuen Mitgliedsnummern wird zumindest versucht, die beiden Nummern gleich zu setzen.
Wo siehst du da den strukturellen Fehler – Man nimmt einfach immer die Mitgliedsnummer…

Worüber wir nachdenken könnten wäre, die ID im Webinterface auszublenden. Nur spätestens für die API werden die IDs als Fremdschlüssel usw. gebraucht.
Bei den GruppierungsIDs ist das noch relevanter, da die Gruppierungsnummer ja keine fortlaufende Zahl ist, sondern eine Abhängigkeits und Rechtestruktur beschreibt. Da ist es sogar unbedingt notwendig, dass es – z.B. für den Fall einer Änderung der Gruppierungsnummer oder bei Fusionen etc. – eine ID gibt, die sich nicht verändert und immer eindeutig ist.

Bzgl. Telefonnummern & Banknamen:
Da würden wir mal drauf achten, dass die Validierungsregeln für die Felder in der Dokumentation beschrieben sind.
Ob man für Telefonnummern weitere Zeichen braucht ist eine andere Frage. Alle Standards wie z.B. DIN 5008 sehen für die Schreibweise von Telefonnummern keine Schrägstriche vor. Je mehr Zeichen da erlaubt sind, desto schwieriger wird auch die Suche. Im Stamm und DV nutzen wir immer das Format „0123-456789“ – das macht dann auch den Abgleich mit anderen Listen einfacher.
Abgesehen davon ist der Schrägstrich soweit ich das getestet habe schon zulässig. Kannst du mal ein Beispiel schicken, das nicht funktioniert?
Bzgl. Banknamen: auch hier wäre ein Beispiel aus der Praxis hilfreich.

Viele Grüße & Gut Pfad
Daniel
(AG NCM)

[Fabian]

Hallo zusammen,

ich verstehe zwar nicht, warum man beim initialen Datenimport nicht darauf geachtet hat, dass Mitglied-IDs und Mitgliedsnummer übereinstimmen, aber das ist jetzt halt so. Bei den Gruppierungs-IDs war ich ziemlich überrascht, als ich festgestellt habe, dass die nicht unbedingt mit den Gruppierungsnummern übereinstimmen (bei den meisten Gruppierungen, die ich sehe, stimmen sie nämlich überein).

Zu den Telefonnummern: vielleicht sollte man hier mal einen einheitlichen Standard schaffen, den alle Gruppierungen verwenden sollen (z. B. 0123-456789). Oder die aufwendigere Lösung: NaMi kümmert sich selbst um die Formatierung der Nummer und die vom Benutzer eingegebenen Sonderzeichen werden ignoriert.

Viele Grüße,
Fabian

[daniel]

Hallo Fabian,

damit beschreibst du sehr schön das Problem, wenn man automatisch generierte IDs auf bestimmte Werte setzt.
„in den meisten Fällen stimmen sie überein“….
Im Prinzip ist die ID völlig willkürlich, da automatisch vergeben. Wer sich darauf verlässt, dass die ID irgendetwas abbildet, weil das jemand per Hand mal so zusammengeklöppelt hat, geht das Risiko ein, auch auf die anderen 10% zu stoßen 😉
Daher würde ich alle Entwickler bitten, die Felder so zu nutzen wie sie gedacht sind:
– die ID jeweils als internen Bezeichner und zur Referenzierung von Objekten. Am Besten gar nicht zu häufig dem Benutzer anzeigen (NaMi hat da auch noch Nachholbedarf)
– die Mitgliedsnummer zur Suche nach Mitgliedern und zur Anzeige beim Benutzer
– die Gruppierungsnummer am Besten im Format 03/02/06 beim anzeigen und intern als 0003020600
Die Gruppierungsnummer ist ja im engeren Sinne keine Zahl (z.B. LongInt) sondern eigentlich ein String der aus Zahlen besteht, die u.a. auch die Rechtevererbung in NaMi abbilden (Bund/Diözese/Bezirk/Stamm/Siedlung)

Zu den Telefonnummern: Prinzipiell wäre da ein einheitlicher Standard wünschenswert. Aber wenn wir davon ausgehen, das Entwicklerzeit begrenzt ist: Wäre das für dich / euch so eine hochprioritäre Baustelle?

[Fabian]

Hi,

das Problem mit den Gruppierungsnummern/-IDs war denke ich, dass es anfangs kein anderes Feld gab, aus dem man die Gruppierungsnummer auslesen konnte (vgl. Thread ). Deswegen hatte ich da einfach die Gruppierungs-ID verwendet, als ich angefangen habe auf die API zuzugreifen.

Ich bin mittlerweile aber auch dazu übergegangen die IDs nur intern zu verwenden und zur Suche nur noch Mitgliedsnummern zu verwenden.

Zu den Telefonnummern: Wollte es nur mal erwähnt haben. Hätte für mich aber auch eine sehr niedrige Priorität.

Viele Grüße,
Fabian

[tmaex]

zu Telefonnummern:
Die Bindestrich-Lösung hätte für mich super funktioniert, daran hatte ich einfach nicht gedacht.
Aber „/“ wird mitlerweile tatsächlich erlaubt, sry dass hab ich nicht gemerkt.

zu Banknamen:
– 1822 direkt (keine Zahlen erlaubt)
– Sparkasse Miltenberg-Obernburg (kein – erlaubt)
– Raiffeisenbank Großostheim-Elsenfeld (kein ß erlaubt)

Fehlermeldung beim Speichern: Der Name des Kreditinstituts muss aus mindestens 4 Zeichen bestehen und darf keine Umlaute, Zahlen und Bindestriche enthalten

zu strukturelle Fehler:
es ist für mich deshalb ein struktureller Fehler, da man direkt am Anfang von „Konzeptionelle Modelierung“ 1. Semester Informatik lernt, dass es Mist ist willkürliche IDs einzuführen. Zumal man eine wunderschöne Mitgliesnummer hat, die meiner Meinung nach als Fremdschlüssel für alles getaugt hätte.

[Autor]

Beiträge