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.

[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

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

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

Zitat von Delphi.Narium (Beitrag 1387930)

@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 :evil: und seit dem hab ich Ruhe.

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

Gruß
K-H

[Delphi.Narium]

Zitat:

Zitat von p80286 (Beitrag 1387936)

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...:P
[meine Meinung]

Zitat:

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

...Satan weiche! :stupid:
[/ meine Meinung]

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

[jobo]

Zitat:

Zitat von haentschman (Beitrag 1388494)

Moin...:P
[meine Meinung]

Zitat:

...MySQL installieren?

...Satan weiche! :stupid:
[/ 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 ;) )

[jobo]

Zitat:

Zitat von HolgerX (Beitrag 1388509)

Hmm..

'Bevor'hier jetzt zu irgendeiner DB geraten wird:

..

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

Es sind sogar ein paar zuviel :)

Access für Geld und relativ nicht Standard, will man nicht ohne konkrete Indikatoren.
Ebenso andere Systeme "für Geld" oder scheinbar kostenlos.
Das "Thema mySQL" hatten wir ja schon.

[Asura]

Das Programm wird nur unter Freunden (Wie anfangs beschrieben max. 16) verwendet und die Datenpflege soll nur über meinen Computer laufen.

[p80286]

Von Interesse ist jeder Zugriff! Also benötigst Du einen eigenen Server (und sei es dein Rechner)

Gruß
K-H

[jobo]

Zitat:

Zitat von Asura (Beitrag 1388512)

Das Programm wird nur unter Freunden (Wie anfangs beschrieben max. 16) verwendet und die Datenpflege soll nur über meinen Computer laufen.

Unter Freunden ist ein kostenloses Programm ja vielleicht eine gute Wahl. Aber vielleicht sind es ja auch reiche Freunde. Ob Du den Rest Deines Lebens nur 16 Freunde hast oder ob es ein paar mehr werden, spielt bei einer Entscheidung pro Datenbank dann letztlich keine Rolle.
Das Datenmodell sollte allerdings davon ausgehen, dass die Anzahl der Nutzer beliebig ist. Das ist hauptsächlich eine Kopfsache beim Entwurf. Man neigt zur Sparsamkeit mit dieser Zahl im Kopf und trifft falsche Entscheidungen.
Hilfreich wäre in Deinem Fall beim Datenmodell die Vorstellung, die Welt ist voller Freunde, also ein paar Milliarden. Klingt vielleicht bescheuert, ist aber nicht verkehrt. Entspricht in etwa dem Hinweis aus #25 http://www.delphipraxis.net/1387936-post25.html.

[HolgerX]

Hmm..

Zitat:

Zitat von jobo (Beitrag 1388510)

Access für Geld und relativ nicht Standard, will man nicht ohne konkrete Indikatoren.
Ebenso andere Systeme "für Geld" oder scheinbar kostenlos.

Access.. Und Geld.. ?
Wieso?
Alles für die Erstellung/Benutzung einer Access-Datenbank ist auf einem blanken Windows-Rechner schon vorhanden.
Ein Office mit der 'Oberfläche' Access wird nicht benötigt.

Per Delphi kann ich eine neue Access-DB anlegen, Tabellen erzeugen und damit arbeiten....

Vielleicht nicht mehr Stand der Technik, bzw von Microsoft ungeliebt, kann ich es jedoch auf jedem Windowssystem (so ab W2k SP4) ohne Installation verwenden..

Oder habe ich da was verpasst? ;)

[Delphi.Narium]

Benutze häufig Access-Datenbank, aber nie die gleichnamige Software von MS.

Funktioniert, man braucht keinen Server, keine DLLs ...

Wenn die entsprechende Datenbankdatei in 'nem freigegebenen Verzeichnis liegt, ist sogar (ohne irgendwelche Zusätze) ein Mehrbenutzerbetrieb möglich. Klar, nicht unbedingt für tausende Nutzer aber so ein halbes Dutzend geht schon ;-)

Datenbankerstellen geht auch über die ODBC-Verwaltung. (weiß nicht ab welchem Windows und ggfls. bis zu welchem.)

Passende Gebrauchsanweisung findet man mit den Suchbegriffen odbc access db erstellen.

