Kauf- und Kontenverwaltung - Datenbank notwendig?

[TBx]

In dem von Dir beschriebenen Umfang ist es eigentlich ziemlich Wurst, was du machst. Ich möchte aber zu bedenken geben, dass dieses Projekt ideal ist, um in die Datenbankprogrammierung einzusteigen, da es klein und übersichtlich ist. Das Projekt und Deine Datenbankfähigkeiten können wunderbar gemeinsam wachsen.
Und Du brauchst nicht zurückzuschrecken, weil man da womöglich weitere Software installieren müßte, heutzutage gibt es genügend embedded DatabaseEngines, die man nur einkopieren muss.

[RaSoWa1]

Auf Grund meiner persönlichen Erfahrungen speichere ich meine Daten in Textdateien. Eine Datenbank würde ich nur verwenden, wenn von mehreren Benutzern oder Anwendungen auf die Daten zugegriffen muss, wegen der Synchronisierung, oder ich extrem viele Datensätze (> 1 Mio) erwarte. Dies kam bei mir bisher noch nicht vor, da ich nur ein Hobby-Programmierer bin.

Meine Daten hatte vor vielen Jahre in dBaseII-, später in Paradox-Datenbanken gespeichert. Als auch die Borland-BDE starb, wollte ich nicht wieder auf eine neue Datenbank umstellen und habe mich für das Textformat entschieden. Damit bin ich bisher gut gefahren und es ist zukunftssicher. Wenn Du Dich für eins der vielen Datenbank-Systeme entscheidest, ist es nicht sicher das es dieses in ein paar Jahren immer noch gibt.

Gruß
Klaus

[p80286]

Nein, eine Datenbank ist nicht notwendig. Eine Textdatei sollte auch ausreichen, wenn man weiß, was man tut. der klassische Weg sollte die Nutzung eines file of myRecord sein. Aber man kommt nicht umhin erst einmal eine vernünftige Datenanalyse zu treiben. Welchen Inhalt haben die Bestandsdaten, was enthalten die Buchungssätze. Wie weit müssen einzelne Vorgänge gespeichert/dokumentiert werden. Narurgemäß ist eine DB hier im Vorteil, da der Umgang mit strukturierten Daten genau ihr Metier ist. Wählt man zur Speicherung eine Textdatei, so muß man zusätzlich zu den notwendigen Datenstrukturen, auch die notwendigen Routinen zur Verwaltung der Daten bereit stellen. Es ist bestimmt interessant diesen Weg zu beschreiten, wenn man etwas lernen will, soll es aber schnell und sicher gehen, führt kein Weg daran vorbei sich beim Know-How anderer (Datenbanken) zu bedienen.

Gruß
K-H

[jobo]

[QUOTE=p80286;1387809]Nein, eine Datenbank ist nicht notwendig. Eine Textdatei sollte auch ausreichen, ../QUOTE]
Sehe ich auch so.

Eine Datenbank: Liefert sämtliche Funktionen, die Integrität der Daten gewährleisten. Die Tabellendefinition, das gesamte Datenmodell erlauben es, eine wasserdichte Kontenverwaltung zu erstellen, in der nichts schiefgeht UND in der ich dafür fast keinen Kontrollcode benötige, hauptsächlich Tabellendefinition und Trigger, nach Bedarf/Geschmack auch Stored Procedures. Außerdem benötige ich keine Rechenläufe für Summen und Reports.
Eine Datenbank ist aber (ähnlich wie die Entwicklungsumgebung) dem Risiko ausgesetzt, irgendwann nicht mehr weiterentwickelt zu werden.

Eine Textdatei: bietet Zukunftssicherheit, erfordert aber die manuelle Kodierung aller Zugriffe, also Buchung, Auswertung, Kontrolle. Man bekommt nichts geschenkt. *

* geschenkt bekommt man dagegen die ein oder andere OpenSource DB wie Firebird oder PostgreSQL, die einen Haufen Funktionen mitbringt, wo ich das Rad nicht neu erfinden muss. Das Risiko, auf dabei auf ein totes Pferd zu setzen, ist relativ übersichtlich, solange man SQL Standards halbwegs einhält und dann notfalls eben einfach die Datenbank wechselt.

Mittelding:
XML oder JSON: Keine Datenbank, sondern Textdatei, also freier Zugriff, notfalls per Notepad. Hunderte Bibliotheken für Lesen, Schreiben, Validieren. Hier hat man immerhin eine normierte Zugriffsebene und definierte Syntax.

