Geschlecht in extra Tabelle speichern?

**Mavarik**

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

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.

OK mit "Im Wandel" und "unter 18" war eigentlich auch nur als Witz gedacht... 1:0 für Dich bei "unter 18" habe ich nicht nachgedacht!

**Nersgatt**

Zitat von bernau:

Zitat von Nersgatt:

Zitat von 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.

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.

Wieso, ich kann doch in einer anderssprachen Version die Daten in der Geschlechtertabelle ändern.

Das Problem habe ich aber auch nicht, weil meine Software nur im Deutschsprachigen Raum eingesetzt wird (und es aus verschiedenen Gründen sehr unwahrscheinlich ist, dass sich das mal ändert). Allerdings habe ich teilweise noch ein Feld "sprache_id" um die Texte in diversen Sprachen durch den User pflegen zu können. Beim Beispiel mit dem Geschlecht wäre das z.B. um die Anrede für einen spanischen Kunden auf der Rechnung in seiner Landessprache machen zu können.
In dem Fall muss natürlich Fallback-Mechanismen einbauen, für den Fall dass das Geschlecht in der gewünschten Sprache nicht gepflegt ist.

**bernau**

Zitat von Mavarik:

Zitat von bernau:

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...

Vieleicht habe ich mich missverständlich ausgedrückt. Ich mache es in dem Sinne so wie du. Eine ID wird festgelegt 1=Mann 2=Frau. In der Datenbank steht also nur (0,1,2) Im Programm ist fest hinterlegt (in verschiedenen Sprachen) welches Wort zur ID angezeigt werden muss.

**Mavarik**

Zitat von bernau:

Vieleicht habe ich mich missverständlich ausgedrückt. Ich mache es in dem Sinne so wie du. Eine ID wird festgelegt 1=Mann 2=Frau. In der Datenbank steht also nur (0,1,2) Im Programm ist fest hinterlegt (in verschiedenen Sprachen) welches Wort zur ID angezeigt werden muss.

Nein, habe Dich schon verstanden und Dir eigentlich zugestimmt.

**Sir Rufo**

Zitat von Mavarik:

Zitat von bernau:

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...

Diese Annahme ist falsch, denn es gibt nun mal Konstanten (natürlicher und unnatürlicher Art) die in so eine Datenbank zwangsläufig rein müssen.

Währungscode
Geschlecht (biologisch)
...

Jetzt ist es aber wichtig, dass die Datenbank die Information speichern kann und die Anwendung diese Informationen auch korrekt interpretiert.

Ein Vertipper in der Datenbank/Anwendung ist doch nicht tragisch. Wenn in der Version 1 das Zeichen N für männlich genutzt wurde und nun in Version 1.1 das korrigiert werden soll nach M, dann baue ich das einfach in die Anwendung mit ein, dass eben das Zeichen N und M eben männlich bedeuten. Das ist auch relativ simpel, denn bei der Erzeugung des Wertes, wird dann aus dem N ein M gemacht. Fertig ist die Laube und alles wird wieder schick.

Das Hauptproblem besteht in den meisten Anwendungen, dass einfach nur der repräsentierende Wert (der ist ohne Kontext) verarbeitet wird und nicht im Zusammenhang mit dem Kontext.

markieren

Delphi-Quellcode:

'M' <> 'm' <> 'N' <> 'n'

Benutzt man das aber mit dem Kontext zusammen, wird es klarer und einfacher im Umgang, weil man auch eine Interpretation mit einfliessen lassen kann (String mit 1 Zeichen, als Uppercase, 'N' => 'M')

markieren

Delphi-Quellcode:

			
 TGender.Create( 'M' ) = TGender.Create( 'm' ) = TGender.Create( 'N' ) = TGender.Create( 'n' )

Generell ist und bleibt es natürlich eine Frage der Anwendung und des allgemeinen Kontextes, ob man eine erweiterbares oder festes Geschlechtsmerkmal benötigt. Gemeinsam bleibt allerdings der Kontext, denn nur so wird aus einem Wert eine verwertbare Information.

