Geschlecht in extra Tabelle speichern?

[p80286]

Nun, von der Theorie her wäre eine eigene Tabelle nicht falsch, insbesonders wenn man an die Nichtvergabe oder eben Transgender denkt.
Platz sparen? die paar Bytes machen den Kohl nicht fett.

Gruß
K-H

[Sir Rufo]

@Lemmy

Wenn ich Fremdaten unterstützen muss, dann nehme ich einen entsprechenden Value-Converter.

Delphi-Quellcode:

TFooConverter = class
public
  function ConvertFrom( Gender : TFooGender ) : TGender;
  function ConvertTo( Gender : TGender ) : TFooGender;
end;

Delphi-Quellcode:

TFooConverter

ist dann der einzige Ort in der Anwendung, der die Übersetzung kennt. Ich brauche also nur an einer Stelle die Übersetzung definieren.

[BUG]

Man kann es auch so sehen: Es sollte eigentlich keine Anfragen geben, bei dem der Enumwert direkt als String vom Nutzer kommt. Also kann man auch problemlos eine ID benutzen (vllt. einen Char für adhoc-Anfragen). Die Übersetzungstabelle kann man dann trotzdem haben, auch wenn man sie nur einmal ausliest.

Zitat:

Zitat von Lemmy (Beitrag 1280994)

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

Das ist Ansichtssache: Die Datenbank stellt einen View für die Anwendung bereit.
Idealerweise zeigt die Datenbank einer Anwendung Strings, einer anderen deren erwartete ID und der nächsten das entsprechende chinesische Schriftzeichen.

[Nersgatt]

Zitat:

Zitat von weisswe (Beitrag 1280992)

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.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

[AlexII]

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

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.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Stimmt :thumb:

[bernau]

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

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.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Damit fällst du aber direkt auf die Nase, wenn dein Programm mehrsprachig werden soll.

Ich mach es immer so, wie Sir Rufo es vorgeschlagen hat. Einfach eine ID festlegen. Im Programm wird dann schon das Korrekte angezeigt.

[Mavarik]

Zitat:

Zitat von AlexII (Beitrag 1280990)

Wieso INT64?

OK Kommt natürlich auf die Datenbank an!
Welchen Wertebereich hat bei Dir ein AutoInc Feld?

Mindestens aber ein INT32!

Also ist mein Byte für 0=Nichtbelegt 1=Mann 2=Frau 3=Unbestimmt 4=Im Wandel 5=Mann unter 18 6=Frau unter 18 7=Reserviert...

Deutlich platzsparender.

[Mavarik]

Zitat:

Zitat von AlexII (Beitrag 1281000)

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

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.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Stimmt :thumb:

LOL..

Deine Frage war:

Zitat:

Zitat von AlexII (Beitrag 1280981)

Spart man damit Platz in der DB oder eher nicht?

Die Antwort ist nein...

Und ob das ein gutes Datenbank Design ist oder nicht - lassen wir mal außen vor. Da gibt es hier schon unterschiedliche Meinungen.

[BUG]

Zitat:

Zitat von Mavarik (Beitrag 1281003)

Also ist mein Byte für 0=Nichtbelegt 1=Mann 2=Frau 3=Unbestimmt 4=Im Wandel 5=Mann unter 18 6=Frau unter 18 7=Reserviert...

Und da ist sie, die Verletzung der 1. NF :shock:
Das Alter im Geschlecht zu speichern halte ich für keine gute Idee. In relationalen Datenbanken würde ich, wenn ich nicht gerade Dokumente speichere, niemals zwei Werte in eine Spalte schreiben.

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1281001)

Ich mach es immer so, wie Sir Rufo es vorgeschlagen hat. Einfach eine ID festlegen. Im Programm wird dann schon das Korrekte angezeigt.

Konstante Texte gehören nicht in eine Datenbank...
Vielleicht hat man sich in Version 1. vertippt und will das in Version 1.1 korrigieren... Ich will bestimmt nicht durch X Datenbanken suchen um da nachträglich den richtigen Text rein zu bringen...