Datenbankmodellierung

[MyRealName]

Ich kenne mich mit deutschem accounting nicht aus, aber hier in Kolumbien ist das mit dem Bank-Accounts nur ein Teil der accounts, die man hat. Hier gibt es den PUC (Plan Unico de Cuentas), wo man zu 8-stelligen Account-Nummern Sachen zuordnet, zum Bsp. MwSt noch zu zahlen. Oder offene Rechnungen. Das sind nicht direkt Bank-Accounts, sondern nur identifikatoren um es in Deinem System auseinander zu halten.

Das sieht eher so aus.
Da gibt es dann diverse Vorgaben wie 1 im Title ist immer Activos wie Waren im Lager. 13 in Grupo (Gruppe) sind Schulden, 11 sind Bankkonten. 14 ist das Inventar. Etc.

[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

[p80286]

Zu der "dynamischen" Struktur:
stell Dir vor Du sitzt im Einkauf eines Autoherstellers. neben Schrauben,Windschutzscheiben usw. bestellst Du auch Räder. Dau auf jede Felgengröße 2 Reifengrößen passen baust Du zwei Tabellen Hauptbauteil, Unterbauteil.
Ob Felge oder Rad in das Hauptbauteil kommen lassen wir mal offen, Reifen kommt in das Unterbauteil. Jetzt kommt jemand auf die Idee die Felge bei einem Lieferanten zu bestellen und den Reifen beim anderen. Ist der Reifen jetzt Hauptbauteil und gleichzeitig Unterbauteil?

Gruß
K-H

[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

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