Kauf- und Kontenverwaltung - Datenbank notwendig?

**Delphi.Narium**

Mein Vorgehen ist erstmal:

Connectionstring auf die neue Datenbank ändern und Programm starten.
Wenn's nicht geht (was äußerst selten ist) muss ich halt die Probleme beheben.

Wenn man sich bei den SQLs an den Standard hält, sind Probleme eher selten, ab und an werden Datentypen etwas anders gehandhabt, aber die Masse sollte einfach laufen.

[edit - etwas provokant]
Wenn man mit Delphi eine gute Datenbankapplikation geschrieben hat, ist es der egal, gegen welche Datenbank sie läuft, man ändert die Datenbankverbindung (gerne per Dialog) und das Programm läuft gegen eine andere Datenbank. Der Softwareentwickler muss die Datenbanken nicht mal alle kennen.

Klar: Auf Datenbankseite darf man dann nur das nutzen, was alle Datenbanken können. Dafür gibt es den Standard, der weitgehend eingehalten wird.

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.
[/edit]

**TigerLilly**

ad DB-Server:
Wir verwenden den MS SQL Express. Der ist kostenfrei, kann auch im Netz für Mehrbenutzer fungieren + ist mit den großen Editions gut skalierbar. Für uns funktioniert das sehr gut, egal ob Einbenutzer mit Laptop oder Multiuser mit Server.
Ähnliches gibt es auch von Oracle. Alternativ gibt es natürlich auch Firebird, Progress, mySQL.

ad Datenmodell formal:
- die Tabellennamen brauchen die Präfixe nicht. Entscheide dich, wie die Tabellen heißen sollen + aus.
- Die Feldnamen der Tabellen brauchen die Präfixe ebenfalls nicht. Das macht die Namen nur unübersichtlich.
- Die Namensgebung ist nicht einheitlich: bacc_usr_ID und sere_ID - sollte wohl book_sere_ID sein. Ähnliches für booT_ID.
- Die Schreibweise ist nicht einheitlich: Wenn du booT_ schreibst müsste es auch bAcc_ heißen.
- Entscheide dich, ob die nach dem _ groß oder klein weiterschreibst: sere_Name vs catg_name.
- Die Namen der Tabellen sollten entweder alle Einzahl (bevorzugt) oder Mehrzahl sein, nicht mischen (usr_users vs booT_bookingtype).

ad Datenmodell inhaltlich:
- In Zeiten von Password-Hacks würde ich keine Passwörter speichern, sondern nur ihre Hash-Äquivalente.
- Die Verwendung von englischen Bezeichnern bleibt jedem überlassen, ich persönlich finde, dass das kein Muss ist. Verständlichkeit hat Vorrang.
- Ob du mit den angeführten Attributen auskommst, musst du wissen, ich finde die Infos zur Bank und zum User sehr dürftig. Passwörter können ein Ablaufdatum haben, sollten ev. Nicht wiederverwendet werden. USer haben Klarnamen, ev E-Mail etc. Banken vielleicht eine Adresse?
- ob Buchungen wirklich nur eine Kategorie haben, musst auch du wissen, aber ev haben die Kategorien noch eine übergeordnete Kategorie. Bzw gehören zu Ein/Ausgängen.
- Senderreceiver kann ev auch weitere Infos vertragen.

HTH TigerLilly

**p80286**

Warum werden username und pw doppelt abgelegt?
Sollten mehrere User auf einen Bankaccount zugreifen müssen/können, sollte diese Relation über eine entsprechende Tabelle abgebildet werden.

Gruß
K-H

@Delphi.Natrium
Ganz so einfach ist es in der Praxis nicht, aber das Prinzip ist schon korrekt.

**jobo**

Zitat von Delphi.Narium:

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

**Delphi.Narium**

Zitat von jobo:

Zitat von Delphi.Narium:

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

@Jobo:

Du beschreibst eigentlich genau das, was ich meine:
entweder <-> oder.

Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.

Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.

Ein bisserl Logik in der Datenbank und die "Reste" in N Applikationen? NoGo

Wer sowas entwirft, empfiehlt ... gehört gehauen

**Asura**

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?

Dann Dankeschön für die kritische Bewertung!
Ich werde davon wohl so gut wie alles umsetzen.

Bezüglich der Hash-Ablage und warum ich zwei Passwörter verwende.
Das eine ist das Passwort für das Programm zum einloggen, dass andere sind die Benutzerdaten für den Bankaccount.
Mein Vorhaben sieht so aus, dass das Programm sich in den Bankaccount des jeweilen Users nach der Auswahl seiner Bank einloggt, die Umsätze herunterlädt und den Benutzer dann die Wahl der Kategorievergabe oblässt und dann diese statistisch darstellt und bewertet.
Deswegen kann ein User (Client) mehrere Bankaccounts haben.

