Komplexe Datenbanken

[Lemontee]

Hallo,
ich entwickel gerade eine komplexe Datenbank.
Vorerst beschränke ich mich auf die wichtigsten Teile:

-Materialvorgaben
-Zeitvorgaben

Diese Vorgaben sollen den Nutzern dann ermöglichen
einfache Angebote zu erstellen.

Ich hatte eigentlich vor die Material und Zeitvorgaben
jeweils in eine eigene Datenbank zu packen, weil
jede für sich ja aus mehreren Tabellen besteht.
So hätte ich schonmal 2 Datenbanken.

Die Angebote wollte ich dann auch in einer eigenen Datenbank
speichern.

Für temporäres Zwischenspeichern würde ich gern auch noch eine Datenbank
anlegen. Oder wäre es besser sowas in der jeweiligen Datenbank zu erledigen?

Ist das so praktikabel?
Wenn ich mich hier im Forum umsehe arbeiten die meisten Leute
immer nur mit einer Datenbank. Ist es denn richtig mehrere
Datenbanken für ein Programm zu verwenden?

Wo genau liegen denn da die Probleme? Was wären die Schwachstellen?

[dimitri]

Ist es denn richtig mehrere Datenbanken für ein Programm zu verwenden?

Kommt drauf an, welchen Datenbankhersteller du verwendest. Bei Oracle ist es das definitiv nicht, dort würde man mehrere Schemata verwenden, um logisch voneinander unabhängige ER Modelle voneinander zu trennen. Bei mysql z.B. gibt es keine Schemata dort würde man dann eben eine neue Datenbank anlegen.

Ich hatte eigentlich vor, die Material und Zeitvorgaben jeweils in eine eigene Datenbank zu packen, weil jede für sich ja aus mehreren Tabellen besteht. So hätte ich schonmal 2 Datenbanken.

Aus welchen Gründen möchtest Du das denn trennen? Deiner Argumentation kann ich nicht ganz folgen. Ein zusammengehöriges ER-Modell gehört in ein Schema (oder auch Datenbank je nachdem welche DB Du verwendest).

Dim

[Christian Marquardt]

Des Weiteren muss man dann auch entsprechend viele DB-Verbindungen in der Anwendung verwalten. Auch kann es schwierig sein, gewünschte übergreifende Abfragen an u.U. mehrere DBs zu richten

[Lemontee]

Als Datenbanksystem verwende ich Firebird SQL.

Die Datenbankverbindungen seh ich weniger als Problem an, da die Anwendung in NET entwickelt wird und da Verbindungen nur so lang offengehalten werden wie sie benötigt werden. Könnte höchstens etwas overhead im Arbeitsspeicher erzeugen..

Der Grund für die Trennung ist, das das doch mit der Zeit sehr Unübersichtlich wird, oder? Ich geh vom Extremfall aus - wenn der Anwender in einem Jahr bis zu ein paar Hundert Angebote schreibt.

Wird denn die Datenbank nicht auch irgendwann langsam wenn alles in eine große Datei gequetscht wird?

Außerdem soll das Programm erweiterungsfähig sein, zB. später eine Kunden- und Projektverwaltung bekommen. Usw.. Usf..

Um die Daten logischer Trennen zu können wollte ich sie so auseinander halten.
Das größte Problem wäre aus einer Datenbank auf eine andere, übergeordnete zuzugreifen, oder?

[dimitri]

und da Verbindungen nur so lang offengehalten werden wie sie benötigt werden.

Davon würd ich dringendst abraten. Datenbankenverbindungen werden im allgemeinen so lange offen gehalten bis das Programm wieder beendet wird. Ansonsten wartet der User bei jeder Aktion erst mal bis überhaupt die Verbindung steht.

Ich geh vom Extremfall aus - wenn der Anwender in einem Jahr bis zu ein paar Hundert Angebote schreibt.

Versteh ich nicht. Du legst aber nicht für jedes Angebot eine Tabelle an oder? Ansonsten sind Datenbanken dafür gemacht zig Milliarden von Datensätzen zu verwalten. Deine paar hundert Einträge sollten also grade noch so gehen

Wird denn die Datenbank nicht auch irgendwann langsam wenn alles in eine große Datei gequetscht wird?

Ich würde Dir dringendst raten dich mit Datenbanken im allgemeinen und deiner Firebird im speziellen zu beschäftigen. Frei nach dem Motto: Verstehe was Du nutzen möchtest.

Außerdem soll das Programm erweiterungsfähig sein, zB. später eine Kunden- und Projektverwaltung bekommen. Usw.. Usf..

