Kauf- und Kontenverwaltung - Datenbank notwendig?

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

Zitat von Delphi.Narium (Beitrag 1387819)

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

[p80286]

Zitat:

Zitat von bernau (Beitrag 1387811)

Aber für dauerhaft gespeicherte Daten, deren Datenstruktur ggf. angepasst werden muss, ist das tödlich.

Da hänge ich mich aus dem Fenster und sage, das ist ein Irrtum. Einmal das alte Format lesen, und dann das neue Schreiben. Fertig.
Eine Textdatei hat den Vorteil der Flexibilität, allerdings muß man Verwaltungsinformation(en) mit in die Datei packen (z.B. Feldnamen).
Will man das umgehen, muß ein festes Format vorliegen, was wiederum einem

Delphi-Quellcode:

File of MyRecord

entspricht bzw. ähnlich ist.

Gruß
K-H

[Jasocul]

Mal eine ganz andere Sichtweise von mir:
Wieviel Datensätze oder Buchungen ist mir egal.
Es geht hier um irgendwelche Abrechnungen. Sind die nur für einn eigene Übersicht und existieren noch in einer Buchhaltungs-Software? Falls ja, kann man das vielleicht so machen, würde ich aber nicht. Falls aber schon diese Daten die "Buchhaltung" sind, so ist eine Text-Datei indiskutabel, weil diese jederzeit problemlos von "außen" manipuliert werden kann. Das muss nicht mal absichtlich passieren. Es gibt da also durchaus Sicherheitsbedenken, die zu berücksichtigen sind.
Eine DB scheint erstmal übertrieben zu sein, löst aber mehrere Probleme, für die jetzt mit Sicherheit Klimmzüge gemacht werden müssen:
- Oben genannte Sicherheitsprobleme sind geringer
- Zahlen sind ganz sicher Zahlen. Zahlen aus einer Text-Datei einzulesen und zu verarbeiten, erfordern in der Regel mehr Prüfaufwand.
- der gesamte Formatierungs- und Prüfaufwand für die Stringgrids entfällt, da z.B. DBGrid genutzt werden kann.
- Berechnungen (Summen, Quartals-Abrechnungen, Mengen, etc.) sind durch SQL meistens viel einfacher und können direkt im DBGrid ohne weiteren Aufwand dargestellt werden.
- Daten filtern ist viel einfacher (SQL)
- Automatische Änderungen können oft über einen SQL-Befehl gelöst werden und benötigen keine "komplizierten" Delphi-Routinen.
- Aufbewahrung "alter" Daten sind in der DB auch kein Problem
- Hobbymäßig ein Abrechnungssystem zu programmieren kann man machen, wenn es für einen selbst ist. Eine Nutzung durch andere, erfordert meiner Meinung nach ein Mindestmaß an Sicherheit (s.o.)

Natürlich muss man sich mit Datenbanken beschäftigen und SQL erfordert auch Einarbeitungszeit. Bei den paar Datensätzen kann man aber auch ohne große SQL-Kenntnisse starten und am Anfang die Filter-Funktionen der DB-Komponenten in Delphi nutzen.
Du kannst das sicher auch mit Text-Dateien lösen, aber den Aufwand, den du jetzt in die Aufbereitung der Daten alleine schon beim Ein- und Auslesen treiben musst, kannst du auch in die Einarbeitung in Datenbank investieren.

[Namenloser]

Datenbanken kann man genau so von außen manipulieren wie Textdateien, das ist also kein Argument.

[Jasocul]

Zitat:

Zitat von Namenloser (Beitrag 1387854)

Datenbanken kann man genau so von außen manipulieren wie Textdateien, das ist also kein Argument.

Natürlich kann man das. Definitiv aber nicht genauso (einfach). Deswegen schrieb ich auch:

Zitat:

Zitat von Jasocul (Beitrag 1387853)

- Oben genannte Sicherheitsprobleme sind geringer

[Timelord]

Zitat:

Zitat von Delphi.Narium (Beitrag 1387819)

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. :thumb: :kiss:

[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