Einfaches Datenbankmodell

[Delphi.Narium]

Warum gibt es in der TBL_Firma Adresse, Strasse, Nr. und Postleitzahl, wenn die Tabelle doch auch noch 'nen Verweis auf TBL_Adressen hat?

Da scheint mir was redundant zu sein.

Adressen gehören in TBL_Adressen. TBL_Firma bekommt nur 'ne Fremdschlüssel auf TBL_Adressen. Aber die Adressdaten werden dort nicht abgelegt.

Nr. ist vom Typ Int. Was soll das sein? Die Hausnummer? Was wäre dann mit der Hausummer 1a?

Die Tabellen TBL_Firma und TBL_Konto scheinen in dem Bild nicht vollständig enthalten zu sein, könntest Du das noch nachbessern?

[Schokohase]

So eine Firma kann ja auch mal umziehen dann ändert sich eben die Adresse oder wird gekauft und benennt sich um (z.B. von CodeGear nach Embarcadero).

Bei diesem Datenmodell würde so eine Änderungen auch die historischen Rechnungen betreffen, obwohl die Dokumente da etwas anderes sagen werden, denn die sind statisch.

FYI: Grundsätzlich ist es ein sehr schlechter Ansatz eine Anwendung mit dem Datenbank-Modell zu beginnen. Uncle Bob sagt dazu: "The database is a detail and not the center of our application." und weiterhin, dass die Auswahl der konkreten Datenbank erst ganz zum Schluss fällt.

[Delphi.Narium]

Echt jetzt?

Bei Datenbankanwendungen halte ich das Datenmodell für wesentlich. Wenn das stimmt, wird die entsprechende Software geschrieben. Hat die letzten Jahrzehnte immer gut geklappt.

Allerdings sind die meisten Kolleginnen und Kollegen, die es andersherum versucht haben, mehr oder weniger kläglich gescheitert oder haben sowohl Software, als auch Datenmodell permanent anpassen müssen.

Aber vielleicht hab' ich ja auch Pech gehabt und nur die Ausnahmefälle kennen gelernt

Jedenfalls halte ich es hier konkret für durchaus sinnvoll, sich erstmal Gedanken über die benötigten Daten und die Datenhaltung zu machen und dann die entsprechende Software zu schreiben.

[Schokohase]

Ja.

Hmmm, Datenbankanwendung - daher wird das wohl kommen, denn eine Datenbankanwendung muss eine Datenbank haben, sonst ist es ja nur eine Anwendung.

Oder ist es tatsächlich einfach nur eine Anwendung und egal, wo und wie diese die Daten speichert, solage es passiert?

Noch wahrscheinlicher ist es wohl, dass diese Datenbankanwendung ihren Ursprung in den Datenmodulen und den sich darauf tummelnden RADz-Fatz-Connection-Query-Komponenten. Die laufen tatsächlich nur mit Datenbanken, was es aber nicht besser macht.

Das wird auch der Grund für die Aversion gegen Unit-Tests sein, denn diese sind bei so einem Ansatz gar nicht möglich. (Bitte nicht mit Integration-Tests verwechseln)

Wenn man an dem RAD-Ansatz mit Connection-Query-Komponente auf Form/DateModul festhalten will, dann rüclt man tatsächlich die Datenbank in das Zentrum der Anwendung.

Will man das nicht, dann muss man hier einen gänzlich anderen Weg gehen, sonst passiert genau das, was du beschrieben hast.

[Delphi.Narium]

@Schokohase

Das Grundgerüst der Datenhaltung ist die Datenbank.
Die Daten werden dazu ausmodelliert.

Mit was für 'ner Software man dann auf die Daten zugreift ist wurscht.

Man kann auf ein Datenmodell mit 'ner Software zugreifen, die über eine GUI verfügt.
Man kann auch mit Batchprogrammen drauf zugreifen.
Oder ein Webinterface dazu bauen.
Oder ...

Die Daten sind immer in der gleichen Datenbank mit einem Datenmodell.

Das Wesentliche sind die Daten. Die Software ist dazu da, um vereinfacht an die Daten zu kommen.

Delbor will eine Datenbankanwendung schreiben.
Welche Datenbank(en) genutzt wird/werden soll, steht im Eingangspost.

