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...
Möööp...Ich bin anderer Meinung.

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.

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

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

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