Datenbankentwurf - wie vorgehen?

[Dsimon24]

Hallo!

habe folgendes Vorhaben, jedoch keine Ahnung, wie ich vorgehen soll:

Ich benötige eine Datenbank die mehrere Benutzerkonten verwaltet.
Jeder Benutzer soll die Möglichkeit haben, mehrere Autos zu verwalten.
Für jedes Auto sollen variable und fixe Kosten gespeichert werden.

Leider bin ich im Bereich der Datenbank ein absoluter Anfänger.
Brauche ich da mehrere Datenbanken, oder
eine mit mehreren Tabellen oder eine ganz andere Struktur?

Vielleicht kann mir im groben und ganzen einer sagen, wie ich in etwa vorgehen kann. In
welchem Bereich ich mich für so ein Vorhaben einlesen muss - oder einfach Tipps geben?

Gruß, David

[fanderlf]

Ich würde vorschlagen Du überlegst Dir erstmal ganz ohne Technik was Dein Programm können soll. Denke Dir dazu erstmal die Entitäten aus die in Deinem Programm vorkommen werden und welchhe Eigenschaften sie haben werden.

z.B.:

Benutzer:
- ID
- Username
- Passwort
- Email
...

Fahrzeug:
- ID
- Marke
- Modell
...

Kosten: (hier kann man eventuell auch schon variable und fixe kosten komplett trennen wenn das in deiner Anwendung mehr Sinn macht statt eines Typ Feldes)
- ID
- Typ (variabel, fix)
- Betrag
- Grund
...

Und dann überlegst Du Dir in welcher Beziehung diese zueinander stehen. Danach würde ich diese erstmal in der Programmiersprache meiner Wahl runter tippen und die Kernfunktionen auf diesen Klasse implementieren.

Du musst immer daran denken dass eine Datenbank lediglich eine mögliche Art der Speicherung Deiner Daten ist. Deswegen würde ich erst den Programmcode schreiben und mich dann um das Speichern und Laden der Daten kümmern. Bei einem neuen Programm mit dem DB Schema anzufangen halte ich für die falsche Idee. Dazu kommt noch dass man Objekte und deren Beziehungen in einer Datenbank relational speichert, was nicht ganz zur objektorientierten Welt der meisten Programmiersprachen passt. Für den Start kannst Du die Objekte auch erstmal nur im Arbeitsspeicher "ablegen" - sprich Dir merken. Wenn Du dann etwas hast was auch den Neustart eines Programms überlebt kannst Du die Daten auch erstmal in eine Datei serialisieren (JSON/XML - das ist allerdings nicht Threadsafe spielt aber anfangs beim Spielen und entwickeln keine Rolle). Das ist alles noch wesentlich einfacher und schneller zu ändern als eine Datenbank. Eine alternative wäre an dieser Stelle auch einen OR-Mapper zu verwenden. Das ganze Themas ist aber schon um einiges komplexer als Dateien. Du wirst allerdings spätestens dann an die Grenzen von Dateien stoßen, sobald mehrere Benutzer auf die schreibend Daten zugreifen wollen.

[Ralf Jansen]

Bei einem neuen Programm mit dem DB Schema anzufangen halte ich für die falsche Idee

Da du pauschal von neuem Programm spricht wiederspreche ich mal.
Bei einer Unternehmenssoftware die vermutlich Jahrzehnte mit den Daten arbeiten wird, die initiale Anwendung aber üblicherweise nicht so lange hält, und natürlich weitere Anwendung in Zukunft dazukommen die über andere Wege auch mit den Daten arbeiten soll wäre es genau die falsche Idee Persistierung so zu schreiben weil es gerade mit der genutzen Technik/Framework/Programmiersprache/Paradigma am einfachsten ist rächt sich später fast immer.

Model-First würde ich nur bei der Vorgabe schnell und kostengünstig bei der Entwicklung aber bei begrenzter Funktionalität und Lebensdauer der Anwendung(inkl. Daten)empfehlen.

[tömmel]

... ich auch ... aber sowas von!

Nu stell er sich vor er hat nach 10Jahren mal richtig richtig viele Daten... und dann war der Entwurf wirlich Mist....

Die Welt besteht ja zum Glück nicht nur noch aus Apps fürs Telefon...

[fanderlf]

