Geschlecht in extra Tabelle speichern?

[AlexII]

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? Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle? Was ist da besser?

Danke!

[Der schöne Günther]

Und was ist mit den Transgenderleuten?

[AlexII]

Zitat:

Zitat von Der schöne Günther (Beitrag 1280982)

Und was ist mit den Transgenderleuten?

Über die reden wir jetzt nicht, es geht um die DB!

[DeddyH]

Ich würde eine eigene Tabelle anlegen. Stell Dir nur vor, die Bezeichnung soll später geändert werden (z.B. "männlich" und "weiblich" statt "Mann" oder "Frau"), ist es dann günstiger, genau 2 Datensätze ändern zu müssen oder u.U. ein paar Millionen? Abgesehen davon bräuchtest Du sonst mindestens einen Check Constraint, wenn Du unterschiedliche Schreibweisen bzw. Tippfehler ausschließen willst.

[Sir Rufo]

Es kommt darauf an ...

Ich lege mir für solche Sachen einen eigenen Typen in der Anwendung an und sorge dafür, dass der immer nur korrekt erzeugt werden kann. Falsche Werte bei der Erzeugung oder beim Lesen aus der DB (hat jemand dran rumgefuscht) sind somit nicht möglich.

In der DB kann ich also ein simples Kennzeichen (Integer, string, whatever) benutzen, die Anwendung interpretiert die Daten richtig oder haut mir eine Exception um die Ohren.

[AlexII]

Zitat:

Zitat von DeddyH (Beitrag 1280985)

Ich würde eine eigene Tabelle anlegen. Stell Dir nur vor, die Bezeichnung soll später geändert werden (z.B. "männlich" und "weiblich" statt "Mann" oder "Frau"), ist es dann günstiger, genau 2 Datensätze ändern zu müssen oder u.U. ein paar Millionen? Abgesehen davon bräuchtest Du sonst mindestens einen Check Constraint, wenn Du unterschiedliche Schreibweisen bzw. Tippfehler ausschließen willst.

Ok... aber Speicherplatz belegt es wohl mehr, oder?

[Mavarik]

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? Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle? Was ist da besser?

Danke!

Wie soll es Platz sparen? Die Information muss doch trotzdem zu jedem Datensatz gespeichert werden. Und warum einen String? Ein Byte sollte doch fürs Geschlecht reichen?
Abgesehen davon das einen weitere Tabelle mehr Platz kostet und Du noch ein INT64 brauchst um das ID zu speichern...

Mavarik

[AlexII]

Zitat:

Zitat von Mavarik (Beitrag 1280989)

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? Würde nicht einfach ein String in der Haupttabelle mit dem Geschlecht nicht weniger Platz einnehmen als ein FK und die extra Geschlechter Tabelle? Was ist da besser?

Danke!

Wie soll es Platz sparen? Die Information muss doch trotzdem zu jedem Datensatz gespeichert werden. Und warum einen String? Ein Byte sollte doch fürs Geschlecht reichen?
Abgesehen davon das einen weitere Tabelle mehr Platz kostet und Du noch ein INT64 brauchst um das ID zu speichern...

Mavarik

Wieso INT64?

[weisswe]

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Tabellenstruktur:
GRUPPE;ID;SPRACHE;Wert;SortNr;Aktiv
Daten:
Geschlecht;m;de;männlich;1;True
Geschlecht;w;de;weiblich;2;True
JaNein;j;de;Ja;1;True
JaNein;n;de;Nein;2;True
...

Diese kann beliebig erweitert werden.

[Lemmy]

lt. Normalisierung sollte das schon in eine eigene Tabelle. Würde ich persönlich nur in bestimmten Fällen machen: Wenn das Geschlecht nur eine optionale Angabe wäre, die in den seltensten Fällen angegeben wird und es wirklich um das letzte Byte ginge.

Ansonsten kauft man sich da nur eine aufwändigere SQL Abfrage ein.

Zitat:

Zitat von DeddyH (Beitrag 1280985)

Ich würde eine eigene Tabelle anlegen. Stell Dir nur vor, die Bezeichnung soll später geändert werden (z.B. "männlich" und "weiblich" statt "Mann" oder "Frau"),

