Einzelnen Beitrag anzeigen

jobo

Registriert seit: 29. Nov 2010
2.966 Beiträge
 
Delphi 2010 Enterprise
 
#2

AW: Datenbankmodell überprüfen

  Alt 17. Aug 2021, 22:47
1. Was wäre der Vorteil ohne echten FK? FK steigern sicher die Datenqualität. Der Inhalt der FK Entitäten muss einfach erweiterbar und auch korrigierbar sein.
(man kann vielleicht fragen, mandatory oder nicht, das sind Details, die evtl. auch fallweise unterschiedlich sind. Z.B.: der eine Ausbildungsort ist immer konstant für den einen Ausbilder und sowieso klar, also warum muss man ihn angeben? So was kann nerven und zu Ablehnung führen. Man macht es idR eher locker und schärft bei Bedarf nach)
2. Insgesamt sind Benennungen frei. Eher Englisch als Deutsch, Hauptsache einheitliche Sprache, das ist offenbar gegeben. Ist alles in ein bereits bestehendes System eingebunden, mit vorhandenen Regeln, würde man sich daran halten. FK muss nicht in den Namen des Feldes, das ist eine Eigenschaft, die dem Entwickler anhand der „Karte“/ des Modells deutlich sein sollte. Wenn mit „FK“, dann lieber als Suffix, statt als Präfix. Es erschließt sich nicht, warum einige Dinge als (starke) Abkürzung benannt sind, andere nicht. (Es ist mir nicht bekannt, dass es nennenswerte Längenbeschränkungen bei SQLite gibt.) Ausbilder1 - 4 ist nicht so toll. Sind es immer genau 4? Werden es absehbar nie mehr oder weniger? Ich würde es ohne Detailkenntnis einen Konstruktionsfehler nennen. Das sollte per n:m Relation angegeben werden. Sonst hat man z.B. Probleme, wenn man Abfragen/ Reports über alle Ausbilder macht, alles immer 4x.
Primärschlüssel werden gerne nur mit ID bezeichnet. Der Sinn ergibt sich dann durch <tabellenname>.id., Fremdschlüssel dann als <tabellenname>.<fremdtabellenname>_id. (wie gesagt, ohne „FK“ Anhängsel).
3. UUID nimmt man gerne in verteilten Systemen, weil sie autark eindeutige Werte bilden, ohne Server Verfügbarkeit/-Vorgabe. Wäre nicht meine erste Wahl in einem kleinen Client Server System.
4. Wenn das dem Ausbilder etwas Arbeit abnimmt okay (wenn es in der Praxis auch funktioniert) Wenn es aber praktisch bedeutet, alle AZUBIS brauchen Systemzugriff -nur dafür allein- und der Prozess ist blockiert, falls sie keinen Zugriff haben/bekommen oder zu faul sind, es zu machen, dann wird es komplizierter, als es sein muss. (Es ist einfacher, ein System zu bauen und zu betreuen für 100 Ausbilder, als für 100 Ausbilder mit jeweils 200 AZUBIS – jeweils als Anwender- durch die Registrierung)
Vielleicht lieber Import von Namenslisten, oder „Runtertippen“ von Namenslisten oder Copy/Paste aller Namen der Übungsteilnehmer… das bietet aber auch Raum für Fehler. Ebenso wie die Registrierung durch den AZUBI selbst. Ich habe nirgendwo eine fachliche oder individuelle ID für den AZUBI entdeckt. Wie geht man mit Doppelregistrierung, falscher Registrierung, Autorisierung, Authentifizierung um? Fehlbedienung, Manipulationsschutz?

Und wenn schon Personal und viele AZUBI Namen, dann die Frage:
Warum werden nicht auch die AZUBI einmalig angelegt/erfasst und sind „wiederverwendbar“
Gruß, Jo
  Mit Zitat antworten Zitat