Ich würde trotzdem immer noch genau das Vorschlagen. Die Domäne ist auf jeden Fall wichtiger als irgendeine Persistenzschicht. CQRS inklusive Eventsourcing ist gerade schwer im kommen und ich sehe viele Vorteile darin Domain Events zu speichern. Wenn es ab zu sehen ist dass Software lange läuft würde ich auf jeden Fall diesen Weg gehen. Die Persistenz der Events an sich ist trivial. Alle anderen Tabellen in der Datenbank sind rein zum Lesen und daher flüchtig und können zu jedem Zeitpunkt wieder hergestellt werden. Dazu kommt noch dass ich mit diesem Mechanismus nach den Events alle möglichen Persistenz- und Leseschichten befüttern kann. Also zum Beispiel auch einen Suchindex oder eine zweite Datenbank in einer komplett anderen Technologie. Falls nötig kann man die Events auch noch über einen Message Bus an andere Systeme schicken, dann bin ich nicht mal mehr an meine Runtime gebunden.

Das wollte ich dem Threadersteller allerdings nicht zumuten und ist wohl auch eher eine Glaubensfrage Vermutlich kommts zudem noch auf das Unternehmen und das Problem an. Ich wollte nur verdeutlichen dass der Threadersteller sich erstmal wirklich Gedanken um seine Domäne machen soll und hinterher irgendwelche Technik designen.

[defo]

Interessant, von diesem schwer kommenden CQRS habe ich noch nie was gehört.
Hätte ich ohne diesen Beitrag vermutlich erst mitbekommen, wenn es mir beim Überholen über die Füße gefahren wäre.

Nagut, Glaubenskriege sind ja was ganz anderes als über die Vor und Nachteile von Software Architekturen zu reden. Der TE würde vermutlich mit Datenmodell getriebener Entwicklung als auch mit einem JPA / Persistenz Tool keinen Fehler machen, sondern einfach Erfahrung auf der einen oder anderen Seite sammeln.
Ich persönlich finde einen Datenbankansatz sehr gut, habe aber noch nie ein Projekt anders umgesetzt. Insofern bin ich bei anderen Verfahren ein Blinder, der von Farben redet, ich höre allerdings, was die Farbsichtigen so erzählen.
Ach und der TE ist sicher schon über alle Berge.

[tömmel]

@defo

ich ignoriere sowas auch weitestgehend. Nur wirklich tolle große Projekte mit viel Geld können sich meinetwegen erstmal mit solch modernen Konzepten auseinandersetzen.

Objektdatenbanken sind ja auch so super... Nur beschütze mich der Herr davor.

(Könnte mir vorstellen das da am Flughafen Berlin/Brandenburg ....)

[fanderlf]

Das würde ich so nicht unterschreiben. Das Trennen des lesenden vom schreibenden Zugriff (CQRS) hat ganz große Vorteile. Gerade wenn die Anwendung etwas größer wird und schon mal mehrere Teams dran arbeiten. Dort tritt nämlich dann oft das Problem auf dass zu viele Daten in den Kontext einer Tabelle geschrieben werden. Die Daten sind weder gut fürs Lesen noch fürs Schreiben geeignet. Beim Schreiben möchte ich ein möglichst klares DRY Datenmodell haben. Das ist allerdings beim Lesen hinderlich, da bei einer gewissen Datenmenge oder Anfragenfrequenz JOINs fast nicht mehr zu realiseren sind. Da wünscht man sich dann denormalisierte Datenbanktabellen auf die ich vom Code möglichst einfach zugreifen kann.

Zudem würde ich auch sagen dass man nicht einfach blind durch die Welt laufen sollte. Klar muss man nicht jeden Trend mitmachen. Aber man sollte Trends zumindest kennen und sich Gedanken drüber machen ob einem das im Unternehmen etwas helfen könnte oder nicht. Und da das Thema mittlerweile auch schon in diversen .Net Zeitschriften vertreten würde ich sagen, dass schon einge Gewisse Basis vorhanden ist. Ich habe von dem Thema das erste mal vor 3 Jahren gehört So ganz neu ist das also auch nicht mehr.

Noch dazu würde ich zwischen technischen Frameworks und grundsätzlichen Architekturentscheidungen die in keinster Weise von der Technologie abhängig sind deutlich unterscheiden. CQRS + EventSourcing ist ein Architekturpattern welches mir keinerlei Vorgaben über die Technologie macht. Objektdatenbanken sind im Endeffekt nur eine Persistenzschicht wie jede andere der zig möglichen und hat ihre Vorteile und Schwächen.

Natürlich ist CQRS + EventSourcing auch nicht für jedes Problem die Lösung. Aber wer sich etwas mit DDD beschäftigt und eine Applikation entwickelt die etwas an Domänenlogik besitzt, dem würde ich empfehlen zumindest mal einen Blick drauf zu werfen. Am Ende ist es kein Hexenwerk, es hilft aber deutlich beim Trennen der Verantworlichkeiten. Und das ist es doch was wir am Ende alle wollen, oder nicht?