Die Datenbankkomponenten dienen dem Zugriff auf die Datenbank. Sie sind nicht die Ursache für die Nutzung einer Datenbank.

Und wenn man mal mit "richtigen" Daten gearbeitet hat (so ein paar millionen Datensätzen in diversen Tabellen) dann wird man sehr schnell feststellen, dass man zuerst eine vernünftige Analyse benötigt, dann ein Datenmodell dazu und erst dann anfängt die Software zu implementieren.

Und Unit-Tests gehen auch bei Datenbankanwendungen. Damit kann man alle Funktionen des Programmes testen, einschließlich der ggfls. in der Datenbank enthaltenen Logik (Trigger, Datenbankprozeduren ...)

Man muss es halt können

Der Ansatz ist: Die Software dient zur Bearbeitung der Daten in der Datenbank.

Und nicht:

Die Datenbank ist ein notwendiges Übel, um die vom Programm verabeiteten Daten irgendwie speichern zu können, um sie ggfls. später nochmal zur Verfügung zu haben.

Ich halte Delbors Ansatz, sich erstmal Gedanken über die benötigten Daten und deren sinnvolle Ablage zu machen, für absolut korrekt. Meiner Meinung nach ist das ein professioneller Ansatz.

[Schokohase]

@Delphi.Narium

Wenn du bei einem "Unit-Test" die Trigger der Datenbank mittestest dann hast du per Definition keinen Unit-Test sondern einen Integration-Test.

Das sind zwei paar Schuhe.

Ein Unit-Test testet die kleinst mögliche Einheit (z.B. eine öffentliche Methode) ohne irgendwelche externen Abhängigkeiten (z.B. Datenbanken). Wenn es Abhängigkeiten gibt, dann werden diese per Mock bereitgestellt. So ein Unit-Test ist klein und schnell und wird bei jeder Quelltext-Änderung ausgeführt (siehe TestInsight).

Ein Integration-Test ist wesentlich fetter als der Unit-Test aufgrund der Abhängigkeiten (z.B. von der Datenbank) die jetzt auch mit im Boot sind. Weil diese gewöhnlich (wesentlich) länger dauern als die Unit-Tests, werden diese auch nur zu bestimmten Zeitpunkten ausgeführt (Einchecken im Repository, Release-Build, etc.)

Wer es weiß der kann es auch.

Eine Datenbank ist kein Übel, sondern Mittel zum Zweck und manchmal auch völlig überflüssig und ein paar schlichte Dateien hätten es auch getan.

Natürlich macht man sich Gedanken was für Datenstrukturen die Anwendung benötigt um ihre Aufgabe zu erledigen, aber eben völlig losgelöst von dem eventuell zu verwendenden Datenbank-System.

Hat man diese Strukturen und die Anwendung, dann ist die Datenbank-Anbindung nur noch ein Spaziergang und das Datenbank-System wird austauschbar.

Das ist professionell.

[Delphi.Narium]

Zitat von Schokohase:

@Delphi.Narium

Wenn du bei einem "Unit-Test" die Trigger der Datenbank mittestest dann hast du per Definition keinen Unit-Test sondern einen Integration-Test.

Das sind zwei paar Schuhe.

Ein Unit-Test testet die kleinst mögliche Einheit (z.B. eine öffentliche Methode) ohne irgendwelche externen Abhängigkeiten (z.B. Datenbanken). Wenn es Abhängigkeiten gibt, dann werden diese per Mock bereitgestellt. So ein Unit-Test ist klein und schnell und wird bei jeder Quelltext-Änderung ausgeführt (siehe TestInsight).

Ein Integration-Test ist wesentlich fetter als der Unit-Test aufgrund der Abhängigkeiten (z.B. von der Datenbank) die jetzt auch mit im Boot sind. Weil diese gewöhnlich (wesentlich) länger dauern als die Unit-Tests, werden diese auch nur zu bestimmten Zeitpunkten ausgeführt (Einchecken im Repository, Release-Build, etc.)

Wer es weiß der kann es auch.

Eine Datenbank ist kein Übel, sondern Mittel zum Zweck und manchmal auch völlig überflüssig und ein paar schlichte Dateien hätten es auch getan.

Natürlich macht man sich Gedanken was für Datenstrukturen die Anwendung benötigt um ihre Aufgabe zu erledigen, aber eben völlig losgelöst von dem eventuell zu verwendenden Datenbank-System.

