Kauf- und Kontenverwaltung - Datenbank notwendig?

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

[p80286]

Falls diese Daten schon in der offiziellen Buchhaltung vorhanden sind, könnte man sie genauso von dort (per SQL) holen und müßte sie nicht nochmals speichern. dann wäre zmindest das Manipulationsproblem vom Tisch.

Gruß
K-H

[Jumpy]

Da ja viele Wege nach Rom führen, erwähne ich der Vollständigkeit halber mal den, den meine lieben kaufm. Kollegen immer benutzen: "Dat Biske mach ich doch schnell mit Excel, daför musse mich doch nix projamiere Jung."

Weiterhin der Vollständigkeit halber der Anruf der 2 Std. später kommt:
"Kannse ens kurz kiecke komme, dat mit dä SVerweis klappt irgjendwie nit so recht."

Und nochmal wegen der Vollständigkeit ein halbes Jahr später:
"Hörens, weeßte noch dat Excel-Dingens mit die Konten da. Da kommen jetzt doch en paar mehr dazu und in Excel ist mich dat zu unübersichtlich. Hätteste da nit direkt en Projramm für schriewe könne? Läßte mich dat mühsam mit Excel fummele. Weiße wat dat en Arbeet wor?

Schönen Feierabend

[Delphi.Narium]

@Jumpy "¡Así es la vida!" oder "so isset"

Oder:

Lieber am Anfang etwas mehr Aufwand und dann dafür nachher "für immer" Ruhe.

Wenn's also jetzt noch etwas übertrieben erscheint eine Datenbank zu nutzen.
Die Ansprüche kommen mit der Nutzung der Software und irgendwann (meist früher als später) erscheint eine Datenbank dann doch die simplere Lösung zu sein.

[p80286]

Zitat von Delphi.Narium:

@Jumpy "¡Así es la vida!" oder "so isset"

Oder:

Lieber am Anfang etwas mehr Aufwand und dann dafür nachher "für immer" Ruhe.

Wenn's also jetzt noch etwas übertrieben erscheint eine Datenbank zu nutzen.
Die Ansprüche kommen mit der Nutzung der Software und irgendwann (meist früher als später) erscheint eine Datenbank dann doch die simplere Lösung zu sein.

So isset! Aber auch wenn die Ansprüche nicht so stark steigen, ich hab mal eine Verwaltung für ca 12-14K Personensätze geschrieben. Nach 2 Jahren waren die 16Bit Schlüssel ausgereizt, also alles auf 32 Bit umgestellt und seit dem hab ich Ruhe.

merke Daten wachsen immer doppelt so schnell wie man es sich vorstellt.

Gruß
K-H

[Delphi.Narium]

Zitat von p80286:

merke Daten wachsen immer doppelt so schnell wie man es sich vorstellt.

und das erste nachzurüstende Feature ist das, von dem der Anwender am Anfang der Entwicklung mit Sicherheit ausschließen konnte, dass es je gebraucht wird.

Aber das wird jetzt OT.

Fazit:

Zuerst überlegen, was man hat, was man jetzt benötigt, was man jetzt gerne zusätzlich (wenn auch nicht dringend) gerne hätte, ermitteln welche Datenmenge anfallen wird (und dabei davon ausgehen, dass diese deutlich schneller wächst, als in den kühnsten Alpträumen befürchtet).

Gegenüberstellen:

Wieviel Aufwand bei datenbankloser Entwicklung?
Wie erweiterungsfähig wird das sein?

Wieviel Aufwand in die Einarbeitung zum Umgang mit Datenbanken?
Wieviel Aufwand wird die Entwicklung mit Datenbank "abwerfern"?
Wie erweiterungsfähig wird die Datenbanversion sein?

[Asura]

Gut, mir sind sowieso noch ein paar Ideen eingefallen, die um die Verwaltung und Bearbeitung der einzelnen Buchungen möglich machen, welches wohl eine Datenbank sehr einfacher zur Verfügung stellen kann.

Ich hatte damals es schon mal versucht. Kannte mich in dem Thema "Verbindung Delphi und Datenbank" überhaupt nicht aus und habe über einen Webdienst, der auch eine Datenbank-Möglichkeit besaß (Ich glaube es war bplaced) dort eine Datenbank mit verschiedenen Tabellen erstellt und über PHP darauf zugegriffen. Sprich: Delphi hat an eine PHP Seite Daten gesendet und bekam die Daten, nach der Verarbeitung des Scripts, von der Website zurück. Sehr umständlich, aber leider wusste ich damals noch nicht wie es anders geht.

Nun meine Frage: Sollte ich nun beispielsweise über Xampp mir die MySQL installieren? Darüber hätte ich auch dann direkt Zugriff über PHPmyadmin auf meine Datenbank und dann (irgendwie?) darüber eine Verbindung zu meinem Programm herstellen? Schlichtweg, ich raffe es nicht, wie und mit was ich hier die Verbindung schaffen kann und ja ich habe auch nach den genannten Stichpunkten gesucht, die bereits genannt wurden über SQLite, FireBird (embedded), Access aber dennoch finde ich dazu kein richtiges: How-To-Do, wie man von Anfang an (Also ab Installation) bis hin zur möglichen Programmierung (Dazu habe ich natürlich sehr viel gefunden) eine Datenbank einbindet.

[haentschman]

Moin...
[meine Meinung]

Zitat:

Sollte ich nun beispielsweise über Xampp mir die MySQL installieren?

...Satan weiche!
[/ meine Meinung]

...versuch es mal damit.
https://firebirdsql.org/manual/qsg25-installing.html
https://firebirdsql.org/en/firebird-2-5/
https://www.delphi-treff.de/tutorial...-und-firebird/

[jobo]

Zitat von haentschman:

Moin...
[meine Meinung]

Zitat:

...MySQL installieren?

...Satan weiche!
[/ meine Meinung]

Seine Meinung ist auch meine Meinung.
Das einzige, was m.E. derzeit "für" mySQL spricht, ist dass es scheinbar allen sofort einfällt.
Schon beim Thema "Weiterentwicklung" erscheinen erste Fragezeichen.

Oder mal bildlich gesprochen:
"Mit welchem Programm soll ich meine Grafiken zeichnen?"
"Installier Dir Windows, dann ist Paint gleich dabei!"

Ja, ich weiß, es hinkt, aber fiel mir grad ein.

[HolgerX]

Hmm..

'Bevor'hier jetzt zu irgendeiner DB geraten wird:

Erst einmal folgende Fragen beantworten:

Anzahl der Verschiedenen PCs, die gleichzeitig auf die Datenbank zugreifen werden?

Stehen die PCs im lokalen Netz oder müssen diese auch über das Internet auf die Daten zugreifen?


Wenn nur ein PC, dann sind lokale/embedded Datenbanken brauchbar (z.B. Access, SQLLite..)
Wenn mehr wie ein/zwei PCs, dann sollte es schon ein DB Server sein (MS-SQLServer (Express), MySQL, Firebird...)
Wenn es eine über Web zu erreichende DB sein soll, dann schau, was dein Provider anbietet, baue dort nen WebService (z.B. per PHP) über den deine App die Daten dort abholt. Bedenke: Es muss von allen PCs das Internet erreichbar sein.

Nun schaue Dir die Lizenzierung/Kosten der jeweiligen DB-Systeme an!
z.B: Wenn dein Programm 'kommerziell' ohne Source-Veröffentlichung verwendet werden soll, dann dürfte das 'mySQL' als lokale Installation schon ausscheiden..

(Die Aufzählung der Datenbanken ist nicht vollständig )