das ist primär eine Sache des Views - nicht der Datenbank.

Zitat:

Zitat von DeddyH (Beitrag 1280985)

ist es dann günstiger, genau 2 Datensätze ändern zu müssen oder u.U. ein paar Millionen?

und dazu dann gegenrechnen wie viel Arbeitszeit vergeudet wird um komplexere SQL-Abfragen zu entwickeln und zu pflegen? Achtung ;-) nicht übersehen!


Grundsätzlich sehe ich das wie SirRufo: In der DB landet ein "Enum" das in der Anwendung dann ausgewertet wird. Werden Fremddatenschnittstellen angeboten, dann kommt ein CheckConstraint auf die Spalte, wenn primär über die eigene Anwendung Daten rein kommen, kann man die Prüfung getrost auch dem ORM überlassen.

Aber: Ein allgemeines richtig oder falsch wird es auf die Frage nie geben....

[p80286]

Nun, von der Theorie her wäre eine eigene Tabelle nicht falsch, insbesonders wenn man an die Nichtvergabe oder eben Transgender denkt.
Platz sparen? die paar Bytes machen den Kohl nicht fett.

Gruß
K-H

[Sir Rufo]

@Lemmy

Wenn ich Fremdaten unterstützen muss, dann nehme ich einen entsprechenden Value-Converter.

Delphi-Quellcode:

TFooConverter = class
public
  function ConvertFrom( Gender : TFooGender ) : TGender;
  function ConvertTo( Gender : TGender ) : TFooGender;
end;

Delphi-Quellcode:

TFooConverter

ist dann der einzige Ort in der Anwendung, der die Übersetzung kennt. Ich brauche also nur an einer Stelle die Übersetzung definieren.

[BUG]

Man kann es auch so sehen: Es sollte eigentlich keine Anfragen geben, bei dem der Enumwert direkt als String vom Nutzer kommt. Also kann man auch problemlos eine ID benutzen (vllt. einen Char für adhoc-Anfragen). Die Übersetzungstabelle kann man dann trotzdem haben, auch wenn man sie nur einmal ausliest.

Zitat:

Zitat von Lemmy (Beitrag 1280994)

das ist primär eine Sache des Views - nicht der Datenbank.

Das ist Ansichtssache: Die Datenbank stellt einen View für die Anwendung bereit.
Idealerweise zeigt die Datenbank einer Anwendung Strings, einer anderen deren erwartete ID und der nächsten das entsprechende chinesische Schriftzeichen.

[Nersgatt]

Zitat:

Zitat von weisswe (Beitrag 1280992)

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

[AlexII]

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Stimmt :thumb:

[bernau]

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Damit fällst du aber direkt auf die Nase, wenn dein Programm mehrsprachig werden soll.

Ich mach es immer so, wie Sir Rufo es vorgeschlagen hat. Einfach eine ID festlegen. Im Programm wird dann schon das Korrekte angezeigt.

[Mavarik]

Zitat:

Zitat von AlexII (Beitrag 1280990)

Wieso INT64?

OK Kommt natürlich auf die Datenbank an!
Welchen Wertebereich hat bei Dir ein AutoInc Feld?

Mindestens aber ein INT32!

Also ist mein Byte für 0=Nichtbelegt 1=Mann 2=Frau 3=Unbestimmt 4=Im Wandel 5=Mann unter 18 6=Frau unter 18 7=Reserviert...

Deutlich platzsparender.

[Mavarik]

Zitat:

Zitat von AlexII (Beitrag 1281000)

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Stimmt :thumb:

LOL..

Deine Frage war:

Zitat:

Zitat von AlexII (Beitrag 1280981)

Spart man damit Platz in der DB oder eher nicht?

Die Antwort ist nein...

Und ob das ein gutes Datenbank Design ist oder nicht - lassen wir mal außen vor. Da gibt es hier schon unterschiedliche Meinungen.

[BUG]

Zitat:

Zitat von Mavarik (Beitrag 1281003)

Also ist mein Byte für 0=Nichtbelegt 1=Mann 2=Frau 3=Unbestimmt 4=Im Wandel 5=Mann unter 18 6=Frau unter 18 7=Reserviert...