Hat man diese Strukturen und die Anwendung, dann ist die Datenbank-Anbindung nur noch ein Spaziergang und das Datenbank-System wird austauschbar.

Das ist professionell.

Meine Datenbankanwendungen sind grundsätzlich so geschrieben, dass ihnen die darunterliegende Datenbank egal ist. Bin es gewohnt mit Datenmengen umzugehen, bei denen sich eine Datenhaltung außerhalb einer Datenbank verbietet. Man müsste dann quasi selbst eine Datenbank implementieren, um mit den Datenmengen umgehen zu können. Das ist unsinnig und zu aufwändig.

D. h.: Die Datenbank ist (annähernd) beliebig austauschbar, aber das Datenmodell ist immer gleich. (Annähernd deshalb: Es gibt zwar 'nen SQL-Standard, aber so wirklich 100% kompatibel sind die Datenbanken da nicht.)
Aber es gibt Möglichkeiten das so flexibel zu gestalten, dass man ohne Programmänderung trotzdem die Datenbank wechseln kann.

[p80286]

Zunächst, es werden wohl nicht Millionen von Datensätzen werden, daher sind Peformanceüberlegungen eher nebensächlich. Trotzdem spricht nichts gegen ein Datenmodell, das alle Möglichkeiten (oder doch nur 95%,98%..) abdeckt.
@Schokohase
Eine Datenbankanwendung ist die Schnittstelle zwischen Benutzer und den Daten. Nicht mehr und nicht weniger. In dieser Schnittstelle kann man z.B. über Prüfungen sicherstellen, daß nur korrekte Daten in der Datenbank landen. Aber der erste Schritt zu einer solchen Anwendung, ist die Definition der Daten und der Datenhaltung, unabhängig vom später eingesetzten DB-System. Wer hierbei Hausnummern, Postcodes oder Telefonnummern als Zahlen ablegt, legt schon eine fehlerhafte Basis für die spätere Schnittstelle.
Wohin gehört z.B. die Telefonnummer 49211789 ? Ist es 0049211789 oder 049211789 oder doch 49211789 ?

Zitat von Schokohase:

Eine Datenbank ist kein Übel, sondern Mittel zum Zweck und manchmal auch völlig überflüssig und ein paar schlichte Dateien hätten es auch getan.

Natürlich macht man sich Gedanken was für Datenstrukturen die Anwendung benötigt um ihre Aufgabe zu erledigen, aber eben völlig losgelöst von dem eventuell zu verwendenden Datenbank-System.

Hat man diese Strukturen und die Anwendung, dann ist die Datenbank-Anbindung nur noch ein Spaziergang und das Datenbank-System wird austauschbar.

Ich denke da sind wir jetzt einer Meinung

Gruß
K-H

[Schokohase]

Zitat von p80286:

Eine Datenbankanwendung ist die Schnittstelle zwischen Benutzer und den Daten.

Also hat eine Anwendung keine Daten?

Und wenn sie doch Daten hat, aber keine Datenbank, ist es dann eine Datenanwendung oder eher eine DatenOhneBankanwendung?

Bei mir ist jede Anwendung eine Schnittstelle zwischen Benutzer und Daten. Und die Daten liegen irgendwo, der Anwendung grundsätzlich egal, denn die bekommt den Zugriff auf die Daten über eine Abstraktion zugeteilt.

Ist es dann eine IrgendwoDatenanwendung?

[Delbor]

Hi zusammen

Zitat von Delphi.Narium:

Delbor will eine Datenbankanwendung schreiben.
Welche Datenbank(en) genutzt wird/werden soll, steht im Eingangspost.

Um dies etws zu präzidieren: Das DB-Modell wurde/wird mit MySQL Workbench erstellt. Standartmässig können damit auch MySQL-Datenbanken erstellt werden(ForwardIngeneering). Es gibt aber ein Plugin für MySQL-Workbench, das die MySQL-DDL-Statements in solche, die für SQLite optimiert sind, exportiert.. Dieses werde ich allerdings wohl löschen und neu installieren müssen - zum Schluuss wird mir eine Fehlermeldung um die Ohren geschlage, wonach eine oder mehrere Python-Dateien fehlen.

Gruss
Delbor