Geschlecht in extra Tabelle speichern?

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

[Mavarik]

Zitat von bernau:

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

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

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

Zitat von Mavarik:

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?

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

[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 von Sir Rufo:

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