AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Datenbankmodell überprüfen
Thema durchsuchen
Ansicht
Themen-Optionen

Datenbankmodell überprüfen

Ein Thema von Asura · begonnen am 17. Aug 2021 · letzter Beitrag vom 17. Aug 2021
 
jobo

Registriert seit: 29. Nov 2010
3.072 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
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:19 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz