Geschlecht in extra Tabelle speichern?

[DeddyH]

Und dann hast Du Deinen Code mal nicht zur Hand, willst in der DB etwas ändern und siehst nur "komische Zahlen". Herzlichen Glückwunsch.

[Mavarik]

Zitat von DeddyH:

Und dann hast Du Deinen Code mal nicht zur Hand, willst in der DB etwas ändern und siehst nur "komische Zahlen". Herzlichen Glückwunsch.

Datenbank ändern? Die ist sowieso verschlüsselt. Da hat keiner was dran zu suchen!

[vagtler]

Genau. Wartbarkeit ist was für Pussies.

[Dejan Vu]

Es soll exotische Anwendungen geben, die sogenannte 'Reportingframeworks' verwenden. Gewiss, für altgediente Profis wie Mavarik ist das Kinderkram, aber Amateure wie -sagen wir- SIEMENS setzen doch tatsächlich diese Dinger ein. Da wäre es nun wirklich sinnvoll, wenn man in der Datenbank auch eine Präsentationsschicht hätte (also diese schwachsinnigen VIEW Dinger zum Beispiel), welche einem die kodierten Daten so aufbereitet, daß man die Daten mit einem Reporting-Tool deskriptiv darstellen kann (will sagen: 'Mann' statt false z.B.).

Auch absolute Nischenprodukte, wie z.B. EXCEL, könnten davon profitieren.

Nebenbei sind so bitkodierte Eingeschaften nicht gerade geeignet, um nach ihnen zu selektieren. Es geht zwar, ist aber mühselig.

Zitat von vagtler:

Genau. Wartbarkeit ist was für Pussies.

Yeah! Gibt eben noch richtige Männerprogrammierer.

[Daniel]

Zitat von Dejan Vu:

[...]Gewiss, für altgediente Profis wie Mavarik ist das Kinderkram, aber Amateure wie -sagen wir- SIEMENS setzen doch tatsächlich diese Dinger ein. [...] Auch absolute Nischenprodukte, wie z.B. EXCEL,

?
Wenn Du das Gefühl hast, nicht zu einer sachlichen Diskussion beitragen zu können, dann verschiebe den Beitrag doch bitte auf später. Solche Beitrag sind nicht hilfreich.

[Sir Rufo]

Auf SO würde diese Frage wohl als Off Topic deklariert werden wegen Primarily Opinion Based

Es ist ja wie ein Glaubenskrieg

Ok, die Frage würde sich eigentlich nicht stellen, wenn die Aufgabe komplett analysiert wäre. Nach der Analyse sollte dann feststehen, ob man eine variable Anzahl an Geschlechtern benötigt oder eben nicht.

• Wenn die variabel sein muss, dann zwingend eine Tabelle mit den Geschlechtern und alle Referenzen in den Tabellen bekommen einen Foreign Key darauf.
• Wenn die statisch ist, dann kann der Wert auch einfach durch die Anwendung definiert werden. Ob es dann in der DB ein BitFeld, ein Char oder eine Zahl wird ist völlig egal, die Anwendung muss es nur deuten können.

View oder nicht View

Ist auch eine Glaubensfrage, die sich allerdings nur dann stellt, wenn es direkte Zugriffe auf die Datenbank gibt. Dieses sollte eigentlich schon aus dem Sicherheitsaspekt vermieden werden. Und wenn alle Zugriffe auf den Datentopf eh durch eine Schicht laufen, dann kann diese Schicht auch die passenden Interpretationen für die einzelnen Konsumenten vornehmen.

Der eine braucht für den Mann eine 1 - gut bekommt er, und der ein M - ok und ein anderer benötigt den Wert in der gewählten Sprache - hier hast du "Mann" - und all das kann man aus dem gespeicherten Wert 42 machen und umgekehrt natürlich auch.

Natürlich ist es erheblich schneller, mal eben eine View zusammen klatschen und dann dem Report Zugriff auf diese View zu geben. Aber ist das sicher? Ist das wirklich flexibel? Ist das dann auch besser?

Es kann ausreichend für den Anwendungsfall sein, aber:

Anstatt dem Zugriff auf die View gibt man dem Reporter eine XML/JSON/CSV/was_auch_immer und der baut daraus den Report. Schon ist es dem Report egal, wo er die Daten herbekommt (frisch abgefragt/aus einer Datei/von System x mit Datenbank y und Abfrageparametern z und über die Schnittstelle xyz geliefert).

Und vernünftig programmiert kann man so eine Datenstruktur auch einfach an den Reporter schicken und der weiß, was er damit anfangen kann, bzw. welche Reports diese Daten ausgeben können:

XML-Code:

<invoice>
  ...
</invoice>