Stop. Großer Fehler. Nicht das Programm muss erweiterungsfähig sein, sondern dein ER-Modell. D.h. wir sprechen jetzt noch nicht mal von physikalischen Tabellen, sondern von Entitäten die sich in der 3. NF befinden und dann ggf. aus performancegründen noch etwas De-Normalisiert wurden.

Du darfst nie die Daten an einem Programm ausrichten - das Programm hat sich immer nach den Daten zu richten (Bedeutet auch Finger weg von diversen objektrelationalen Erweiterungen und den ganzen Mappern die das zeugs generieren!). In 5 jahren wird deine .Net Anwendung vielleicht nicht mehr existieren und die Daten müssen dann vielleicht von einer Webanwendung gelesen und geschrieben werden die in einer komplett anderen Sprache entwickelt wurde.

Um die Daten logischer Trennen zu können wollte ich sie so auseinander halten.

Das macht wenn überhaupt aber auch nur dann Sinn, wenn sie auch fachlich und technisch nichts miteinander zu tun haben.

Mein Rat: Erstelle dir auf dem Papier ein ER-Modell, denk noch nicht mal an eine Datenbank o.ä. und mach das vernünftig so das es deinen fachlichen Anforderungen gerecht wird. Wenn das steht kann man mal dran denken überhaupt einen Create Table Befehl abzusetzen - vorher nicht.

Dim

PS: Ich würd mir auch mal überlegen, ob Du nicht PostgeSQL oder gleich die Oracle XE verwendest. Sind beide deutlich leistungsfähiger als Firebird und auch die Doku ist erheblich besser (vor allem bei Oracle).

[O. Helper]

und da Verbindungen nur so lang offengehalten werden wie sie benötigt werden.

Davon würd ich dringendst abraten. Datenbankenverbindungen werden im allgemeinen so lange offen gehalten bis das Programm wieder beendet wird

Alle aktuellen Datenzugriffskomponenten wie ADO / ADO.NET verwenden "Connection Pooling", d.h. wenn eine Applikation eine Connection zu einem SQL Server beendet, wird diese im Pool eine Zeit lang vorgehalten und für andere Verbindungen wieder recyceld. Von daher ist es kein Performanceproblem, die Verbindung zwischenzeit wieder zu trennen.
Bei Web-Applikation ist das sogar der Normalfall, das für jede Aktion eine Verbindung aufgebaut, Daten selektiert o.ä. und die Verbindung gleich wieder geschlossen wird.

[dimitri]

Alle aktuellen Datenzugriffskomponenten wie ADO / ADO.NET verwenden "Connection Pooling", [...]
Bei Web-Applikation ist das sogar der Normalfall, das für jede Aktion eine Verbindung aufgebaut, Daten selektiert o.ä. und die Verbindung gleich wieder geschlossen wird.

Ok dann ist es ja auch kein schließen der Connection, sondern ein zurückgeben in den Pool.

Dim

[Lemontee]

Davon würd ich dringendst abraten. Datenbankenverbindungen werden im allgemeinen so lange offen gehalten bis das Programm wieder beendet wird. Ansonsten wartet der User bei jeder Aktion erst mal bis überhaupt die Verbindung steht.

Net, insebesondere die ADO-Komponente verwendet das "disconnected data set". Die Verbindung zur Datenbank wird nicht offengehalten, sondern es wird eine temporäre Datenbank erzeugt, mit der gearbeitet, und erst bei Bedarf wieder in die originale Datenbank zurückgeschrieben (meist nach einem festen Zeitintervall, oder nach mehreren Änderungen).

Ich speziell werde die Daten in Zeitintervallen temporär abspeichern um Datenverluste zu minimieren. Und erst richtig speichern wenn der Benutzer sein ok gibt. (also auf Speichern drückt...)

Du legst aber nicht für jedes Angebot eine Tabelle an oder?

Doch, für jedes Angebot hab ich immer eine neue Tabelle die in etwa so aussieht:

Pos.Nr.
Beschreibung
+
-
Berechnung
...

Die Tabelle arbeitet mit Material und Zeitvorgaben..
Diese Tabellen wiederum werden in Projekte geordnet, und diese Projekte werden Kunden zugeordnet. Also das ist wirklich schon ein komplexeres Programm.

Stop. Großer Fehler. Nicht das Programm muss erweiterungsfähig sein, sondern dein ER-Modell. D.h. wir sprechen jetzt noch nicht mal von physikalischen Tabellen, sondern von Entitäten die sich in der 3. NF befinden und dann ggf. aus performancegründen noch etwas De-Normalisiert wurden.

Genau aus dem Grund bestehem Material und Zeitdaten allein schon aus mehreren Tabellen.

Nicht das Programm muss erweiterungsfähig sein, sondern dein ER-Modell.

