Datenbankmodellierung

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