Kauf- und Kontenverwaltung - Datenbank notwendig?

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

[Rollo62]

Ich würde das zwar auch mit richtiger db machen,
Aber warum nicht Beides ?

Mit TFdMemTable eine inmemory db nutzen und mit save und loadfile als textdatei speichern.

Rollo

[HolgerX]

Hmm..

Ich hab mal (Quick and Dirty) ein paar Tools gebastelt, welche ich ohne Datenbank, jedoch dennoch mit Datenmengen benutzt habe.

Da hier die Datenmengen gering waren (so ca. 20-100 Datensätze) und zumeist Statisch, konnte ich auf eine Datenbank als solches verzichten.

Stichwort ClientDataSet (OK, habe hier das TADODataset verwendet).

Bei Programmstart habe ich die Daten aus einem File in das Dataset geladen und bei Programmende oder nach Veränderungen an der Datenmenge einfach wieder in das gleiche File weggespeichert.

Beim Test als XML und später dann Binär.
Somit konnte diese Datenmenge nicht mehr so einfach ohne mein Tool bearbeitet werden

Wenn nun die Daten so umfangreich werden, dass diese nicht mehr praktikabel in ein File weggespeichert werden können, dann kann ich das Dataset einfach in z.B. eine AccessDB oder SQL-Server packen und nehme statt TADODataSet einfach nen TADOQuery zum Holen der Datenmenge.

Das weitere Tool bleibt dann identisch.