Datenbankmodellierung

[Asura]

Zitat:

Zitat von jobo (Beitrag 1399278)

Eine Kategorisierung und eine Bewertung wären durch einen separaten Prozess und Datenspeicher zu bewerkstelligen.
Ist das Problem klar, kann man natürlich hergehen und beides parallel Speichern, Fakten und (subjektive Kategorie. So läuft man jedenfalls nicht Gefahr, eine sagen wir verkürzte Interpretation von Fakten zu speichern, deren Ursprung einem irgendwann (z.B. bei der Neukategorisierung) fehlt. Fakten sind im übrigen viel leichter einzutragen. Nicht im Sinne von Verfügbarkeit (auf der Lastschrift vom Supermarkt findet man natürlich nicht alle Artikel, die man gekauft hat), aber Sinne der Abwägung (Grundbedarf oder Luxus). Das ist sehr subjektiv, schwankt wahrscheinlich mit der Zeit und führt zu einer eher mäßigen Kategorisierungsqualität.

Ich hoffe ich habe das richtig verstanden:

Man stellt also die Kategorien raus und weißt diese nur der Buchung zu.
Also kann eine Buchung mehrere Kategorien besitzen, die im gleichen Level (Hauptkategorie vs. Nebenkategorie) sich befindet. Damit aber später das Programm nach einer Neukategorisierung weiß, welchen Zuweisung nun wirklich die neue ist, nimmt er praktisch den neuesten Eintrag (Also anhand der Eintragungszeit) der Kategorisierung einer Buchung.
So bin ich flexibel, was die Kategoriezuweisung angeht.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1399280)

Zitat:

Zitat von Ghostwalker (Beitrag 1399276)

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:

Zitat von Ghostwalker (Beitrag 1399270)

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:

Zitat von Ghostwalker (Beitrag 1399270)

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:

Zitat von Ghostwalker (Beitrag 1399270)

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:

Zitat von TigerLilly (Beitrag 1399346)

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.