Wegen der Passwortablage:
Ich bin mir nicht sicher, ob du das meinst was ich vorhabe:
Ich würde das Passwort über das Programm verschlüsseln und der verschlüsselte Inhalt wird dann auf die Datenbank abgelegt. Wenn man sich einloggt, entschlüsselt er den Wert und gleicht diesen dann ab.
Ich wollte auch eine Option des automatischen Logins einspeisen, habe das zurzeit zwar noch alles ohne Verschlüsselung aber er speichert die Logindaten in einer Ini-Datei ab. Hier würde ich dann auch das Passwort verschlüsseln und nur diesen Wert in die Ini schreiben und diesen wieder laden, entschlüsseln, vergleichen.

Möchte noch kurz anmerken: Das Programm zielt nicht ab kommerziell genutzt zu werden. Das wird nur unter ausgewählten Personen verteilt. Ich habe leider gar keine Rechte mit einer Student Version von RAD hier kommerziell zu werden. Also würde davon nur hauptsächlich Ich und ein paar gute Bekannte davon profitieren.

//EDIT:

Ich habe nun die Datenbankmodellierung angepasst.
Ich habe bei Senderreceiver ein "Usage" hinzugefügt, der soll dann ein Boolean Wert haben (Sender = 0, Receiver = 1).
Bei Bookings ist Bookingtype nun raus und soll nun die Oberkategorie (Einzahlung/Auszahlung) sein. Hier habe ich eine Frage. Da es ja nur die zwei Optionen gibt, würde es nicht reichen einfach nur eine Spalte bei Kategorien hinzuzufügen als Boolean mit 0 = Eingang, 1 = Ausgang. Aber es stimmt, dass dies eher eig. als Oberkategorie dienen soll. Also so wie ich das jetzt habe nur eventuell in der Tabelle Bookingtype statt Name den Boolean wert?
Man müsste dann später ja nur über die Kategorien gehen, um die Eingänge bzw. die Ausgänge darzustellen.

**Delphi.Narium**

Zitat von Asura:

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?

Doch genau das: Andere Datenbank, anderer Connectionstring und gut ist es.

Es wäre für meine Begriffe recht erbärmlich von Delphi, wenn ich je Datenbank andere Datenbankkomponenten nutzen müsste.

Habe im Laufe meines Lebens so einiges an Software schreiben müssen, bei dem ich zu Beginn der Entwicklung noch nicht wusste, gegen welches DBMS sie denn letztendlich laufen wird.

Das wäre ja mörderisch, wenn man dann die Software erstmal gegen die zur Entwicklung verfügbare Datenbank mit den passenden Komponenten entwickelt und wenn man dann irgendwann erfährt, dass beim Kunden eine andere Datenbank zum Einsatz kommt, macht man alles, mit anderen Datenbankkomponenten, neu?
Oder die Software kommt bei mehreren Kunden zum Einsatz, aber jeder hat sich für ein anderes DBMS entschieden? Dann gibt es entsprechend viele Varianten der Software, schön mit jeweils eigenen Komponenten?

Und was ist, wenn aus irgendeinem Grund mal die zuerst gewählte Datenbank wegfällt? Eine Neuentwicklung mit anderen Datenbankkomponenten?

Warum mag man wohl bei den ADO-Komponenten bei der Erstellung des Connectionstrings eine recht große Auswahl an unterschiedlichen Möglichkeiten zur Erstellung des Connectionstrings und eine (ggfls. systemabhängig) mehr oder weniger große Auswahl an unterschiedlichen DBMS bekommen? Nur um dann festzustellen, dass es nur gegen Access funktioniert?
In dem Fall würd' für meine Begriffe die sofortige Deinstallation dieser Komponenten das Einzige sein, was ich mit ihnen mache!

Es gibt diverse Möglichkeiten, um auf Datenbanken zuzugreifen, sei es FireDac, UniDac, dbgo, ADO, Zeos, (manche kennen noch die BDE

) und was weiß der Geier sonst noch.
Sicherlich sollte man am Anfang eine Entscheidung treffen, welche Variante man nutzt.
Aber egal welche man nutzt: Sobald man die Datenbank wechselt, muss man auch die Datenbankkomponeten wechseln?
Das hieße doch letztlich: Für jede Datenbank müsste es eine eigene Palette von entsprechenden Datenbankkomponenten geben. Das wäre ja dann fast schon absurd.
Wo blieben denn da die datenbankunabhängige Entwicklung von Datenbanksoftware?

Brauchen wir dann eventuell für jede Sprache ein eigenes TEdit, ein eigenes TMemo ...

Delphi ist hervorragend dazu geeignet, Datenbanksoftware zu schreiben und ist dabei nicht auf eine bestimmte Datenbank festgelegt. Dies kann nur gelingen, wenn es eben nicht erforderlich ist, beim Datenbankwechsel die gesamte Datenbankschnittstelle auszutauschen.

Probleme beim Datenbankwechsel kann es geben, wenn sehr datenbankspezifische SQLs genutzt werden. Die eine DB will halt top 10, die andere first 10, eine andere RowNum < 11, wieder eine andere Limit 10 und das auch noch an unterschiedlichen Stellen des SQLs, nur um an die ersten 10 Zeilen einer Ergebnismenge zu kommen. Das ist aber bei allen Datenbankkomponenten gleich.

