Geschlecht in extra Tabelle speichern?

[Dejan Vu]

Zitat:

Zitat von Sherlock (Beitrag 1281039)

Aber wenn man erstmal 7 Joins durchführen muss, um sowas triviales wie Personenstammdaten zusammenzubekommen, dann schätzt man die "unnormale" Form sehr.

Versuchs mal mit Gemütlichkeit Views.

Deine (produktiv-) DB ist fast vollständig 3NF. An die Tabellen will eh keine Sau ran, wegen der 7 Joins. Also basteln wir uns Views, die die ganzen FK-Verknüpfungen kapseln. Wupps, habe ich meine Kunden-View, die mir alles sehr schön darstellt und die 23 Untertabellen wunderbar verbirgt.

Das jetzt noch mit der Auftrags-View verknüpfen, die auch wieder meine Untertabellen und FKs kapselt und -schawuppel- habe ich meine Auftragsübersicht mit einem

Code:

select * 
  from Aufträge a 
  join Kunden k on a.KundenID = k.KundenID
where a.AuftragsDatum between :DateFrom and :DateTo

Ist doch sauber, oder?

Normalerweise transferiert man ja historische Daten aus der Produktiv-DB in eine Reporting-DB, wobei man die 3NF zugunsten einfacher Tabellen (star design vs. snowflake) aufgibt. Bei kleineren DBs lohnt sich das nicht, da verwendet man eben Views zur Darstellung. Und -natürlich- wenn das von der Performance nicht hinhaut, dann hat man (ich jedenfalls) eine redundante Tabelle (also eine Art materialized view), die per Trigger auf dem Stand gehalten wird. Das musste ich mal machen, weil die Auftragsübersicht dann doch in Echtzeit verfügbar sein musste (alle 5 Sekunden ein neuer Auftrag rein, ein bestehender abgearbeitet usw.) Aber das ist dann eine *zusätzliche* und redundante Tabelle.

Beim Programmieren kapselst Du ja das rumgefriemele mit dieser blöden Schnittstelle auch in einer Klasse, damit sich der Anwender damit nicht rumschlagen muss. Wieso machst Du das nicht auch in deiner Datenbank?

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1281049)

Deine (produktiv-) DB ist fast vollständig 3NF. An die Tabellen will eh keine Sau ran, wegen der 7 Joins. Also basteln wir uns Views, die die ganzen FK-Verknüpfungen kapseln. Wupps, habe ich meine Kunden-View, die mir alles sehr schön darstellt und die 23 Untertabellen wunderbar verbirgt.

Das jetzt noch mit der Auftrags-View verknüpfen, die auch wieder meine Untertabellen und FKs kapselt und -schawuppel- habe ich meine Auftragsübersicht mit einem

Code:

select * 
  from Aufträge a 
  join Kunden k on a.KundenID = k.KundenID
where a.AuftragsDatum between :DateFrom and :DateTo

Ist doch sauber, oder?

OMG...

Da bin ich doch froh, dass ich für sowas immer BitFelder nehme und diese mit einen Const Array im Code verknüpfe...

Mavarik

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1281060)

Da bin ich doch froh, dass ich für sowas immer BitFelder nehme und diese mit einen Const Array im Code verknüpfe...

*Wofür* nimmmst Du Bitfelder und *was* verknüpfst Du mit einem Const Array im Code?

BTW: Was Du 'OMG' nennst, heißt in der Industrie 'Standard'. Nur mal so ;-)

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1281065)

Zitat:

Zitat von Mavarik (Beitrag 1281060)

Da bin ich doch froh, dass ich für sowas immer BitFelder nehme und diese mit einen Const Array im Code verknüpfe...

*Wofür* nimmmst Du Bitfelder und *was* verknüpfst Du mit einem Const Array im Code?

Ein Beispiel könnte sein!:

Delphi-Quellcode:

Var
  Bitfeld : Byte;
begin
  if (BitFeld and $80) = $80 
    then Gender := Sprache[AktSprache,ID_Herr]
    else Gender := Sprache[AktSprache,ID_Frau];

  if (BitFeld and $40) = $40
     then Kunde := true
     else Kunde := false;
end;

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

Zitat von DeddyH (Beitrag 1281083)

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

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

Zitat von vagtler (Beitrag 1281094)

Genau. Wartbarkeit ist was für Pussies. :mrgreen:

Yeah! Gibt eben noch richtige Männerprogrammierer.

[Jumpy]

Zitat:

Zitat von Dejan Vu (Beitrag 1281027)

und eine Kodierung wie 'M' oder 'F' ist nun totaler Quark, weil dadurch die Tabelle nicht mir in 3NF ist.

Wollte mich eigentlich gar nicht an der Diskussion hier beteiligen, weil glaub ich die ursprüngliche Frage aus dem Blick geraten ist, aber wollte hier nochmal nachhaken. 'M' oder 'F' können doch die Primärschlüssel in der Geschlechter-Tabelle sein. Dann können die doch als Fremdschlüssel in irgendeiner andferen Tabelle stehen. Da kenn ich minestens 3 Software-Produkte (die nicht von uns sind, aber wo ich täglich mit arbeite und die auch im HR-Bereich zum Standard gehören) die sowas gelegentlich verwenden. Wo steht geschrieben, das Primärschlüssel immer Zahlen sein müssen. Und warum ist das dann nicht 3.NF.

Oder hab ich nur die Bemerkung falsch verstanden?


Aber zurück zur Ausgangsfrage. War die nicht sowas wie: Geschlecht in der Personen-Tabelle mitspeichern oder separate PersonenGeschlecht-Tabelle führen, oder?

[bernau]

Was bei solchen Diskussionen auch gerne aus den Augen gelassen wird ist, daß es unterschiedliche Schwerpunkte bei der Entwicklung von Software gibt. Frank (Mavarik) und ich, wir entwickeln Branchen-Software. Diesese Pakete werden von uns seit Jahren (Jahrzehnten) weiterentwickelt. Wir haben gar kein interesse daran, daß "andere" in der Datenbank rumspielen. Für mich ist es daher auch leichter alles im Quellcode zu definieren als in der Datenbank. Schon alleine wegen den Kommentaren, die ich im Quellcode einfügen kann. Ausserdem ist die Updatemöglichkeit um einiges einfacher, da ich mich nicht darum kümmern muss, ob bestimmte Definitionen in der Datenbank bestehen oder geändert wurden.

Auf der anderen Seite gibt es Firmen, die den Schwerpunkt auf die Datenbank setzen und immer mal wieder Software schreiben lassen um die Daten auszuwerten oder zu BEarbeiten. Das ist natürlich ein ganz anderer Ansatz. Denn in dem Fall wird ein Großteil der Geschäftslogik in der Datenbank definiert.

Fazit: Es gibt nicht die "eine optimale Lösung". Unterschiedliche Ansätze -> unterschiedliche Lösungen.