Kauf- und Kontenverwaltung - Datenbank notwendig?

[Asura]

Guten Tag,
ich frage mich, ob ich mich zwingend bei meinem folgenden vorhaben eine Datenbank verwenden sollte.
Es geht hier um 14 Konten, die nur einmal im Jahr eine Änderung durchleben.
Im Programm kann man anhand von Buttons sein Account auswählen (Kein Login Notwendig), daraufhin wird man weitergeleitet und man wählt zwischen Produkten aus, diese werden in einen Art Warenkorb (Stringgrid) als Einträge niedergelegt. Durch das weiter klicken auf einen Button, soll nun dieses Stringgrid abgespeichert werden.
Diese "Rechnung" wird quartalsmäßig bezahlt. Jedoch sollen diese Daten nicht verschwinden, sondern als Nachweis in dem Datensatz erhalten bleiben.

Ich dachte mir, ich lass einfach eine Textdatei erstellen, in der soll dann Produkt, Anzahl und Preis niedergelegt werden. Das Programm berechnet dann immer die Summe und kann jeder Zeit einen Stand ausgeben. Wenn nun quartalsmäßig etwas beglichen wird, dann wird manuell ein Plus in den Datensatz hinterlegt und das Programm erkennt anhand des Zusammenrechens, was als Endsumme rauskommt. Das muss ja dann immer die Verbindlichkeit sein, die im laufenden Quartal übrig ist.

Meine Frage nochmal: Gibt es eventuell bessere Möglichkeiten, dies zu verwirklichen; Muss ich eine Datenbank eher nutzen (Nebenbei gesagt: Ich beschäftige mich nur Hobbymäßig damit und blutiger Anfänger) oder kann ich meine Überlegung so realisieren. Alles in Allem: Was für Optionen habe ich dies zu verwirklichen?

[Namenloser]

Ich schätze mal, manche hier werden anderer Ansicht sein, aber ich denke, dass eine Textdatei in dem Fall durchaus legitim ist. Wenn du das Programm später erweitern willst, wirst du dir aber vielleicht wünschen, du hättest eine Datenbank genommen. Allerdings ist zu viel Planung für die Zukunft die Wurzel allen Übels in der Programmierung. Am Ende braucht man es halt eben doch nicht und hat sich nur unnötig Arbeit gemacht und den Code komplizierter und größer. Daher würde ich vorschlagen: Implementiere es einfach erst mal so wie du beschrieben hast.

[blawen]

Erfahren die Konten Quartalsweise oder nur einmal im Jahr eine Änderung (14 vs 4x14)?
So oder so sind die (max.) 56 Buchungen nichts, wofür Du zwingend eine DB einsetzen müsstest.
Sofern Du aber grundsätzlich am Thema DB interessiert bist, kann ich Dir dies nur empfehlen.

Zitat:

Wenn du das Programm später erweitern willst, wirst du dir aber vielleicht wünschen, du hättest eine Datenbank genommen.

Eigentlich auch kein grosses Problem. Sofern die Textdatei gut strukturiert und jede Buchung eindeutig ist (inkl. Zeit/Datumstempel), lässt sich dies jederzeit in eine Datenbank überführen. Zugegeben, dafür muss ein kleiner Importer geschrieben werden, aber der Aufwand ist überschaubar und man hat sich den Weg nicht verbaut. Vorausschauende Planung, bzw. für zukünftige Erweiterungen flexbel genug zu sein, ist grundsätzlich das wichtigste zu Beginn von neuen "Meilensteinen".

[haentschman]

Moin...:P
Möööp...Ich bin anderer Meinung. 8-)

Zitat:

Ich schätze mal, manche hier werden anderer Ansicht sein, aber ich denke, dass eine Textdatei in dem Fall durchaus legitim ist. Wenn du das Programm später erweitern willst,

Die diese 2 Satzteile widersprechen sich in sich. :wink:

Zitat:

So oder so sind die (max.) 56 Buchungen nichts, wofür Du zwingend eine DB einsetzen müsstest.

56 Buchungen sagen aber nichts über den Umfang der Buchungen aus. 56 Buchungen mit Detaildaten usw. können u.U. das Textfile zum Platzen bringen.

Zitat:

Wenn du das Programm später erweitern willst

Die erste Erweiterung wird die Suche in den Daten sein. :wink: Da bist du mit einer Datenbank komfortabler und schneller.

Ich zitiere mal meinen Lehrmeister:

Zitat:

Was kostet es mehr, wenn man es gleich richtig macht!

:thumb:

[bnreimer42]

Kommt es nicht immer drauf an, was man kann?

Jemand, der noch nie eine DB aufgebaut hat, macht das im ersten Versuch sicher schlechter (Mehr Fehler aus späterer Sicht), als wenn er die Daten ordentlich in eine Text-Datei speichert.

Aber anders rum: Jeder muss seine Erfahrungen machen, um etwas zu lernen.

Somit würde ich die Frage stellen:
Wie kritisch ist die Anwendung?

Wenn Du genug Zeit hast, nimm eine Datenbank und mach Deine Erfahrungen!

Wenn Du regelmäßig Backups machst und prüfst, ob die Restores auch funktionieren, kann da nichts passieren!

Die frage nach "Welche" Datenbank ist hier ja schon oft genug behandelt und so eindeutig behandelt, wie welche Automarke stellt die besten Autos her.

[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

Delphi-Quellcode:

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:

Zitat von p80286 (Beitrag 1387809)

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

Delphi-Quellcode:

file of myRecord

sein.

Beim Ersten stimme ich dir zu. Beim klassischen Weg über

Delphi-Quellcode:

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.