Abbildung von Master/Detail bei wenigen Werten

[Artur]

Guten Morgen :-)

Wie bildet Ihr es eigentlich ab, wenn in einem Feld nur wenige Werte zur Auswahl stehen.

Gemeint sind die Klassiker wie Feld Anrede ('Herr', 'Frau')
Oder der Status für ein Projekt ('aktiv','inaktiv','verloren','gewonnen')

Die offensichtlichen Lösungen sind mir bekannt (Feld mit entsprechender Länge und ComboBox bzw. Master/Detail mit Detail-Tabelle)

Aber was ist die eleganteste Lösung, denn das Ganze riecht stark nach Platzverschwendung bzw. unnötiges Aufblähen an Tabellen.

Kann man eine Lösung ähnlich wie in Delphi machen:

type
TStatus = (stAktiv, stInaktiv, stVerloren, stGewonnen); ?

Und wäre das sinnvoll?


Ciao,

Artur

[mkinzler]

Man könnte natürlich die Tabelle weglassen und die Bedeutung der IDs auf Programmseite verwalten. Wäre aber nicht sauber.

[OregonGhost]

Hmm, ich kenne zwar Firebird nicht, aber in mySQL ist die übliche Lösung dafür ein Enum. Das ist zwar von Programmseite aus wieder nur ein String, aber man kann die erlaubten Werte abfragen und zumindest theoretisch kann die Datenbank die Speicherung dieser Information optimieren. Denk immer dran, dass Strings grundsätzlich nichts schlechtes sind für Datenbanken - das macht sie in meinen Augen leichter wartbar. Und so ein extremes Aufblähen ist das im Normalfall auch nicht. Ob ein Datensatz jetzt 1500 oder 1510 Byte hat, ist relativ wurscht.

[MrSpock]

Hallo Artur,

wenn es dir nur darum geht, die gültigen Werte zu beschränken, kannst du mit einer entsprechenden Domain arbeiten, die das CHECK Constraint entsprechend setzt:

SQL-Code:

CREATE DOMAIN STATUS
AS VARCHAR(8)
CHECK(VALUE IN ('aktiv', 'inaktiv', 'gewonnen', 'verloren'))

[Artur]

Hallo zusammen

Vielen Dank für die Antworten. Die Frage ging in Richtung OregonGhosts Antwort.

Aber wenn es da nix Besserers gibt, als die Strings zu speichern, dann ist es okay.
(Wollte nur vermeiden, schon im Design Murks zu machen).

Mercie und schönen Tag.

Ciao,

Artur

[marabu]

Hallo Artur,

Zitat:

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:

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

[stoxx]

also da ich mich jetzt langsam auch mal mit Datenbanken beschäftige :-)
Hab ich mal meinen Experten um Rat gefragt. :)
Und ich hab mich von folgender Lösung überzeugen lassen.
Und zwar nicht die harten Strings ("inaktiv", "gewonnen", "verloren") speichern.
Sondern doch lieber doch eine Detailtabelle.

mit den Feldern "ID, ShortDescription, LongDescription"

Aus folgenden zwei Gründen.
Wenn ein Nutzer der Software in einer Combobox selectieren möchte.
würde es die Auswahl sehr vereinfachen. Wenn nicht nur "verloren" erscheint, sondern noch daneben eine kurze erklären.
Nicht immer weiß man ja mit einem einzigen wort was anzufangen.

Und man ist zukunftssicher, in Bezug auf Mehrsprachigkeit... was ist wenn Du mal eine russische Version herausgeben möchtest.
Da bist Du ja dann entweder kräftig am casten, oder musst Deine ganze Datenbank konvertieren.
.. und kannst keine DBCombobox verwenden
Eventuell müsstest Du bei Mehrsprachigkeit nur die eine Description Tabelle ändern.
Macht vieles einfacher ...

[Artur]

Hi stoxx,

stimmt, wurde ja auch oben schon so von einigen angemerkt. Allerdings handelt man sich natürlich auch einen Haufen Master Detail Abfragen ein, denn es bleibt ja nicht bei 1-2 Feldern.

Bei einer Person z.B. ist es die Anrede, der Titel, evtl. die Funktion (Einkäufer, Projektleiter, usw.), evtl. die Abteilung, (in meinem Fall) der oder die Mitarbeiter, die die Person betreuen, das Land, evtl. die (Int.) Vorwahl, usw.

Wenn man die Sache dann wieder in Tabellen oder Reports anzeigen möchte, gibt es schöne Abfragen...


Ich habe derzeit eine bunte Mischung (ein paar Felder sind Master Detail) und für ein paar andere habe ich eine Tabelle angelegt, die wiederum einige ComboBoxen befüllt (allerdings aus dem Grund, weil ich ein paar häufigere Sachen zur Auswahl anbiete und trotzdem die Möglichkeit lasse, eigene Daten in die Felder einzugeben wie z.B. bei der Funktion der Person: Einkäufer, Sachbearbeiter, etc. ist schon drin, aber die DBCombobox ist nicht als Dropdownlist definiert, so dass man auch "Hausmeister" eingeben könnte).

Aber was ich (als Hobbyprogrammierer) in letzer Zeit an Lernzuwachs hatte und schon alles neu geschrieben habe :wall:

Danke für den Tipp und gute Nacht :-)

Ciao,

Artur