Wenn Du mit dem Auto normalerweise über die Autobahn zur Uni/Arbeit/Oma/... fährst und nicht über die Landstraße, wirst Du doch nicht dann, wenn Du ausnahmsweise mal über die Landstraße fährst, vorher einen entsprechenden Motor einbauen? (ja, der Vergleich hinkt.)

Probleme beim Wechsel der Datenbank kann und wird es geben, aber nicht aufgrund der Komponenten, sondern Aufgrund der Unterschiedlichen Syntax im SQL, sobald man auch nur um Haaresbreite vom (weitgehend einheitlich unterstützten) SQL-Standard abweicht.

Man muss sich im realen Leben also Gedanken darüber machen, welche Änderungen am SQL notwendig sind, um mit unterschiedlichen Datenbanken zusammenarbeiten zu können. Und darüber, wie man das im Programm am besten gehändelt bekommt. Hierzu gibt es im Forum schon vielfältige, teils recht kontroverse, Diskussionen. Die solltest Du mal zu Rate ziehen.

ADO ist jetzt vielleicht nicht aus jedermanns Sicht die beste Datenbankschnittstelle, aber welche Datenbank man damit nutzt, sollte egal sein.

Mein konkretes Vorgehen in Deinem Fall wäre:

Connectionstring auf die neue Datenbank ändern, in der neuen Datenbank für das Vorhandensein des benötigten Datenmodells sorgen.
Programm starten und auf Herz und Nieren testen.
Und nur wenn Probleme auftreten nach einer Möglichkeit der Beseitigung suchen und diese (wenn irgend möglich) so wählen, dass das(die) bisher unterstützte(n) DBMS auch weiterhin genutzt werden kann(können). (Unterschiedliche Lösungsansätze findet man hier im Forum.)

**jobo**

Zitat von Asura:

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?

Du kannst mit ADO verschiedene Systeme ansprechen. Mit etwas "Glück" kannst Du ohne große Probleme wechseln. Access ist im SQL Bereich leider nicht so kompatibel, wie man es sich wünschen würde. Das macht sich aber erst bemerkbar, wenn Du in der Anwendung native SQL Statements absetzt. Das Thema "Logik" schrumpft ja im Falle der Client seitigen Implementierung auf Datenmodell Logik. Da bist Du ja dran. Solange Du keine Code Module auf Datenbankseite verwendest, ist ein Wechsel der Systeme nicht dramatisch (aufwendig).
Es gibt ein paar Dinge, auf die man grundsätzlich achten sollte, um weitgehende Kompatibilität zu erhalten. In Deinem Fall aber vielleicht nicht ganz so interessant, wenn Du das Programm nur als Hobby betreibst.
- die Handhabung von ID Werten bzw deren Generierung
- die Verarbeitung von BLOB Typen
- generell die Typ Besonderheiten des RDBMS (Verwendung exotische Typen bindet vielleicht ungewollt doch an ein System)
- Handhabung von Schema, User, Privilege Konzepten
- Sperrverhalten und Multiuserbetrieb (Rowlevel Locking, ... -heutzutage können es eigentlich alle nennenswerten Systeme recht filigran)

Diese spontane Liste ist vielleicht nicht vollständig, muss aber auch nichts heißen.

**jobo**

Zitat von Delphi.Narium:

Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.

Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.

Naja, es gibt da recht kompatible Systeme. Oracle zu Postrges geht in vielen Bereichen recht gut (bzw umgekehrt). Idealerweise berücksichtigt man das, wenn möglich/nötig. Es gibt allerdings auch hier z.B. wirkliche Brüche.
Grundvoraussetzung ist für die Implementierung natürlich ein RDBMS mit mehr als passablen Programmierfähigkeiten. Das sind nicht so viele.

Wenn man das Spielchen so weit treibt, dass eine Anwendung per SQL bedienbar ist, ist das natürlich ganz was anderes als ein RDBMS, das nur als Datencontainer verwendet wird. Prinzip bedingt, gibt es aber m.E. nichts Schnelleres als DB Server Business Logik.
Das könnte dann auch ein Argument für Kunden sein, nicht auf das gewohnte "Haus" DB System zu setzen. Ist das RDBMS dann noch kostenlos, hat man eigentlich ganz gute Argumente. Nein, ist das RDBMS sogar OpenSource, dann hat man ganz gute Argumente für eine sehr spezifische Lösung.

Wieauchimmer, gehört wohl nicht ganz hier her.

**p80286**

Mir scheint das wichtigste für eine Buchung fehlt noch, die KontoNummer!?

Was die DB-Zugriffskomponenten angeht
a) Ihre Syntax ist weitestgehend Kompatibel
b) Jede Komponente unterstützt mehrere Datenbanken

Auch wenn ADO nicht dieee Schnittstelle ist, um einen Prototypen zu erstellen ist sie wohl gut genug. Später kann man dann noch, falls notwendig eine optimale Komponente verwenden.

Auch wenn es ein nicht kommerzielles Projekt ist, zumindest das, was nichts kostet darf durchaus professionellen Ansprüchen genügen. Mann könnte auch sagen mach es ordentlich oder laß es.

Gruß
K-H