Datenbankmodellierung

[Ghostwalker]

Zitat von Codehunter:

Das würde hier jetzt jeden Rahmen sprengen, die deutsche Buchhaltung zu erklären ^^ Sagen wir mal so: Wo bei euch eine Schraube eingedreht wird, da wird bei uns erstmal eine Maschinenkonstruktionszeichnung für die Maschine zur Schraubenherstellung angefertigt

Öhm..also die Grundlagen der Buchhaltung (wir reden hier doch von der Doppelten ?) sind doch recht einfach. Wenn ich da ans deutsche Steuerrecht denke.....

Aber zurück zum Thema. Einige allgemeine Tips aus der Praxis:

1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.

2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der DB (und ggf. auf dem Rechner für die DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.

3. Die Strukturen immer so einfach wie möglich halten. Je einfacher das Datenmodell desto leichter ist es,
sie in einem Programm zu handhaben (xtCommerce ist da nicht gerade Vorreiter).

[jobo]

Zitat von Ghostwalker:

1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.

2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der DB (und ggf. auf dem Rechner für die DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.

zu 1:
"Angenehm" an der Redundanz ist ja höchstens, dass "man" "es" als Programmierer (scheinbar) einfacher hat. Gerade im Sinne von Punkt 3. Wirklich "notwendig" sind sie wohl eher selten.

zu 2:
Joins sind kein Hexenwerk. Man kann in den allermeisten Fällen durch Indexierung und meist sinnvolle Einschränkungen der betrachteten Menge auf sehr "kleine" und schnelle Selectergebnisse kommen. Ich empfehle bei dem Modellentwurf nicht auf Anzahl von Joins abzuzielen, sondern auf ein stimmiges Modell. Gerade hier in dem Thread geht es ja offensichtlich um sehr gut beherrschbare Datenmengen.

3 ist sowieso empfehlenswert. In der Praxis macht man bei der Abbildung der Wirklichkeit immer irgendwo einen Cut, ein Kompromis aus Entwicklungsaufwand und gewünschten Ergebnissen, aber auch aus dem Eingabeaufwand, den das erstellte Modell erzwingt.
Wieviel Eingabemasken und Tabellen hat man schon gesehen, die aufwendig befüllt werden müssten, aber am Nutzen und Aufwand (Praktikabilität, Faulheit, Zeitdruck, ..) scheitern.

[Ghostwalker]

Zitat von jobo:

zu 1:
"Angenehm" an der Redundanz ist ja höchstens, dass "man" "es" als Programmierer (scheinbar) einfacher hat. Gerade im Sinne von Punkt 3. Wirklich "notwendig" sind sie wohl eher selten.

Notwendig sind sie heufiger als man denkt. Gerade wenn man auch die Performance und die Systemresourcen
im Auge hat.

Zitat von jobo:

zu 2:
Joins sind kein Hexenwerk. Man kann in den allermeisten Fällen durch Indexierung und meist sinnvolle Einschränkungen der betrachteten Menge auf sehr "kleine" und schnelle Selectergebnisse kommen. Ich empfehle bei dem Modellentwurf nicht auf Anzahl von Joins abzuzielen, sondern auf ein stimmiges Modell. Gerade hier in dem Thread geht es ja offensichtlich um sehr gut beherrschbare Datenmengen.

Ich habe nicht gesagt, das Joins Hexenwerk sind. Ein gutes und stimmiges Modell macht auch viele Joins (die in anderen Modellen notwendig sind), überflüssig. Man sollte aber auch daran Denken, das ein Datenmodell, so gut es auch entwickelt wurde, selten die 2. Version überlebt.

Fakt ist aber, das Joins eine DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.

Zitat von jobo:

3 ist sowieso empfehlenswert. In der Praxis macht man bei der Abbildung der Wirklichkeit immer irgendwo einen Cut, ein Kompromis aus Entwicklungsaufwand und gewünschten Ergebnissen, aber auch aus dem Eingabeaufwand, den das erstellte Modell erzwingt.
Wieviel Eingabemasken und Tabellen hat man schon gesehen, die aufwendig befüllt werden müssten, aber am Nutzen und Aufwand (Praktikabilität, Faulheit, Zeitdruck, ..) scheitern.

[jobo]

Zitat von Ghostwalker:

Fakt ist aber, das Joins eine DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.

Das ist mir etwas zu pauschal (z.B. steigende Nutzerzahl ist per se eine höhere Belastung für jedes Sytem). Für mich gehören JOINS einfach dazu. Aber man muss auch nicht alles zerreden.

[p80286]

Zitat von jobo:

Zitat von Ghostwalker:

Fakt ist aber, das Joins eine DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.

Das ist mir etwas zu pauschal (z.B. steigende Nutzerzahl ist per se eine höhere Belastung für jedes Sytem). Für mich gehören JOINS einfach dazu. Aber man muss auch nicht alles zerreden.

Eine Datenbank ist dafür gemacht, mit Joins umzugehen. Wenn sie die Aufgabe für die sie gemacht ist, nicht bewältigen kann, ist sie schlicht untauglich.

Gruß
K-H

[Delphi.Narium]

Darf ich das mal etwas "dreister" formulieren:

Wenn eine Datenbank mit Joins nicht zurecht kommt, hat der Entwickler was falsch gemacht.

Ein normalisiertes Datenmodell ohne Joins ist (meiner Meinung nach) nicht sinnvoll einsetzbar.

Ok, habe auch schon Systeme gesehen, bei denen gezielt denormalisiert wurde, weil es mit den Joins ... nicht mehr so recht funktionierte und mehrere CPUs und etliche GB Speicher auch nicht ausreichten. Aber das waren Systeme mit mehreren 100 Mio. Datensätzen in dutzenden Tabellen. (Also "geringfügig" komplexer, als das hier besprochene System.)

[jobo]

"..Man stellt also die Kategorien raus.."
Da weiß ich jetzt nicht, was Du damit meinst.
Ich habe da eigentlich nicht von einem konkreten Datenmodell gesprochen, sondern von Vor- und Nachteilen eines Kategorisierungsverfahrens. Damit habe ich mich auf Deine Pläne zur Analyse bezogen.

Mein Gedanke war eigentlich nur folgender:
Statt (evtl. fragwürdige) Kategorisierungen eines Datensatz zu erdenken und zu speichern, einfach nur Fakten abzuspeichern.
Du kaufst Dir ein Auto, ein MB S Klasse Coupé. Wie kategorisierst Du das?
Auto>Coupe (Luxus)?
Wie würde eine Änderung der Kategorisierung irgendwann ausfallen?
Bei diesem Beispiel wirst Du sicher auch nach vielen Jahren noch wissen, was Du tatsächlich gekauft hast und sei die Kategorie, unter der Du das gespeichert hast, noch so schräg.

Also nicht Kategorie Auto, Coupé speichern sondern MB S Klasse Coupé.

Das kannst Du wann und wie auch immer analysieren und kategorisieren.
Wenn es gefällt, kannst Du das auch parallel machen (konkreten Artikel und eine akute Kategorisierung speichern) und später neue und alte (originale) vergleichen.

Und was das Modell angeht, vielleicht macht man das dann in einer separaten Tabelle.

[TigerLilly]

Zitat von Ghostwalker:

1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.

Redundanzen sind nie "angenehm". Der Rest stimmt nur, wenn man mit dBase oder Paradox arbeitet. Für moderne DB-Systeme gilt das zu 99,999% nicht. Redundanzen mögen beim lesenden Zugriff hilfreich sein, dafür hat man beim Schreiben höheren Aufwand. Die Diskussion über die Normalformen ist wie die um Patterns: Sinnvoll. Berücksichtigen. Immer. Muss man abweichen, hat man was nicht verstanden.

Zitat von Ghostwalker:

2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der DB (und ggf. auf dem Rechner für die DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.

Siehe oben - gilt für mySql, MSSQL, Oracle, FireBird, etc nicht. Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die DB gar nicht. Siehe immer auch Execution Plan.

Zitat von Ghostwalker:

3. Die Strukturen immer so einfach wie möglich halten. Je einfacher das Datenmodell desto leichter ist es,
sie in einem Programm zu handhaben (xtCommerce ist da nicht gerade Vorreiter).

Naja, aber was heißt schon "einfach"? Es gibt effiziente und elegante Lösungen, die weniger "einfach" sind und scheinbar einfache Lösungen, die rasch sehr ineffizient werden. Aber wenn man sich an die drei Normalformen hält, ist man eh schon sehr gut bedient.

[rokli]

Zitat von TigerLilly:

Siehe oben - gilt für mySql, MSSQL, Oracle, FireBird, etc nicht. Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die DB gar nicht. Siehe immer auch Execution Plan.

Das ist, denke ich der wesentliche Punkt: "Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die DB gar nicht."

Sonst würde so manche Software gar nicht arbeiten können.