Datenbankmodellierung für Berichtswesen-tool

Minimalist

Neuer Benutzer
Beiträge
4
Hallo erstmal,

ich arbeite schon ne Weile mit Datenbanken, bin aber kein Experte auf dem Gebiet. Ich würde mich freuen, wenn ihr mir bei meinem Problem helfen könnt.

In meiner Firma habe ich eine recht große MySQL-Datenbank, die Kundendaten auf ungefähr 30 Tabellen enthält. Mit dieser möchte ich eine Art Controlling- / Berichtswesen-Tool in PHP realisieren.

Der User soll zuerst eine Ansicht, also alle Spalten / Daten der Kunden auswählen, die er später angezeigt haben will. Anschließend definiert er noch einen Filter um genau die Datensätze zu bekommen, die er für seine Auswertung braucht.

Das Ganze ist also recht dynamisch und schließt praktisch alle Tabellen mit ein, die in irgendeiner logischen Relation zur Kundentabelle stehen. Einen Query mit PHP zu erzeugen, der 30 Tabellen miteinander joint, scheint mir da keine gute Methode zu sein...

Da die Thematik noch recht neu für mich ist, suche momentan ich nach Ansätzen und Best Practices um dieses Projekt möglichst sauber zu realisieren. Vor allem frage ich mich, ob sich sowas überhaupt mit relationalen Datenbanken richtig realisieren lässt. Wären objektorientierte / objektrelationale DBs eine Alternative?

Hat schon jemand Erfahrungen mit solchen Tools gemacht und noch Tipps für mich?

Danke schonmal für eure Antworten!
 
Werbung:
30 Tabellen ist für Datenbanken (nun ja, außer vielleicht für MySQL) eigentlich kein Thema.
Das macht mir schonmal Hoffnung, die Daten nicht migriere zu müssen. :D Gibt es zufällig ein Pattern o.ä. mit dem das 'sauber' zu realiseren ist?

Verstehe ich dich richtig, wenn du sagst... Du möchtest dynamisch 1 bis n Tabellen aus einem Pool von ca. 30 Tabellen joinen?
Ja, so könnte man es sagen. Dazu kommt noch, dass die vorher ausgewählten Filter auf die Menge angewendet werden soll.
 
Join alle 30 Tabellen (Left- oder Inner / jenachdem was benötigt ist) und lass einfach die Spalten wegfallen die nicht gebraucht werden? Bei einem guten Datenbankdesign und den richtigen Indizes dürfte man keine Performace-Einbußen spüren. Die Where-Clause dynamisch zusammen zubauen dürfte dann eig. ein Leichtes sein :)
 
Join alle 30 Tabellen (Left- oder Inner / jenachdem was benötigt ist) und lass einfach die Spalten wegfallen die nicht gebraucht werden? Bei einem guten Datenbankdesign und den richtigen Indizes dürfte man keine Performace-Einbußen spüren. Die Where-Clause dynamisch zusammen zubauen dürfte dann eig. ein Leichtes sein :)

PG würde aus seinem Plan dann sogar nicht benötigte Tabellen wegoptimieren...
 
Hmm...

Das hört sich alles recht machbar an. Vielleicht gibts es in Sachen Normalisierung und Indizierung noch etwas nachholbedarf, aber wenn MySQL das meiste optimiert, dann könnte das funktionieren.
 
Hmm...

Das hört sich alles recht machbar an. Vielleicht gibts es in Sachen Normalisierung und Indizierung noch etwas nachholbedarf, aber wenn MySQL das meiste optimiert, dann könnte das funktionieren.

Von MySQL hab ich nicht geschrieben. das hat keinen wirklich funktionierenden Planner/Optimizer, kein Kostenmodell, keine Statistiken, nichts.
 
Na ich hoffe doch nicht... Oder kann PG zwischen n:n und n:m Beziehungen unterscheiden? Das würde mich jetzt aber mal interessieren.... :) Wie entscheidet PG denn wann eine Tabelle "wegoptimiert" werden kann? :)

Wenn Du im Select nur eine Tabelle angibst, aber 5 weitere left joinst, und auch keine Where-Condition sich auf die gejointen bezieht, dann sind die wohl nicht relevant für das Resultat, oder?
 
Mit dieser möchte ich eine Art Controlling- / Berichtswesen-Tool in PHP realisieren.
Also in erster Linie die Verknüpfung von in Relation stehender Daten gewürzt mit ein wenig Analyse?

Vor allem frage ich mich, ob sich sowas überhaupt mit relationalen Datenbanken richtig realisieren lässt.
Welche Schwierigkeiten erwartest du? Und vor allem, warum? Nur weil das Konzept relationaler Date

Wären objektorientierte / objektrelationale DBs eine Alternative?
Sicher. Und welchen Nutzen würde dir eine solche Datenbank gegenüber einer relationalen liefern?

Das hört sich alles recht machbar an. Vielleicht gibts es in Sachen Normalisierung und Indizierung noch etwas nachholbedarf, aber wenn MySQL das meiste optimiert, dann könnte das funktionieren.
Es gibt kein DMBS, das ein schlechtes Datenbankdesign nachträglich gesund optimieren kann.

Gibt es zufällig ein Pattern o.ä. mit dem das 'sauber' zu realiseren ist?
Ohne weiter Informationen ist das Standard-Pattern die BCNF.
 
Werbung:
Zurück
Oben