Kauf- und Kontenverwaltung - Datenbank notwendig?

[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.