Und wenn man nur einmal eine Datenbankdatei braucht, kann man die so erstellen und muss das nicht extra programmieren.

Da hier aber nur eine Software mit einer Datenbank auf einem Rechner gewünscht ist, der von mehreren Benutzern (nicht zeitgleich) genutzt wird, reicht das vollkommen aus und ist auch für Datenbankunerfahrene recht einfach und leicht erlern- und händlebar.

[p80286]

Da kann ich nur unbedingt von abraten. Wenn es bisher funktioniert hat, dann hast Du Glück gehabt. Und ob Du ODBC oder eine andere Schnittstelle nutzt, eine DLL oder EXE ist immer im Spiel. Es kann sein, daß Du nichts explizit dazu laden mußt, aber ohne geht es nicht. Du brauchst immer eine Schnittstellensoftware und sei sie selbst geschrieben!

Gruß
K-H

[jobo]

@HolgerX,@Delphi.Narium
Ja, habt Ihr recht, früher hab ich das auch mal für Bastelprojekte gemacht. Je nach Installationsstand des Rechners mit/ohne Office dann noch mdac Module nachinstallieren, da gabs sogar extra von MS so ein Prüftool comchecker oder so, das einem dann hoffentlich erzählt hat, was wo noch fehlt. Heute vielleicht irgendwelche anderen Redistributables oder so, da bin ich nicht mehr auf dem Stand, ich denke das meinte auch p80286.
Ob der TE sich das als Anfänger antuen will/sollte, ist eine andere Frage. Erzeugung der Tabellen ist ja dann auch "Handarbeit" (oder man landet dann doch bei einem gefkauften Access für den Entwickler, was ohne Frage halbwegs Komfort für Tabellen und Abfragen stiften würde)
Also, streng genommen ist meine Aussage mit dem Geld falsch.
Aber das Geld würde ich dann doch eher in die oft bejammerte und ach so teure Delphi Version oder extra Datenbankkomponenten stecken, statt in Access.
Was an einem nackten Access Datenfile dann leicht und einfach ist, weiß ich nicht. Es ist von mir bekannten SQL Systemen am weitesten non konform zu SQL Standards, besonders wenn man im SQL noch irgendwelche Jet Funktionen einsetzt.

[Delphi.Narium]

Die Schnittstellensoftware ist hier Teil des Betriebssystem. Sie ist genauso sicher oder unsicher, wie z. B. alle Aufrufe der Windows-API. Es hat bisher funktioniert, aber muss es nicht für immer und alle Zeiten.

Deshalb kann man ja z. B. aktuelle Delphis nicht mehr auf älteren Windosen installieren.

Das Problem habe ich immer. Niemand kann mir garantieren, dass ich mit einem aktuellen FireBird (embedded) für immer und alle Zeiten eine heute geschriebene Software auf allen weiteren Windosen, die es noch so geben wird, nutzen kann. Dergleichen gilt auch für SQLite oder eine Delphiexe, die mit den heute aktuellen Datenbankkomponenten für den Zugriff auf z. B. Oracle geschrieben wurde.

Das beschriebene Problem

Zitat:

Zitat von p80286

Und ob Du ODBC oder eine andere Schnittstelle nutzt, eine DLL oder EXE ist immer im Spiel. Es kann sein, daß Du nichts explizit dazu laden mußt, aber ohne geht es nicht. Du brauchst immer eine Schnittstellensoftware und sei sie selbst geschrieben!

habe ich immer. Ich brauche immer irgendwas, was zwischen meiner Applikation und der Datenbank "hängt". Egal ob ich jetzt eine DLL mitliefere (z. B. SQLite) oder mehrere (z. B. Embedded FireBird) oder über ADO auf Access zugreife oder sonstwie auf welche Datenbank auch immer.

Immer laufe ich Gefahr, dass früher oder später Änderungen an der Schnittstelle und/oder am Betriebssystem eine weitere Nutzung meiner Software verhindern.

Unabhängig von der Schnittstelle: Ich weiß nicht, ob eine heute erstellte Exe mit aktuellem Delphi und aktuellem Windows, in Zukunft weiterhin auf neuer Hardware und/oder neuem Windows funktionieren wird. Es ist eher davon auszugehen, dass dem nicht so sein wird.