Und da ist sie, die Verletzung der 1. NF :shock:
Das Alter im Geschlecht zu speichern halte ich für keine gute Idee. In relationalen Datenbanken würde ich, wenn ich nicht gerade Dokumente speichere, niemals zwei Werte in eine Spalte schreiben.

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1281001)

Ich mach es immer so, wie Sir Rufo es vorgeschlagen hat. Einfach eine ID festlegen. Im Programm wird dann schon das Korrekte angezeigt.

Konstante Texte gehören nicht in eine Datenbank...
Vielleicht hat man sich in Version 1. vertippt und will das in Version 1.1 korrigieren... Ich will bestimmt nicht durch X Datenbanken suchen um da nachträglich den richtigen Text rein zu bringen...

[Mavarik]

Zitat:

Zitat von BUG (Beitrag 1281007)

Zitat:

Zitat von Mavarik (Beitrag 1281003)

Also ist mein Byte für 0=Nichtbelegt 1=Mann 2=Frau 3=Unbestimmt 4=Im Wandel 5=Mann unter 18 6=Frau unter 18 7=Reserviert...

Und da ist sie, die Verletzung der 1. NF :shock:
Das Alter im Geschlecht zu speichern halte ich für keine gute Idee. In relationalen Datenbanken würde ich, wenn ich nicht gerade Dokumente speichere, niemals zwei Werte in eine Spalte schreiben.

OK mit "Im Wandel" und "unter 18" war eigentlich auch nur als Witz gedacht... 1:0 für Dich bei "unter 18" habe ich nicht nachgedacht!

[Nersgatt]

Zitat:

Zitat von bernau (Beitrag 1281001)

Zitat:

Zitat von Nersgatt (Beitrag 1280999)

Zitat:

Zitat von weisswe (Beitrag 1280992)

Ich habe für solche Daten eine eigene Tabelle angelegt - jedoch nicht nur für eine Wertegruppe.
Diese kann man dann auch erweitern - zum Beispiel mehrsprachig.

Wenn ich auf solche Konstrukte stoße, stellen sich mir jedes Mal die Nackenhaare auf.
Ich verwende für solche Dinge immer eigene Tabellen. Über den Platzbedarf hab ich mir dabei nie Gedanken gemacht. Ein ordentliches Datenbankdesign ist mir deutlich wichtiger, als ein paar gesparte Byte.
Bei der Tabelle kann man dann auch problemlos weitere Felder anfügen für verschiedene Zwecke:

ID	Bezeichnung	Kuerzel	Anrede
1	männlich	m	Sehr geehrter Herr
2	weiblich	w	Sehr geehrte Frau

Außerdem hat der Kunde so die Möglichkeit die Texte nach eigenem Gusto anzupassen.

Damit fällst du aber direkt auf die Nase, wenn dein Programm mehrsprachig werden soll.

Wieso, ich kann doch in einer anderssprachen Version die Daten in der Geschlechtertabelle ändern.

Das Problem habe ich aber auch nicht, weil meine Software nur im Deutschsprachigen Raum eingesetzt wird (und es aus verschiedenen Gründen sehr unwahrscheinlich ist, dass sich das mal ändert). Allerdings habe ich teilweise noch ein Feld "sprache_id" um die Texte in diversen Sprachen durch den User pflegen zu können. Beim Beispiel mit dem Geschlecht wäre das z.B. um die Anrede für einen spanischen Kunden auf der Rechnung in seiner Landessprache machen zu können.
In dem Fall muss natürlich Fallback-Mechanismen einbauen, für den Fall dass das Geschlecht in der gewünschten Sprache nicht gepflegt ist.

[bernau]

Zitat:

Zitat von Mavarik (Beitrag 1281008)

Zitat:

Zitat von bernau (Beitrag 1281001)

Ich mach es immer so, wie Sir Rufo es vorgeschlagen hat. Einfach eine ID festlegen. Im Programm wird dann schon das Korrekte angezeigt.

