Kauf- und Kontenverwaltung - Datenbank notwendig?

[jobo]

Zitat:

Zitat von Asura (Beitrag 1390926)

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:

Zitat von Delphi.Narium (Beitrag 1390913)

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

[Delphi.Narium]

Zitat:

Zitat von jobo (Beitrag 1390943)

Prinzip bedingt, gibt es aber m.E. nichts Schnelleres als DB Server Business Logik.

Niemand kann schneller und besser mit den Daten in einer Datenbank umgehen, als die Datenbank, in der sich die Daten befinden.
Bisher konnte ich noch jedem im Kollegenkreis, der etwas anderes behauptete, das Gegenteil beweisen.

Man muss sich halt nur einmal die Mühe machen SQL zu lernen und sich in die Programmiersprache der jeweiligen Datenbank einarbeiten. (PL/SQL, T-SQL, PL/pgSQL ...)
Das ist kein Hokus-Pokus, sondern genauso leicht oder schwer erlernbar, wie jede andere Programmiersprache auch.
Und gerade bei großen Datenmengen spart man eine Menge an Datentransfer zwischen DB und Software. Und bei der Reportgenerierung, Summierungen, Aggregierung, Abrechnungen ... und was weiß der Geier noch, aus welchen Gründen Abhängigkeiten, Zusammenhängen ... großer Datenmengen untereinander ermittelt werden müssen, Datenbanken sind doch genau dafür da und in dem Bereich unschlagbar schnell.