Bei (übertrieben) konsequenter Beachtung des oben zitieren Einwandes, wäre von der Nutzung einer Datenbank abzuraten. Es besteht immer potentiell die Möglichkeit, dass es irgendwann nicht mehr funktioniert, weil Änderungen am Betriebssystem und/oder der genutzten Datenbankschnittstelle eine weitere Funktion verhindern. Letztlich sollte man dann auch keine eigene Software erstellen, da auch hier nicht sichergestellt werden kann, dass sie für alle Zeiten auf neuen Rechnern und neuen Betriebssystemversionen funktionieren wird.
Selbst bei der Nutzung von Fremdsoftware hat man keine Garantie, dass man diese immer und für alle Zeiten nutzen kann.

Einen Tod muss man sterben.

Und wenn man gut programmiert, dann baut man sich in die Datenbankanwendung eine Exportfunktion für die Daten ein und ebenso eine Importfunktion. Damit kann man dann schonmal für Datensicherungen ausserhalb der Datenbank sorgen. Dies halte man bitteschön SQL-Standardkonform.

Sollte es die Unterstützung der genutzten Datenbank nicht mehr geben, ändert man das Programm auf die Nutzung einer anderen Datenbank, was mit den aktuellen Datenbankkomponenten kein wirkliches Problem sein sollte, nimmt den letzten Datenexport und importiert ihn in eine neue, andere Datenbank (beliebiger Hersteller) und kann die Software weiter nutzen.

@Jobo:

Egal welche Datenbank: Halte mich an den SQL-Standard, dann sind exotische Sonderlocken diverser Datenbanksystem nicht von belang.

Tabelle erstellen kann man halt mit reinem SQL. Wenn ich FireBird (embedded) oder SQLite nutze, hab' ich ja auch nicht sofort irgendeine komfortable Oberfläche. Für mich ist Access nichts weiter als eine Schnittstelle zu einer Datenbankdatei. Bisher ist sie bei Windows meist dabei. Bei SQLite und FireBird muss ich mich halt selbst drum kümmern.
Rein aus Programmquelltextsicht besteht für mich da kein Unterschied. Man nehmen (z. B. die Zeos-Komponenten oder was man immer auch nutzen möchte), sage der, welche Datenbank sie zu gefälligst zu nehmen habe und gut ist.

So wie Access SQL-technische Besonderheiten hat, haben es FireBird und SQLite auch. MS-Server und Oracle sind auch nicht vollumfänglich kompatibel, noch MySQL und Postgres (und was weiß der Geier noch) dazu und irgendwie passt nix mehr so ohne weiteres zusammen.

Fazit: Egal, was man hier jetzt empfiehlt: Für jeden Lösungsvorschlag finden sich sehr schnell eine Reihe fundierter und berechtigter Gegenargumente.

Mein Vorschlag für Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen ODBC-Treiber für MS-Access anlegen? Wenn nein: Vergiss es!) und für den Anfänger zur Erstellung der ersten Datenbankanwendung erstmal vollkommen ausreichend. Einmal Datenbankdatei erstellen und dann mit Delphi das Programmieren einer einfachen Datenbankanwendung lernen. Wenn man dass dann kann und sich irgendwann mit Datenbanken auskennt, sollte ein Umstieg auf eine beliebige "professionelle" Datenbank dann kein Problem sein.

Für eine Unternehmenssoftware jedoch sicherlich eher induskutabel.

[jobo]

Zitat:

Zitat von Delphi.Narium (Beitrag 1388563)

Die Schnittstellensoftware ist hier Teil des Betriebssystem.
..snip..
Mein Vorschlag für Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen ODBC-Treiber für MS-Access anlegen? Wenn nein: Vergiss es!)
..

Widerspricht sich das nicht?

Treiber hin oder her, ich müsste auch für andere Systeme Treiber installieren (außer meine Delphikomponenten machen das nativ).
Access halte ich aus diversen Gründen für "exotisch" und nicht naheliegend, weder für Anfänger noch Fortgeschrittene. Naheliegendere Systeme sind nur ein paar Klicks entfernt.