Konstante Texte gehören nicht in eine Datenbank...
Vielleicht hat man sich in Version 1. vertippt und will das in Version 1.1 korrigieren... Ich will bestimmt nicht durch X Datenbanken suchen um da nachträglich den richtigen Text rein zu bringen...

Vieleicht habe ich mich missverständlich ausgedrückt. Ich mache es in dem Sinne so wie du. Eine ID wird festgelegt 1=Mann 2=Frau. In der Datenbank steht also nur (0,1,2) Im Programm ist fest hinterlegt (in verschiedenen Sprachen) welches Wort zur ID angezeigt werden muss.

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1281017)

Vieleicht habe ich mich missverständlich ausgedrückt. Ich mache es in dem Sinne so wie du. Eine ID wird festgelegt 1=Mann 2=Frau. In der Datenbank steht also nur (0,1,2) Im Programm ist fest hinterlegt (in verschiedenen Sprachen) welches Wort zur ID angezeigt werden muss.

Nein, habe Dich schon verstanden und Dir eigentlich zugestimmt.

[Sir Rufo]

Zitat:

Zitat von Mavarik (Beitrag 1281008)

Zitat:

Zitat von bernau (Beitrag 1281001)

Ich mach es immer so, wie Sir Rufo es vorgeschlagen hat. Einfach eine ID festlegen. Im Programm wird dann schon das Korrekte angezeigt.

Konstante Texte gehören nicht in eine Datenbank...
Vielleicht hat man sich in Version 1. vertippt und will das in Version 1.1 korrigieren... Ich will bestimmt nicht durch X Datenbanken suchen um da nachträglich den richtigen Text rein zu bringen...

Diese Annahme ist falsch, denn es gibt nun mal Konstanten (natürlicher und unnatürlicher Art) die in so eine Datenbank zwangsläufig rein müssen.

• Währungscode
• Geschlecht (biologisch)
• ...

Jetzt ist es aber wichtig, dass die Datenbank die Information speichern kann und die Anwendung diese Informationen auch korrekt interpretiert.

Ein Vertipper in der Datenbank/Anwendung ist doch nicht tragisch. Wenn in der Version 1 das Zeichen N für männlich genutzt wurde und nun in Version 1.1 das korrigiert werden soll nach M, dann baue ich das einfach in die Anwendung mit ein, dass eben das Zeichen N und M eben männlich bedeuten. Das ist auch relativ simpel, denn bei der Erzeugung des Wertes, wird dann aus dem N ein M gemacht. Fertig ist die Laube und alles wird wieder schick.

Das Hauptproblem besteht in den meisten Anwendungen, dass einfach nur der repräsentierende Wert (der ist ohne Kontext) verarbeitet wird und nicht im Zusammenhang mit dem Kontext.

Delphi-Quellcode:

'M' <> 'm' <> 'N' <> 'n'

Benutzt man das aber mit dem Kontext zusammen, wird es klarer und einfacher im Umgang, weil man auch eine Interpretation mit einfliessen lassen kann (String mit 1 Zeichen, als Uppercase, 'N' => 'M')

Delphi-Quellcode:

 TGender.Create( 'M' ) = TGender.Create( 'm' ) = TGender.Create( 'N' ) = TGender.Create( 'n' )

Generell ist und bleibt es natürlich eine Frage der Anwendung und des allgemeinen Kontextes, ob man eine erweiterbares oder festes Geschlechtsmerkmal benötigt. Gemeinsam bleibt allerdings der Kontext, denn nur so wird aus einem Wert eine verwertbare Information.

Wenn die Information erweiterbar ist, dann habe ich auch einen Foreign Key und über den wird das Update gemacht. Dann trage ich das an einer Stelle ein und die gesamte Datenbank ist wieder im Lot

[Lemmy]

Zitat:

Zitat von Sir Rufo (Beitrag 1280997)

@Lemmy

Wenn ich Fremdaten unterstützen muss, dann nehme ich einen entsprechenden Value-Converter.

da dachte ich mehr an Schnittstellen auf die du keinen Einfluss hast, sprich anderen schieben dir Daten rein...

Zitat:

Zitat von BUG (Beitrag 1280998)

Zitat:

Zitat von Lemmy (Beitrag 1280994)

