Hallo Artur,
Zitat von
Artur:
... Die Frage ging in Richtung OregonGhosts Antwort. ...
diese Formulierung rettet meinen Tag.
Übrigens: Wenn du wirklich FireBird im Einsatz hast, dann ist der Beitrag von MrSpock die direkte Umsetzung des
MySQL Enum Data Type, von dem OregonGhost geschrieben hat.
Die Frage, ob Anreden in einer Tabelle zu speichern sind oder eher nicht, würde ich nicht mit der Kardinalität verbinden. Vor dieser Frage steht ja auch eine andere: Soll die Anrede verschlüsselt werden oder nicht? Ganz sicher werden alle Entitäten auf Tabellen abgebildet, aber die Anrede ist keine Entität, sie wird wahrscheinlich auch später nie zu einer solchen ausgebaut werden. Warum findet man trotzdem da und dort Datenmodelle, in denen die Anrede in einer eigenen Tabelle geführt wird? Technische Gründe (Lookup-Tabellen zur Normierung der Schreibweisen) können dafür sprechen oder auch die einfache Austauschbarkeit der Strings (Lokalisierung).
Zitat von
Artur:
... Wollte nur vermeiden, schon im Design Murks zu machen. ...
Davor kann dich nichts und niemand schützen. Eigentlich ist es fast sicher, dass man (nicht Du alleine) eine suboptimale Implementierung abliefert, weil in der Regel die Anforderungen mangelhaft fixiert wurden. Auch wird meistens zu früh mit der Programmierung begonnen, sodass das Datenmodell irgendwann nicht mehr oder mit großem Aufwand revidiert werden kann. Der größte Schaden wird nunmal in den frühen Phasen (requirements engineering, data modeling) verursacht. Deshalb sollte man als Entwickler diese Anforderungen auf Vollständigkeit und Widerspruchsfreiheit prüfen und danach so exakt wie möglich umsetzen - dann kann dir keiner je an den Karren fahren.
Freundliche Grüße