Geschlecht in extra Tabelle speichern?

[p80286]

Kaum ist Wochenende schon ist hier wieder gut was los.
Wie schon erwähnt, kann ich mich weder für eine eigene Tabelle, noch für ein Feld in den Personaldaten entscheiden. 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 Und kommt mir jetzt bitte nicht mit dem Vornamen, das haut zwar meistens hin aber eben nicht immer, für Deutschland nehmen wir Friedel oder weniger altmodisch Chris, es soll auch Franzosen geben, die in Deutschland arbeiten da ist Jean-Marie gar nicht so selten, und bei Koreanern, Japanern, Chinesen ist es extrem selten, das ein Europäischer Personaler die notwendigen Informationen besitzt.

[offtopic]
Ich habe seit mehreren Jahren das Vergnügen wechselnde Softwarepakete einer Branche zu betreuen. Wenn der eine oder andere Programmierer darauf hingewiesen wurde, daß er an die eine oder andere Anforderung nicht gedacht hatte, was oft verständlich ist, da bisher die Kunden diese Anforderung nicht hatten, dann kommt oft die Erwiederung, das braucht man doch nicht. Liebe Leute, nur weil euch das bisher noch nicht über den Weg gelaufen ist, heißt es nicht, daß es das nicht gibt.
[/offtopic]


Gruß
k-H

[bernau]

Zitat von p80286:

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 Und kommt mir jetzt bitte nicht mit dem Vornamen, ....

Binär wohl eher nicht. Aber ein Integer schon genügen verschiedene Zustände darstellen. Aber das steht ja weiter oben.

Zitat von p80286:

[offtopic]
Ich habe seit mehreren Jahren das Vergnügen wechselnde Softwarepakete einer Branche zu betreuen. Wenn der eine oder andere Programmierer darauf hingewiesen wurde, daß er an die eine oder andere Anforderung nicht gedacht hatte, was oft verständlich ist, da bisher die Kunden diese Anforderung nicht hatten, dann kommt oft die Erwiederung, das braucht man doch nicht. Liebe Leute, nur weil euch das bisher noch nicht über den Weg gelaufen ist, heißt es nicht, daß es das nicht gibt.[/offtopic]

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

[p80286]

Zitat von bernau:

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.

[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 von p80286:

Und kommt mir jetzt bitte nicht mit dem Vornamen,

Oh doch! TRWTF is ColdFusion!

Zitat von bernau:

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

[bernau]

Zitat von BUG:

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

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 von bernau:

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.

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 von bernau:

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

[bernau]

Zitat von p80286:

Kaum ist Wochenende schon ist hier wieder gut was los.

Es ist Mittwoch.

[Dejan Vu]

Zitat von p80286:

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.