Geschlecht in extra Tabelle speichern?

[Daniel]

Zitat:

Zitat von Dejan Vu (Beitrag 1281095)

[...]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 :mrgreen:

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>

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1281102)

Diesese Pakete werden von uns seit Jahren (Jahrzehnten) weiterentwickelt. Wir haben gar kein interesse daran, daß "andere" in der Datenbank rumspielen

Tja Gerd, vielleicht machen wir die letzten 30 Jahre etwas falsch? Und unsere Erfahrung mit tausenden Installationen beim Kunden inkl. der daraus resultierenden Hotline sind aus modernen Gesichtspunkten völlig überholt. Das wir versuchen die Anrufe von Kunden durch eine "selbst heilende" und stabile Software zu minimieren. Vielleicht liegt es daran, dass wir mit unserer Software schon länger unsere Brötchen verdienen als diese tollen-Software-Design-Regeln existieren? Oder das wir schon 10 Jahre unsere Software auf dem Markt hatten bevor MySQL überhaupt erfunden wurde.

Ok, hätten wir doch mal lieber unsere Software umgestellt, alle Information inkl. unserem Datenbankdesign und unserer Logik offengelegt. Zwar hätte wahrscheinlich eines der Skript-Kids eine Freeware raus gebracht die unsere Software ersetzt. Aber dafür wären wir das Uptodate... Ein geregeltes Einkommen wird sowieso überschätzt.

Nur meine 2 Cents - (Schreibt man dann, oder? Keine Ahnung was das bedeutet, klinkt aber immer cool)

Mavarik

Edit: Ups.. Sorry 100% Offtopic

[DeddyH]

In meinen Augen gilt für diesen Beitrag #41 ebenfalls. Man muss ja nicht immer jedem Hype hinterherlaufen, aber weiterhin Lochkarten stanzen, weil das seit zig Jahren funktioniert, ist auch nicht das Gelbe vom Ei.

[bernau]

Zitat:

Zitat von DeddyH (Beitrag 1281112)

In meinen Augen gilt für diesen Beitrag #41 ebenfalls. Man muss ja nicht immer jedem Hype hinterherlaufen, aber weiterhin Lochkarten stanzen, weil das seit zig Jahren funktioniert, ist auch nicht das Gelbe vom Ei.

Aber wenn für den Anwendungsfall die Lochkarten reichen und es keinen Bedarf gibt, weil es seit Jahren sicher läuft, dann ist das schon OK. ;-)

Den Leierkasten gibt es seit 100 Jahren mit Lochkarten. Mittlerweile bestimmt auch mit MP3. Aber der mit Lochkarten funktioniert der immer noch ;-)

Ach ja. OffTopic.

[AlexII]

Zitat:

Zitat von Mavarik (Beitrag 1281111)

Tja Gerd, vielleicht machen wir die letzten 30 Jahre etwas falsch? ..... Oder das wir schon 10 Jahre unsere Software auf dem Markt hatten bevor MySQL überhaupt erfunden wurde.

Habt ihr etwa schon das biblische Alter erreicht?

[bernau]

Zitat:

Zitat von AlexII (Beitrag 1281127)

Zitat:

Zitat von Mavarik (Beitrag 1281111)

Tja Gerd, vielleicht machen wir die letzten 30 Jahre etwas falsch? ..... Oder das wir schon 10 Jahre unsere Software auf dem Markt hatten bevor MySQL überhaupt erfunden wurde.

Müsst ihr aber alt sein... Habt ihr etwa schon das biblische Alter erreicht?

:pale:

Ach. Man ist immer nur so alt, wie man sich fühlt :lol:

[Dejan Vu]

So habe ich das noch gar nicht betrachtet. Wobei ich auch Branchensoftware schreibe/geschrieben habe, aber immer mit der Prämisse: Lass den Kunden so unabhängig wie möglich sein und so flexibel wie möglich. Das ist natürlich kein erfolgreiches Geschäftsmodell, da der Kunde lernt, sich selbst zu helfen.

Eine derartig proprietäre Lösung wurde von mir und meinen Kollegen bzw. anderen Entwicklern und Architekten immer mit einem Facepalm bedacht. Aber da es sie gibt und sie funktionieren, sind sie immer noch 1000x besser als jede Theorie.

Das man ersthaft hinter proprietären Ansätzen steht, ist mir allerdings neu. Sie aus Sachzwängen (Legacy Code) mitzuschleppen.. Nun ja, wer hat keine Leiche im Keller...

Nur: Bitte nicht darstellen als 'gute' Lösung... Man muss in Delphi schließlich auch keine OOP umsetzen, aber keiner stellt sich hin und propagiert prozedurale Programmierung als echte Alternative. Nur wenn ich legacy software habe, muss ich eben damit leben, das sie so ist, wie sie ist.

Ach #41: Ja, ich hielt meinen etwas ironischen Beitrag für sachdienlich und der Diskussion förderlich. Es tut mir leid, das ich keinen Besenstiel verschluckt habe. Die alten Haudegen, hinter denen echte 30 Jahre Anwenderentwicklung stehen, kann man mit einem Beitrag schließlich nicht verunsichern.

PS: Ich schlage mich hier gerade mit einer Bankingsoftware herum, die entwickelt wurde, bevor Datenbanken frei verfügbar waren (kann man sich nicht vorstellen). Sie sind Weltmarktführer und die Entwickler sollten eigentlich geteert und gefedert werden, aus benannten Gründen (passt also voll zum Thema). So. Sie *sind* Weltmarktführer. Ist damit die Architektur gut? Nein, ist sie nicht. Sie ist grauenhaft. Aber sie ist da.

Da fällt mir immer der alte Spruch ein: "Fresst Sch**se, 1 Mio Fliegen können nicht irren".

Zitat:

Zitat von Sir Rufo (Beitrag 1281106)

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.

Diese Schicht würde sich dann z.B. 'DWH' nennen. In kleineren Anwendungen macht man das aber nicht, sondern geht direkt auf die Daten. Die 'Sicherheit' wird durch Zugriffskontrolle auf Serverebene sichergestellt. Hier einen Appserver zu installieren, würde wieder bedeuten, den einfachen allgemeinen Lösungen wie EXCEL, CrystalReports etc. einen Riegel vorzuschieben.

Bei wirklich großen Anwendungen, die auf eine Reporting-DB verzichten, gebe ich Dir aber Recht. Meist ist das aber wieder so ein Legacy-Zeugs.

Bei der Diskussion sollte man unterscheiden: "Was *ist* bereits da und funktioniert (aus dem Nähkästchen plaudern)" vs. "Wie sollte man es heute machen"...

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

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

Zitat von p80286 (Beitrag 1281146)

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

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