Geschlecht in extra Tabelle speichern?

[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 von 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"),

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

Zitat von DeddyH:

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

[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;

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

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

[Dejan Vu]

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

[Dejan Vu]

Zitat von Sherlock:

Aber wenn man erstmal 7 Joins durchführen muss, um sowas triviales wie Personenstammdaten zusammenzubekommen, dann schätzt man die "unnormale" Form sehr.

Versuchs mal mit Gemütlichkeit Views.

Deine (produktiv-) DB ist fast vollständig 3NF. An die Tabellen will eh keine Sau ran, wegen der 7 Joins. Also basteln wir uns Views, die die ganzen FK-Verknüpfungen kapseln. Wupps, habe ich meine Kunden-View, die mir alles sehr schön darstellt und die 23 Untertabellen wunderbar verbirgt.

Das jetzt noch mit der Auftrags-View verknüpfen, die auch wieder meine Untertabellen und FKs kapselt und -schawuppel- habe ich meine Auftragsübersicht mit einem

Code:

select * 
  from Aufträge a 
  join Kunden k on a.KundenID = k.KundenID
where a.AuftragsDatum between :DateFrom and :DateTo

Ist doch sauber, oder?

Normalerweise transferiert man ja historische Daten aus der Produktiv-DB in eine Reporting-DB, wobei man die 3NF zugunsten einfacher Tabellen (star design vs. snowflake) aufgibt. Bei kleineren DBs lohnt sich das nicht, da verwendet man eben Views zur Darstellung. Und -natürlich- wenn das von der Performance nicht hinhaut, dann hat man (ich jedenfalls) eine redundante Tabelle (also eine Art materialized view), die per Trigger auf dem Stand gehalten wird. Das musste ich mal machen, weil die Auftragsübersicht dann doch in Echtzeit verfügbar sein musste (alle 5 Sekunden ein neuer Auftrag rein, ein bestehender abgearbeitet usw.) Aber das ist dann eine *zusätzliche* und redundante Tabelle.

Beim Programmieren kapselst Du ja das rumgefriemele mit dieser blöden Schnittstelle auch in einer Klasse, damit sich der Anwender damit nicht rumschlagen muss. Wieso machst Du das nicht auch in deiner Datenbank?

[Jumpy]

Zitat von Dejan Vu:

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

Wollte mich eigentlich gar nicht an der Diskussion hier beteiligen, weil glaub ich die ursprüngliche Frage aus dem Blick geraten ist, aber wollte hier nochmal nachhaken. 'M' oder 'F' können doch die Primärschlüssel in der Geschlechter-Tabelle sein. Dann können die doch als Fremdschlüssel in irgendeiner andferen Tabelle stehen. Da kenn ich minestens 3 Software-Produkte (die nicht von uns sind, aber wo ich täglich mit arbeite und die auch im HR-Bereich zum Standard gehören) die sowas gelegentlich verwenden. Wo steht geschrieben, das Primärschlüssel immer Zahlen sein müssen. Und warum ist das dann nicht 3.NF.

Oder hab ich nur die Bemerkung falsch verstanden?


Aber zurück zur Ausgangsfrage. War die nicht sowas wie: Geschlecht in der Personen-Tabelle mitspeichern oder separate PersonenGeschlecht-Tabelle führen, oder?

[bernau]

Was bei solchen Diskussionen auch gerne aus den Augen gelassen wird ist, daß es unterschiedliche Schwerpunkte bei der Entwicklung von Software gibt. Frank (Mavarik) und ich, wir entwickeln Branchen-Software. Diesese Pakete werden von uns seit Jahren (Jahrzehnten) weiterentwickelt. Wir haben gar kein interesse daran, daß "andere" in der Datenbank rumspielen. Für mich ist es daher auch leichter alles im Quellcode zu definieren als in der Datenbank. Schon alleine wegen den Kommentaren, die ich im Quellcode einfügen kann. Ausserdem ist die Updatemöglichkeit um einiges einfacher, da ich mich nicht darum kümmern muss, ob bestimmte Definitionen in der Datenbank bestehen oder geändert wurden.

Auf der anderen Seite gibt es Firmen, die den Schwerpunkt auf die Datenbank setzen und immer mal wieder Software schreiben lassen um die Daten auszuwerten oder zu BEarbeiten. Das ist natürlich ein ganz anderer Ansatz. Denn in dem Fall wird ein Großteil der Geschäftslogik in der Datenbank definiert.

Fazit: Es gibt nicht die "eine optimale Lösung". Unterschiedliche Ansätze -> unterschiedliche Lösungen.