[bernau]

Zitat von p80286:

Eine Textdatei sollte auch ausreichen, wenn man weiß, was man tut. der klassische Weg sollte die Nutzung eines file of myRecord sein.

Beim Ersten stimme ich dir zu. Beim klassischen Weg über file of myRecord sage ich aber immer "Hände weg". Das ist für temporäre Daten ganz gut. Aber für dauerhaft gespeicherte Daten, deren Datenstrucktur ggf. angepasst werden muss, ist das tödlich. Dann lieber so etwas wie CSV, JSON, XML oder sogar INI.

[Asura]

Wow vielen Dank für die vielen Kommentare!
Ich ergänze mal, dass was eventuell für die Verwirklichung meines Vorhabens wichtig wäre:
Ich würde pro Konto eine Textdatei erstellen (Maximal können nur 16 Konten existieren), aktuell existieren 14. Maximal einmal im Jahr findet hier ein Wechsel statt, sprich: Neue Konten / Neues Konto, neue Buchungen.
Anzahl der Buchungen (grob): Pro Quartal: 10-80 Buchungen.
Danach würde ein Plus erfolgen, durch die Begleichung der Verbindlichkeit durch den Kontoinhaber. Die Datensätze sollten hier aber erhalten bleiben, nur sollte das Programm diesen Plus erkennen. Alles in allem könnte man das mit einem Online Banking Account vergleichen. Im Programm sieht man jegliche Buchungen, die abgezogen werden und Quartalsmäßig das Plus, was man bezahlt hat. Dabei wird dann die Gesamtsumme errechnet, was in dem laufenden Quartal noch zu bezahlen ist.

[Delphi.Narium]

Bei der Aufgabenstellung: Datenbank

Das alles selbst zu verwalten wird schnell sehr aufwändig.

SQLite, FireBird (embedded), Access.

[Asura]

Zitat von Delphi.Narium:

Bei der Aufgabenstellung: Datenbank

Das alles selbst zu verwalten wird schnell sehr aufwändig.

SQLite, FireBird (embedded), Access.

Ich habe mal bisschen auf Google geschaut, bezüglich Tutorials für die Verbindng Access Datenbank, jedoch leider nichts brauchbares gefunden.
Gibt es eventuell eine Linksammlung oder etwas vergleichbares, was mir das einarbeiten in diese Thematik ermöglicht?

[Delphi.Narium]

Auf Access kann man mit den ADO-Komponenten zugreifen, bzw. allen Datenbankkomponenten, die u. a. ODBC ... unterstützen.

Ansonsten funktioniert der Zugriff, wie bei allen Datenbanken auch, da gibt es programmiertechnisch eigentlich keine Unterschiede.

Über die ODBC-Verwaltung müsste man eigentlich bei Hinzufügen Mircosoft-Access auswählen können. Dort vergibt man den Namen der Datenbankverbindung und kann auch sofort eine neue Datenbank erstellen lassen, man bekommt dann eine leere Datenbankdatei.

Die benötigten Tabellen kann man per SQL erstellen.

Die Datenbankdatei wählt man dann in der Datenbankverbindung der Datenbankkomponente(n) in Delphi aus.

Ein bestimmtes Tutorial kenne ich da jetzt nicht, aber hier solltest Du so allerlei finden können:
tutorial delphi source Access
tutorial delphi sql

[Timelord]

Zitat von Delphi.Narium:

SQLite, FireBird (embedded), Access.

Ich habe bisher gute Erfahrungen mit SQLite gemacht (zwar nicht direkt von Delphi/Pascal aus, aber das sollte übertragbar sein...).
Vorteil an diesen "direkt zugegriffenen" Datenbankfiles gegenüber individualisiertn Textdateien ist eindeutig die leichtere Interoperabilität/Migrationsfähigkeit, mit einer "großen" relationalen Datenbank (z.B. MariaDB). Ich schließe mich gerne meinen Vorrednern an, wenn gesagt wird, dass man auch mehr Funktionalität bekommt: Bei einem Textformat lernt man mit Sicherheit wie soetwas funktioniert usw, aber bei Datenbanken/Datenbankdateien bekommt man den zusätzlichen Aufwand (Suche, Filter, etc) einfach freihaus geschenkt dazu.