Vollkommen richtig.. Die vorliegenden Tabellen bilden auch das Grundmodell. Das ganze Modell soll nur bei Bedarf noch erweitert werden, in Prinzip auf einer höheren abstrakten Ebene...

Also ich hab jetzt die 1. Ebene:
Materialdatenbank - Zeitdatenbank - Kundendatenbank

Darauf baut die Ebene 2. Ebene auf:
Angebotsdatenbank - Verkaufsdatenbank

Auf dieser wiederum zu einem späteren Zeitpunkt eine weitere 3. Ebene:
Projektverwaltung

Jede dieser Ebenen kann immer nur aus Elementen der Ebene darunter bestehen.. Also die 2te Ebene zB. nur aus Elementen der 1. Es handelt sich also um ein Schichtenmodell. Kann es sein das meine teils noch Objektorientierte Sicht auf diese Dinge falsch ist? Vielleicht versteht man jetzt weshalb ich die Datenbanken zum Teil trennen wollte..


Dazu ist vielleicht noch zu sagen das die Datenbank embedded ist. Das Programm wird eine Einzelplatzanwendung, ohne Vernetzung oder mehrere Benutzer. Externe Daten werden über Import / Export Schnittstellen verwaltet.

Danke erstmal für die ausführlichen Informationen..

[dimitri]

Doch, für jedes Angebot hab ich immer eine neue Tabelle die in etwa so aussieht:

Oh je bitte nicht. Mach das besser so:
Angebot (Beschreibung, Erstellungsdatum, Ersteller und weitere Kopfdaten)
Angebotspunkt(FK auf Angebot, Beschreibung aus Materialtabelle, Mengenangabe,Einzelpreis, etc.)

Es handelt sich also um ein Schichtenmodell. Kann es sein das meine teils noch Objektorientierte Sicht auf diese Dinge falsch ist?

Absolut. In einer relationalen Datenbank gibt es keine Schichten, keine Vererbung und auch keine Objekte.
Allerdings ist deine Sicht auch nicht objektorientiert, denn würde man deine Angebotslogik auf OOP ummünzen, dann wäre jedes neue Angebot eine neue Klasse die zur Laufzeit generiert, kompiliert und von der anschließend genau ein Objekt instanziiert wird.

Also weg von Schichten und dem ganzen Zeugs. Mach dein ER-Modell in der 3 NF und dann mach deine Anwendung, welche aus den Schichten Datenbank, sowie Logik und Oberfläche (MVC Pattern) besteht.

Dim

[Lemontee]

Angebot (Beschreibung, Erstellungsdatum, Ersteller und weitere Kopfdaten)
Angebotspunkt(FK auf Angebot, Verweis auf die Materialtabelle, Mengenangabe)

Wie soll das gehen?
Also genauer im Detail:

Es gibt Kopfdaten, die hab ich noch nichtmal erwähnt..
Angebot: Müller & Co.. Bauvorhaben 1
Datum:
letzte Änderung:
Bearbeitung:

Dazu gibt es dann aber eine Tabelle mit den zugehörigen Positionspunkten. Diese Punkte sind für jedes Angebot anders, da sie sich aus örtlichen Gegebenheiten berechnen:

Pos | Bennenung | Abstiche | Größe | verwendetes Material | Arbeitszeit

Allerdings ist deine Sicht auch nicht für objektorientiert, denn würde man deine Angebotslogik auf OOP ummünzen, dann wäre jedes neue Angebot eine neue Klasse die zur Laufzeit generiert, kompiliert wird und von der anschließend genau ein Objekt instanziiert wird.

Autsch.. Genauso hatte ich mir das gedacht. Ich arbeite ja mit einer MDI-Anwendung. Ich hab mir gedacht für jedes Form einfach ein neues DataSet anzulegen. Also sollte ich nur ein Globales verwenden? Die Tabellen werden sogar über Programmcode angelegt. Bis zum ersten mal speichern erfolgt nicht ein Datenbankzugriff (beim erstellen einer neuen Tabelle).



Also gut.. ich arbeite das ganze er-modell jetzt nochmal aus..
Programmlogic, Daten und GUI trenne ich allerdings schon seit Jahren.. xD

[dimitri]

Diese Punkte sind für jedes Angebot anders, da sie sich aus örtlichen Gegebenheiten berechnen:

Ja und? Über einen FK Constraint werden sie mit dem Angebotskopf verbunden.

Ach ja: Wie machst das eigentlich bei der Datensicherung? Embedded bedeutet ja, dass die DB mit ins Programm eingebunden wird. Aber was pasiert, wenn Du z.B. eine neue Version auslieferst? Angebote sind rechtsverpflichtend und dürfen nicht einfach weggeworfen werden.