Wenn die Information erweiterbar ist, dann habe ich auch einen Foreign Key und über den wird das Update gemacht. Dann trage ich das an einer Stelle ein und die gesamte Datenbank ist wieder im Lot

**Lemmy**

Zitat von Sir Rufo:

@Lemmy

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

da dachte ich mehr an Schnittstellen auf die du keinen Einfluss hast, sprich anderen schieben dir Daten rein...

Zitat von BUG:

Zitat von Lemmy:

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

Das ist Ansichtssache: Die Datenbank stellt einen View für die Anwendung bereit.

könnte es sein, dass wir aneinander vorbeireden? Als Views meinte ich nicht die DB-Views sondern die Visualisierung der Daten. WEnn wir nicht aneinander vorbeireden: Ein Interessanter Standpunkt - so habe ich das noch nie gesehen....

Das Geschlecht ist aus konservativer Sicht eine binärinformation: Mann/ kein Mann
bzw. aus feministisch-konservativer Sicht: Frau/keine Frau.

Für ewiggestrige Katholikenmuslime (oder wahlweise auch osteuropäische Enggestirne) würde es also reichen, das Geschlecht als Bit/Boolean abzulegen. Das ist die zweitkompakteste* Art, diese Information zu verpacken. Das hat natürlich den entscheidenden Nachteil, das eine Erweiterung des eigenen Horizontes nur mit erheblichem Aufwand bei der Änderung DB-Struktur möglich ist.

Da es sich hier -allgemein gesehen- um ein qualitatives** Merkmal handelt (ich bin 'A', 'B', 'C' oder 'D') würde ich auch zu einer einfachen Kodierung raten, dessen Präsentation (also Text) in einer separaten Tabelle untergebracht ist. Diese Kodierung ist ja unabhängig von der Information an sich und macht den Code nur lesbar. Hier würde ich allerdings davon abraten, in dieser 'Geschlechtertabelle' gleich noch Anrede etc. unterzubringen: Das gehört dort nicht hin: Anreden haben ja nur indirekt etwas mit dem Geschlecht zu tun, sondern eher mit dem Status der Person.

Ob man hier Bytes oder Integer verwendet, ist eigentlich wurscht, weil die paar Bytes Speicherplatz den Kohl auch nicht fett machen. Besser wäre eine gleichförmige Behandlung aller qualitativer Merkmale über alle Tabellen.

und eine Kodierung wie 'M' oder 'F' ist nun totaler Quark, weil dadurch die Tabelle nicht mir in 3NF ist.

(*) die kompakteste Art wären zwei Tabellen, für jedes Geschlecht eine eigene Tabelle.
(**) im Gegensatz zu quantitativen Merkmalen, wie Alter, Adresse etc.

**AlexII**

Zitat von Dejan Vu:

Für ewiggestrige Katholikenmuslime (oder wahlweise auch osteuropäische Enggestirne) würde es also reichen, das Geschlecht als Bit/Boolean abzulegen. Das ist die zweitkompakteste* Art, diese Information zu verpacken. Das hat natürlich den entscheidenden Nachteil, das eine Erweiterung des eigenen Horizontes nur mit erheblichem Aufwand bei der Änderung DB-Struktur möglich ist.

Jah... und solange die ewiggestrigen WESI Toilettenhersteller bei dem dualen System bleiben, werde ich Bit/Boolean bevorzugen.

**Sherlock**

Sobald Du mit einem Reportingtool drüber musst, wirst Du glücklich sein, wenn Du nicht zig Subreports erzeugen musst. Eine vernünftige Abwägung der Vor- und Nachteile der Normalisierung solltest du schon vornehmen (ich mach mich gerade unbeliebt, ich weiss). Aber wenn man erstmal 7 Joins durchführen muss, um sowas triviales wie Personenstammdaten zusammenzubekommen, dann schätzt man die "unnormale" Form sehr. Sowohl als Supportmitarbeiter, als auch jemand der mit der weiteren Nutzung der Daten in statistischen Auswertungen à la QlikView und Reportingtools wie Crystal (heisst das noch so?) beschäftigt ist.

Sherlock