Geschlecht in extra Tabelle speichern?

[bernau]

Zitat:

Zitat von p80286 (Beitrag 1281146)

Kaum ist Wochenende schon ist hier wieder gut was los.

Es ist Mittwoch. :lol:

[p80286]

Zitat:

Zitat von bernau (Beitrag 1281149)

Wenn es jemand zahlt, dann kann man natürlich alles berücksichtigen. Dann kann man auch die Blutgruppe als Feld berücksichtigen. Man weis ja nie ;-)

Find ich gar nicht soweit hergeholt. HR-Software in Krankenhäusern z.B. sollte diese Möglichkeit beachten. Übrigens geht es nicht um's Bezahlen, sondern um die Einstellung etwas in Erwägung zu ziehen. Ich bin ja auch schon einer der alten Säcke, sobald wir uns auf unsere Erfahrung zurückziehen und alles "neue" per se ablehnen, machen wir was falsch. Darum muß man ja nicht immer topmodisch sein.

Gruß
K-H

P.S.
Für mich hatte sich das WE etwas verschoben.:stupid:

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1281146)

Ein absolutes NoGo is aber die Beschränkung auf ein binäres Feld, da dann ausgelassen wird, daß der Datenerfasser keine Information über das Geschlecht hat

NULL?
Unabhängig davon ist ein Bool-Feld wirklich Quark, denn es geht um keine Ja/Nein-Frage, sondern um eine Eigenschaft, die eben heute nur M/F aber morgen auch M/F/T sein kann oder auch:"Ich kenne mein Geschlecht, aber euch geht das nichts an", was etwas anderes ist, als "Keine Angabe gemacht".

Wichtig ist mir, das Systeme erweiterbar sind. Denn sie werden erweitert. Und sie sollen flexibel sein und nicht proprietär. Aber diese Einschätzung teilen nicht alle.

[bernau]

Hier geht es ja nicht darum, daß man etwas per se ablehnt. Aber wenn sich etwas über Jahre bewährt hat, muss man nicht immer etwas einführen weil andere etwas besser finden. Man muss es für sich abwägen.

[BUG]

Zitat:

Zitat von p80286 (Beitrag 1281146)

Und kommt mir jetzt bitte nicht mit dem Vornamen,

Oh doch! TRWTF is ColdFusion!

Zitat:

Zitat von bernau (Beitrag 1281163)

Aber wenn sich etwas über Jahre bewährt hat, muss man nicht immer etwas einführen weil andere etwas besser finden.

Aber man muss auch nicht sein DRM-System als gutes Datenbankdesign verkaufen :wink: :mrgreen:

[bernau]

Zitat:

Zitat von BUG (Beitrag 1281229)

Aber man muss auch nicht sein DRM-System als gutes Datenbankdesign verkaufen :wink: :mrgreen:

Wer hat wo etwas als gutes Datenbankdesign verkauft? Ich hatte ja geschrieben: "Das" gute Design gibt es nicht. Je nach Anforderung kann es unterschiedliche Lösungen geben. Für den einen so, für den anderen so.

Was hat das ganze mit DRM zu tun?

[Dejan Vu]

Zitat:

Zitat von bernau (Beitrag 1281234)

Wer hat wo etwas als gutes Datenbankdesign verkauft?

Na ja: Bitfelder vorschlagen und Stringkonstanten im Code, als es um Möglichkeiten ging, qualitative Merkmale in einer Tabelle darzustellen, wurde mit Sicherheit nicht vor dem Hintergrund vorgetragen, ein Beispiel für besonders schlechtes Design zu präsentieren und hinter den merkwürdig süffisanten Bemerkungen, dann ja wohl in den letzten 30 Jahren irgendetwas falsch gemacht zu haben (Ja! solange gibt es die Software schon und sie läuft immer noch!), stand auch keine Selbstkritik ob des schlechten Designs.

Aber ich habe mich bestimmt verlesen und alles war ironisch vorgetragene Selbstkritik. :mrgreen:

Aber lass es doch: Ihr setzt Techniken ein, die eben nicht state-of-the-art sind (und auch vor 30 Jahren nicht state of the art waren) und steht dazu. Ist doch ok.

Zitat:

Zitat von bernau (Beitrag 1281234)

"Das" gute Design gibt es nicht.

Doch, gibt es, finde ich zumindest. Aber die konkrete Ausprägung ist von Anwendungsfall zu Anwendungsfall verschieden. Gutes Design zeichnet sich -wie überall- durch Einfachheit, Klarheit, Flexibilität und Erweiterbarkeit aus. Gutes Design setzt die Vorgaben optimal um und erreicht die Ziele auf kürzestem Weg. Verstößt man gegen eines dieses Grundprinzipien, sollte man gute Gründe haben.

[Perlsau]

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?

Ja, das halte ich durchaus für schlau, denn erstens erleichtert es die Dateneingabe, wenn der Anwender nicht jedesmal "männlich" oder "weiblich" eingeben muß, zweitens kannst du leicht ein weiteres "Geschlecht" hinzufügen, z.B. "unbekannt", und drittens kannst du die Geschlechtertabelle auch dahingehend erweitern, daß du eine Standard-Anrede in einer zweiten Spalte mitführst, z.B. "Sehr geehrte Damen und Herren," (für unbekannt), "Sehr geehrte Frau " (für weiblich) und "Sehr geehrter Herr " (für männlich). Daneben kannst du an das Geschlecht noch eine weitere Tabelle mit möglichen Titeln binden, wie z.B. "Generaldirektor" oder "Prof." oder "Dr." usw.

Zitat:

Zitat von AlexII (Beitrag 1280981)

Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle

Nein, deine Methode benötigt weitaus mehr Platz, da ja für jeden einzelnen Datensatz ein weiterer String hinzukommt, während bei der normalisierten Variante die zur Verfügung stehenden Geschlechter nur einmal als String in der Geschlechtertabelle existieren, während in der Personen-Tabelle lediglich die jeweilige ID-Nr. des gewählten Geschlechts abgespeichert wird.

Es gibt natürlich schon Fälle, in denen Normalisierung bis zur letztmöglichen Unterteilung die Performance verschlechtert. Bei derart einfachen Konstrukten wie einer Personen-Tabelle ist Normalisierung aber auf jeden Fall zu empfehlen.