das ist primär eine Sache des Views - nicht der Datenbank.

Das ist Ansichtssache: Die Datenbank stellt einen View für die Anwendung bereit.

könnte es sein, dass wir aneinander vorbeireden? Als Views meinte ich nicht die DB-Views sondern die Visualisierung der Daten. WEnn wir nicht aneinander vorbeireden: Ein Interessanter Standpunkt - so habe ich das noch nie gesehen....

[Dejan Vu]

Das Geschlecht ist aus konservativer Sicht eine binärinformation: Mann/ kein Mann
bzw. aus feministisch-konservativer Sicht: Frau/keine Frau.

Für ewiggestrige Katholikenmuslime (oder wahlweise auch osteuropäische Enggestirne) würde es also reichen, das Geschlecht als Bit/Boolean abzulegen. Das ist die zweitkompakteste* Art, diese Information zu verpacken. Das hat natürlich den entscheidenden Nachteil, das eine Erweiterung des eigenen Horizontes nur mit erheblichem Aufwand bei der Änderung DB-Struktur möglich ist.

Da es sich hier -allgemein gesehen- um ein qualitatives** Merkmal handelt (ich bin 'A', 'B', 'C' oder 'D') würde ich auch zu einer einfachen Kodierung raten, dessen Präsentation (also Text) in einer separaten Tabelle untergebracht ist. Diese Kodierung ist ja unabhängig von der Information an sich und macht den Code nur lesbar. Hier würde ich allerdings davon abraten, in dieser 'Geschlechtertabelle' gleich noch Anrede etc. unterzubringen: Das gehört dort nicht hin: Anreden haben ja nur indirekt etwas mit dem Geschlecht zu tun, sondern eher mit dem Status der Person.

Ob man hier Bytes oder Integer verwendet, ist eigentlich wurscht, weil die paar Bytes Speicherplatz den Kohl auch nicht fett machen. Besser wäre eine gleichförmige Behandlung aller qualitativer Merkmale über alle Tabellen.

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

(*) die kompakteste Art wären zwei Tabellen, für jedes Geschlecht eine eigene Tabelle.
(**) im Gegensatz zu quantitativen Merkmalen, wie Alter, Adresse etc.

[AlexII]

Zitat:

Zitat von Dejan Vu (Beitrag 1281027)

Für ewiggestrige Katholikenmuslime (oder wahlweise auch osteuropäische Enggestirne) würde es also reichen, das Geschlecht als Bit/Boolean abzulegen. Das ist die zweitkompakteste* Art, diese Information zu verpacken. Das hat natürlich den entscheidenden Nachteil, das eine Erweiterung des eigenen Horizontes nur mit erheblichem Aufwand bei der Änderung DB-Struktur möglich ist.

Jah... und solange die ewiggestrigen WESI Toilettenhersteller bei dem dualen System bleiben, werde ich Bit/Boolean bevorzugen. :thumb:

[Sherlock]

Sobald Du mit einem Reportingtool drüber musst, wirst Du glücklich sein, wenn Du nicht zig Subreports erzeugen musst. Eine vernünftige Abwägung der Vor- und Nachteile der Normalisierung solltest du schon vornehmen (ich mach mich gerade unbeliebt, ich weiss). Aber wenn man erstmal 7 Joins durchführen muss, um sowas triviales wie Personenstammdaten zusammenzubekommen, dann schätzt man die "unnormale" Form sehr. Sowohl als Supportmitarbeiter, als auch jemand der mit der weiteren Nutzung der Daten in statistischen Auswertungen à la QlikView und Reportingtools wie Crystal (heisst das noch so?) beschäftigt ist.

Sherlock

[Sir Rufo]

Zitat:

Zitat von Lemmy (Beitrag 1281022)

Zitat:

Zitat von Sir Rufo (Beitrag 1280997)

@Lemmy

Wenn ich Fremdaten unterstützen muss, dann nehme ich einen entsprechenden Value-Converter.

da dachte ich mehr an Schnittstellen auf die du keinen Einfluss hast, sprich anderen schieben dir Daten rein...

Das soll sich mal einer trauen, dann fliegen aber die Zähne wie Popcorn :mrgreen:

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