Dim

[Lemontee]

Ja und? Über einen FK Constraint werden sie mit dem Angebotskopf verbunden.

mhm.. die Tabelle für ein Angebot ist auch immer indiziert, da die einzelnen Punkte in weiteren Tabellen weiter verwendet werden..

Ich wollts gar nicht so ausführlich schreiben.. Aber es handelt sich um eine Tabelle mit den Aufmaßen für ein bestimmtes Bauprojekt. Dazu dann eine Tabelle welche die erechneten Werte für Zeitvorgaben verwendet, eine Tabelle welche die Aufmaßdaten für Materialberechnung verwendet. Und diese ganzen Daten werden dann zentral in der Projektverwaltung für Angebotsschreiben verwendet. Mit einem klick auf Drucken soll sich dann das ganze Angebot drucken lassen ohne das man lästig nochmal alle Daten zusammensuchen müsste..

Die Materialien hingegen sind wieder in einer extra globalen Tabelle, welche über längere Zeiträume konstant bleibt.

Naja.. da steckt wohl noch ne Menge Ausarbeitungszeit drin.. Denn ich hab mir das wohl etwas falsch vorgestellt. Mit Datenbanken hatte ich noch nicht so viel zu tun, beschäftige mich erst seit diesem Monat damit und muss erstmal meine ganzen Objektorientierten Gedanken beiseite lassen... frrr ^^

Noch eine Anmerkung: Die globalen Datenbanken mit den Vorgaben für Zeit und Material dienen mehr als eine Art Bibliothek auf die man bei der Angebotsberechnung zugreifen kann - aber nicht muss..
Bei der Erstellung eines Angebots verwende ich eine Listenansicht, und über Comboboxen werden aus den Material und Zeitvorgaben Vorschläge gemacht. Aber eben nur Vorschläge, keine Verbindlichkeiten. Weswegen Angebote und Stammdaten immer voneinander getrennt sind.

Wie machst das eigentlich bei der Datensicherung?

Embedded bedeutet hier das das dbms ins programm eingebunden ist.
Die Datenbankdateien werden jedoch einzeln gespeichert.

Ganz grob gesagt gibts einige Dateien:

-exe | Programmdatei
-DLLs | für das DBMS
-FDB | Dateien welche die Daten repräsentieren (Datenbank)


Bei einer neuen Programmversion werden nach Möglichkeit nur die DLLs und die Exe-Datei aktualisiert. Die Daten bleiben allerdings wie sie sind. Falls es doch mal Änderungen an der FDB-Datei geben sollte wird ein Converter geschrieben.

Der Converter verwendet ganze einfach die Import / Export Funktionalität weil diese sowieso benötigt wird. Richtig?

[dimitri]

Mit Datenbanken hatte ich noch nicht so viel zu tun, beschäftige mich erst seit diesem Monat damit und muss erstmal meine ganzen Objektorientierten Gedanken beiseite lassen... frrr ^^

Allerdings. Es gibt übrigends auch keine globalen Tabellen und ein FK Constraint kann, muss aber nicht indiziert sein.

Dim

[Lemontee]

So, ich mal wieder.. Ich habe in der Zwischenzeit viel gelernt und jetzt den Teilbereich "Material" normalisiert. Vielleicht könnt ihr es einmal kurz übersehen und mir mal sagen ob das wirklich die richtige Richtung ist..

Ich hab die Kürzel verwendet:
PS = Primärschlüssel
FS = Fremdschlüssel
VT = Verknüpfungstabelle

Die Tabellennamen sind fett.. unter ihnen immer die Attribute..

Material
ID (PS), Name, Beschreibung, Verbrauch, VerbrauchseinheitsID (FS)

Verbrauchseinheit
ID(PS), Name

Lagereinheit
ID(PS), MaterialID (FS), EinzelmengentypID (FS), Einzelmenge, LiefermengentypID (FS), Liefermenge, PreiseinheitsID (FS), Preis, Anmerkung

Die Fremdschlüssel aus der Lagereinheit sind immer verweise auf weitere Tabellen..

Dann hab ich noch ein paar Tabellen zur Kategorisierung...
Zum Beispiel eine für Hersteller.

Hersteller
ID(PS), ...weitere Attribute

Und diese dann über Verknüpfungstabellen mit den Materialdaten verknüpft:

VTHerstellerMaterial
HerstellerID(FS), MaterialID(FS)

Das ist nur ein Teilausschnitt von allen Tabellen, aber der Rest funktioniert im Prinzip genauso.. Ich hoffe das ist wirklich eine Normalisierung und nicht einfach nur Zeitverschwendung gewesen.