Geschlecht in extra Tabelle speichern?

[AlexII]

Hallo,

ist es schlau das Geschlecht (Mann, Frau (nur zwei!)) in eine extra Tabelle zu speichern? Spart man damit Platz in der DB oder eher nicht? Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle? Was ist da besser?

Danke!

[Der schöne Günther]

Und was ist mit den Transgenderleuten?

[AlexII]

Zitat:

Zitat von Der schöne Günther (Beitrag 1280982)

Und was ist mit den Transgenderleuten?

Über die reden wir jetzt nicht, es geht um die DB!

[DeddyH]

Ich würde eine eigene Tabelle anlegen. Stell Dir nur vor, die Bezeichnung soll später geändert werden (z.B. "männlich" und "weiblich" statt "Mann" oder "Frau"), ist es dann günstiger, genau 2 Datensätze ändern zu müssen oder u.U. ein paar Millionen? Abgesehen davon bräuchtest Du sonst mindestens einen Check Constraint, wenn Du unterschiedliche Schreibweisen bzw. Tippfehler ausschließen willst.

[Sir Rufo]

Es kommt darauf an ...

Ich lege mir für solche Sachen einen eigenen Typen in der Anwendung an und sorge dafür, dass der immer nur korrekt erzeugt werden kann. Falsche Werte bei der Erzeugung oder beim Lesen aus der DB (hat jemand dran rumgefuscht) sind somit nicht möglich.

In der DB kann ich also ein simples Kennzeichen (Integer, string, whatever) benutzen, die Anwendung interpretiert die Daten richtig oder haut mir eine Exception um die Ohren.

[AlexII]

Zitat:

Zitat von DeddyH (Beitrag 1280985)

Ich würde eine eigene Tabelle anlegen. Stell Dir nur vor, die Bezeichnung soll später geändert werden (z.B. "männlich" und "weiblich" statt "Mann" oder "Frau"), ist es dann günstiger, genau 2 Datensätze ändern zu müssen oder u.U. ein paar Millionen? Abgesehen davon bräuchtest Du sonst mindestens einen Check Constraint, wenn Du unterschiedliche Schreibweisen bzw. Tippfehler ausschließen willst.

Ok... aber Speicherplatz belegt es wohl mehr, oder?

[Mavarik]

Zitat:

Zitat von AlexII (Beitrag 1280981)

Hallo,

ist es schlau das Geschlecht (Mann, Frau (nur zwei!)) in eine extra Tabelle zu speichern? Spart man damit Platz in der DB oder eher nicht? Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle? Was ist da besser?

Danke!

Wie soll es Platz sparen? Die Information muss doch trotzdem zu jedem Datensatz gespeichert werden. Und warum einen String? Ein Byte sollte doch fürs Geschlecht reichen?
Abgesehen davon das einen weitere Tabelle mehr Platz kostet und Du noch ein INT64 brauchst um das ID zu speichern...

Mavarik

[AlexII]

Zitat:

Zitat von Mavarik (Beitrag 1280989)

Zitat:

Zitat von AlexII (Beitrag 1280981)

Hallo,

ist es schlau das Geschlecht (Mann, Frau (nur zwei!)) in eine extra Tabelle zu speichern? Spart man damit Platz in der DB oder eher nicht? Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle? Was ist da besser?

Danke!

Wie soll es Platz sparen? Die Information muss doch trotzdem zu jedem Datensatz gespeichert werden. Und warum einen String? Ein Byte sollte doch fürs Geschlecht reichen?
Abgesehen davon das einen weitere Tabelle mehr Platz kostet und Du noch ein INT64 brauchst um das ID zu speichern...

Mavarik

Wieso INT64?

[weisswe]

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Tabellenstruktur:
GRUPPE;ID;SPRACHE;Wert;SortNr;Aktiv
Daten:
Geschlecht;m;de;männlich;1;True
Geschlecht;w;de;weiblich;2;True
JaNein;j;de;Ja;1;True
JaNein;n;de;Nein;2;True
...

Diese kann beliebig erweitert werden.

[Lemmy]

lt. Normalisierung sollte das schon in eine eigene Tabelle. Würde ich persönlich nur in bestimmten Fällen machen: Wenn das Geschlecht nur eine optionale Angabe wäre, die in den seltensten Fällen angegeben wird und es wirklich um das letzte Byte ginge.

Ansonsten kauft man sich da nur eine aufwändigere SQL Abfrage ein.

Zitat:

Zitat von DeddyH (Beitrag 1280985)

Ich würde eine eigene Tabelle anlegen. Stell Dir nur vor, die Bezeichnung soll später geändert werden (z.B. "männlich" und "weiblich" statt "Mann" oder "Frau"),

das ist primär eine Sache des Views - nicht der Datenbank.

Zitat:

Zitat von DeddyH (Beitrag 1280985)

ist es dann günstiger, genau 2 Datensätze ändern zu müssen oder u.U. ein paar Millionen?

und dazu dann gegenrechnen wie viel Arbeitszeit vergeudet wird um komplexere SQL-Abfragen zu entwickeln und zu pflegen? Achtung ;-) nicht übersehen!


Grundsätzlich sehe ich das wie SirRufo: In der DB landet ein "Enum" das in der Anwendung dann ausgewertet wird. Werden Fremddatenschnittstellen angeboten, dann kommt ein CheckConstraint auf die Spalte, wenn primär über die eigene Anwendung Daten rein kommen, kann man die Prüfung getrost auch dem ORM überlassen.

Aber: Ein allgemeines richtig oder falsch wird es auf die Frage nie geben....