Kauf- und Kontenverwaltung - Datenbank notwendig?

**Delphi.Narium**

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.

Ja, der Widerspruch ist vorhanden, aber man kann leicht prüfen, ob's nun funktionieren wird oder nicht.

Access ist exotisch, wenn man es aus der Sicht der gleichnamigen Software von MS sieht. Die ist meiner Meinung nach ein Graus.

Nimmt man nur "normales" SQL, dass auch gegen jede andere Datenbank läuft, dann ist die Datenbankdatei einfach nur 'ne Datenbankdatei. Man merkt aus dem Programm heraus (egal ob als Anwendern oder Entwickler) nicht, dass da ein (wie Du sagst) Exot hinter hängt.

Welches sind bitte die "Naheliegenderen Systeme, die nur ein paar Klicks entfernt sind?"

Was muss der Laie tuen, um eine funktionierende Datenbankanwendung schreiben zu können?

Wo muss z. B. bei SQLite die DLL hin?
Wie sieht es bei embedded FireBird aus?

Kann man deren Schnittstellen ggfls. auch zeitgleich für mehrere Programme, aber unterschiedliche Datenbanken nutzen?

Kann eine Datenbank von mehreren Programmen zeitgleich genutzt werden?

Und mir ist klar: Für professionelle Software ist mein Vorschlag absoulut ungeeignet.

**Asura**

Zitat von jobo:

Zitat von Asura:

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.

Diese Anzahl der Personen kann sich jedoch nicht verändern, deswegen sprach ich von Max. 16. Also die Zahl bleibt fest.

Bezüglich der ganzen Datenbankmöglichkeiten: Also ich suche eher ein Datenbanksystem, welches die Datenbankpflege leicht macht (Sprich: In Richtung PhpMyAdmin-Oberfläche) oder in Form der Access-Datenbank, da ich auch das MS Programm zur Datenpflege habe.
Nur ein Gerät (Tablet) wird das Programm besitzen, darüber können dann die maximal 16 Benutzer zugreifen und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen.

Ich dachte anfangs ja einfach an Textdateien, die mit einer Cloud gesichert werden und somit mir auch zugänglich sind. Doch sehe ich ein, dass eine Datenbank, auch in hinblick auf eventuelle Analysefunktionen und erweiternde Programme zur Analyse und Bearbeitung, eher sinnvoll wäre.

**jobo**

@Delphi.Narium
Access möchte z.B. gerne diese häßliche Klammerung bei Objektnamen, nicht Standard.
Aber ich will nicht weiter drauf rumreiten.
Vielleicht ist ja auch die Installation einer sqlite dll ein Problem. Z.B. auf einem Tablet, womit man beim nächsten Beitrag des TE wäre.

Ich gehe mal davon aus, es ist ein Windows Tablet?

Eine komfortable Oberfläche bietet Access natürlich, das kann MS ganz gut.
Etwas wie PHPMyAdmin bieten auch Firebird oder Postgres, für sqlite bekommt man es auch als Browserplugin (Keine Ahnung, wieviele davon unter FF seit Version 57 noch laufen).
Frage wäre auch, was alles so als "Pflege" anfällt.

**Delphi.Narium**

Die hässliche Klammen braucht aber nur die Software von MS, habe das noch bei keiner Delphiapplikation, die u. a. Access-Datenbanken nutzt, benötigt.

Ohne die MS-Oberfläche funktioniert auch Standard-SQL. Nichts mit []`´ und was die per Software meinen alles nutzen zu müssen.

Als "Oberfläche" brauch' ich eigentlich nur:

Ein Memo für die Eingabe von SQL, eine Abfragekomponente, um eben diese auszuführen. Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge. Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert

)

Für FireBird könnte man

FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.

Klar: Bei SQLite kommt die DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.

Da beim TE Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an. Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt". Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch. Wer Sonderzeichen, Leerzeichen ... meint in den Tabellendefinitionen nutzen zu müssen, gehört eh gehauen

und macht es sich schwer, wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.

**haentschman**

Moin...

Auf die Gefahr hin, mir wieder den Mund zu verbrennen...

Zitat:

Ein Memo für die Eingabe von SQL, eine Abfragekomponente, um eben diese auszuführen.

SQL im Klartext einzugeben ist keine gute Idee. Erst Recht für den User. Siehe SQL Injection.

Zitat:

Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge.

...lasse ich mit Ach und Krach durchgehen.

Zitat:

Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert )

Überspitzt ist kein Ausdruck...

Wie kommst du denn darauf? Es gibt haufenweise Techniken die auch die datensensitiven Controls überflüssig machen. Denn die machen dir die Optik der Oberfläche zur Sa..., weil diese nicht als DB Version vorliegen.

Zitat:

Für FireBird könnte man FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.

Zitat:

if you don't have a host name, because yours is a local or embedded Firebird server

...

Zitat:

Klar: Bei SQLite kommt die DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.

3 DDL´s...Der Vorteil ist, das man bei Firebird mit der gleichen Datenbank sowohl Embedded als auch mit dem Server Multi User arbeiten kann.

Zitat:

Da beim TE Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an.

Um Gottes Willen.

Wer behauptet Access sei eine Datenbank sagt auch jeden Tag "Jehowa" und bettelt darum gesteinigt zu werden.

Zitat:

Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt".

...so soll es sein.

Zitat:

Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch.

Bei SQL ist der Standard (SQL-92) das Non plus Ultra! Da weicht Access schon mal ab.

Zitat:

wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.

Das ist mit Access in naher Zukunft zu erwarten, weil die Anforderungen meistens über die erste Vorstellung hinausgehen.

Letztendlich entscheidet der Umfang der Anwendung über das DBMS. Im Moment sind es 16 User...

Zitat:

darüber können dann die maximal 16 Benutzer zugreifen

...das sieht nach einem Mehrbenutzersystem aus. Da scheidet Access schon mal aus.

Zitat:

und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen

Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift?

Bis bald...

**Asura**

Zitat von haentschman:

Zitat:

darüber können dann die maximal 16 Benutzer zugreifen

...das sieht nach einem Mehrbenutzersystem aus. Da scheidet Access schon mal aus.

Zitat:

und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen

Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift?

16 Benutzer können über ein Gerät nur auf das Programm zugreifen, nicht auf die Datenbank!
Auf die Datenbank soll nur ich über meinen Computer Zugriff darauf haben, um dort eventuell Datensätze anzupassen/löschen oder dergleichen.
Also, ich möchte das nur gerne sehr simpel haben und Systeme wie PHPmyAdmin, Access sind für mich simpel. Ohne große SQL Befehle, wenn ich nur mal Tabellen und/oder Datensätze ändern möchte.

**Delphi.Narium**

Zitat von haentschman:

Moin...

Auf die Gefahr hin, mir wieder den Mund zu verbrennen...

Zitat:

Ein Memo für die Eingabe von SQL, eine Abfragekomponente, um eben diese auszuführen.

SQL im Klartext einzugeben ist keine gute Idee. Erst Recht für den User. Siehe SQL Injection.

Ich schrieb für mich und nicht für den User!!!
Außerdem handelt es sich dabei dann nicht um SQL Injection, sondern um fehlerhafte oder falsche oder ungeeignete oder systemzerstörenden SQLs. Aber nicht um "hinterherum" manipulierte Abfragen. SQL-Injection ist: Wenn ich ein vorhandenes SQL, auf das ich direkt keinen Einfluss habe, durch Parametermanipulation und/oder Ausnutzung von Softwareschwachstellen, ein SQL mache, dass der eigentlichen Nutzung zuwiderspricht. Die Eingabe eines SQL-Statments zwecks Ausführung, ist kein SQL-Injection.
Ansonsten wäre ja jedes SQL, das ich in FlameRobin bei "Execute SQL Statement" eingebe, eine SQL-Injection, dito. bei der Nutzung von TOAD für Oracle ...

Zitat von haentschman:

Zitat:

Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge.

...lasse ich mit Ach und Krach durchgehen.

Auch hier: Für mich, für die Entwicklung und nicht für den User!!!

Zitat von haentschman:

Zitat:

Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert )

Überspitzt ist kein Ausdruck...

Wie kommst du denn darauf? Es gibt haufenweise Techniken die auch die datensensitiven Controls überflüssig machen. Denn die machen dir die Optik der Oberfläche zur Sa..., weil diese nicht als DB Version vorliegen.

Ob und wie ich die Daten anzeige, steht auf 'nem anderen Blatt, dass ist (auch mit datenbansensitiven Komponenten) datenbankunabhängig. Kein Control greift selbständig direkt auf die Datenbank zu.

Zitat von haentschman:

Zitat:

Für FireBird könnte man FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.

Zitat:

if you don't have a host name, because yours is a local or embedded Firebird server

...

Zitat:

Klar: Bei SQLite kommt die DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.

3 DDL´s...Der Vorteil ist, das man bei Firebird mit der gleichen Datenbank sowohl Embedded als auch mit dem Server Multi User arbeiten kann.

Zitat:

Da beim TE Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an.

Zitat von haentschman:

Um Gottes Willen.

Wer behauptet Access sei eine Datenbank sagt auch jeden Tag "Jehowa" und bettelt darum gesteinigt zu werden.

Nochmal: Zum professionellen Einsatz nicht geeignet. Wer Office hat und dort Access nutzt, hat damit nunmal eine Datenbank. Ob die nun jedem Profi gefällt, steht doch auf 'nem anderen Blatt.

Zitat von haentschman:

Zitat:

Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt".

...so soll es sein.

Zitat:

Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch.

Bei SQL ist der Standard (SQL-92) das Non plus Ultra! Da weicht Access schon mal ab.

Wenn ich eine Access.mdb nutze ohne die MS-Oberfläche zu nutzen, kann ich mich an das Non plus Ultra! halten, ohne Probleme!!!

Zitat von haentschman:

Zitat:

wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.

Das ist mit Access in naher Zukunft zu erwarten, weil die Anforderungen meistens über die erste Vorstellung hinausgehen.

Sagen wir mal so: Solange ich Access kenne, wird es bald nicht mehr existieren. So seit 20 Jahren?
Die BDE war auch mal "die Datenbankschnittstelle" für Delphi und ist längst Schnee von gestern. Auch DBase war mal "das" relationale Datenbanksystem für PC. Kennt das noch wer? Nein, Schnee von gestern. Das Problem habe ich letztlich mit allem in der EDV.
Wird es Delphi "immer" geben? Keine Ahnung, hoffen wir es.

Zitat von haentschman:

Letztendlich entscheidet der Umfang der Anwendung über das DBMS. Im Moment sind es 16 User...

Zitat:

darüber können dann die maximal 16 Benutzer zugreifen

...das sieht nach einem Mehrbenutzersystem aus. Da scheidet Access schon mal aus.

Zitat:

und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen

Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift?

Es ist kein Mehrbenutzersystem: Der TE schrieb klar und deutlich: Ein Gerät, ein Tablet. Da geht Mehrbenutzersystem nicht! Alle User benutzen das gleiche Gerät, dadurch habe ich zwar mehrere Benutzer aber noch lange kein Mehrbenutzersystem (zumindest hab' ich bisher darunter was anderes verstanden

)

Und Access kann Mehrbenutzer, habe das (wenn auch sehr ungern, eben aus Deinen Gründen) trotzdem für ein paar Kunden meines Arbeitgebers so umsetzen müssen. Und es lief: problemlos und wartungsfrei! (Und auf so 'ne Idee wäre ich freiwillig nie von alleine gekommen!)

Und nochmal nein: Für den professionellen Einsatz nicht geeignet!!!

Und langsam gehen wir vom Thema ab: Es wird eine Grundsatzdiskussion, die einem Anfänger nicht wirklich bei der Entscheidungsfindung hilft. Man kann Access nutzen, muss es aber nicht, es ist eine möglich Option, die man meiner Meinung nach unter Umständen in Betracht ziehen könnte. Diese Ansicht muss man nicht teilen.

Dem TE bleibt es überlassen für sich zu entscheiden, ob diese Möglichkeit für ihn in Betracht kommen könnte oder ob die Argumente dagegen seiner Sicht nach überwiegen. Dann muss er sich für was anderes entscheiden.

Nach dem letzten Beitrag des TE scheint mir hier Access eine durchaus sinnvolle Einstiegsmöglichkeit in die Datenbankprogrammierung. Es ist alles, für die Nutzung der Datenbank und die Entwicklung einer eigenen Software benötigte, vorhanden. Es muss nichts installiert werden, kein Lernaufwand für weitere Software, Oberflächen, Datenbankkonfiguration ...
Hätte ich mit so wenig Aufwand meine ersten Schritte bei der Datenbankentwicklung mit Delphi machen können, wäre ich erstmal zufrieden gewesen.
Bleibe bei der Meinung (trotz aller berechtigter Kritik): Für den Einstieg reicht das aus.

Und wenn es Access irgendwann nicht mehr gibt, ist es auch nicht mehr Teil von MS-Office. Ja: Dann muss man sich Gedanken über ein neues oder anderes Datenbanksystem machen. Wer garantiert uns, dass es dann FireBird, SQLite ... noch gibt?

**mkinzler**

Die Oberfläche hat nichts mit der Datenbank zu tun. Mit der Access-Oberfläche kann man auch auf andere Datenbanksysteme (MSSQL, FireBird, ..) zugreifen und es gibt auch ähnliche Programme für diese.
Sollen mehrere (gleichzeitig) auf die Daten zugreifen können (direkt) fällt Access/SQLite (ohne middleware) dann raus.
JET (das, was man oft als Access bezeichnet) ist möglicherweise vorinstalliert, gehört aber nicht zum Betriebssystem. SQlite im Gegensatz ist Teil einiger Betriebssysteme (iOS, macOS, Android).

**Asura**

Ich habe mich mal an den Access-Versuch ran gemacht.
Funktioniert super, schnell und einfach! Verbindung ist aufgebaut, testweise eine Tabelle als Form in das Programm und er zeigt mir direkt die Einträge in der Datenbank an, die ich vorher über Access hinzugefügt habe.

Ein paar Verständnisfragen kamen hier dennoch auf:

Mir ist nur gerade aufgefallen, wenn ich über das Programm auf die Datenbank zugreife und ich nebenbei einen Eintrag mache und dann die Datei abspeichere, müsste es doch zu Überschneidungen kommen? Nach dem Motto: Das Programm möchte die Datei ändern, durch eine Eintragung, aber ich speichere eine ältere Datenbank ab, um meine neue Änderung manuell zu verwirklichen.
Und liege ich da richtig, wenn ich später mein Programm auf dem Tablet habe, darauf ja auch die Datenbank, damit das Programm darauf zugreifen kann, aber diese Datenbank in einem Cloud-Ordner sich befinden muss, damit ich über meinen Computer auf die Datenbank zugreifen kann?
Kann man eigentlich, solche Komponenten wie ADOConnection etc. irgendwie nicht auf der Form haben? Ich habe die schlichtweg auf die Form gelegt, aber ich finde das eher unschön.
Des Weiteren habe ich nun die Komponenten ADOConnection, ADOTable und Datasource, reicht dies für mein Vorhaben?
Also auch hier wieder: Sehe ich das richtig, wenn ich bei mehreren Tabellen zur Laufzeit einfach nur den Tablename von ADOTable ändern muss, um damit zu arbeiten?
Mir ist noch was aufgefallen, trotzt der neuesten Version von Delphi kann ich nicht die neueste Version von Access Dateien nutzen (accdb), sondern muss auf (mdb) zurückgreifen, woran liegt das?

**Delphi.Narium**

Zitat von Asura:

Ich habe mich mal an den Access-Versuch ran gemacht.
Funktioniert super, schnell und einfach! Verbindung ist aufgebaut, testweise eine Tabelle als Form in das Programm und er zeigt mir direkt die Einträge in der Datenbank an, die ich vorher über Access hinzugefügt habe.

Ein paar Verständnisfragen kamen hier dennoch auf:

Mir ist nur gerade aufgefallen, wenn ich über das Programm auf die Datenbank zugreife und ich nebenbei einen Eintrag mache und dann die Datei abspeichere, müsste es doch zu Überschneidungen kommen? Nach dem Motto: Das Programm möchte die Datei ändern, durch eine Eintragung, aber ich speichere eine ältere Datenbank ab, um meine neue Änderung manuell zu verwirklichen.

Du schriebst: Ein Gerät, ein Benutzer.
Da musst Du Dich dran halten.
Entweder mit dem Programm auf die Datenbank zugreifen, oder mit Access oder mit Delphi, aber nicht mit allen dreien gleichzeitig, das sind dann mehrere Benutzer und Du musst Dir Gedanken über ein Mehrbenutzerkonzept machen, wenn jede Software zeitgleich was ändern soll. Ggfls. gewinnt, wer zuletzt eine Datenänderung schreibt.

Zitat von Asura:

Und liege ich da richtig, wenn ich später mein Programm auf dem Tablet habe, darauf ja auch die Datenbank, damit das Programm darauf zugreifen kann, aber diese Datenbank in einem Cloud-Ordner sich befinden muss, damit ich über meinen Computer auf die Datenbank zugreifen kann?

Du musst die Datenbank dann irgendwie vom Tablet zu PC bekommen (und auch wieder zurück) oder dafür sorge tragen, dass sie an einer Stelle liegt, an der beide Systeme darauf zugreifen können. Aber dabei dürfen dann keine lokalen Kopieen existieren, sonst gehen ggfls. Änderungen verloren, weil die Kopieen ja nicht inhaltlich synchronisiert werden.

Zitat von Asura:

Kann man eigentlich, solche Komponenten wie ADOConnection etc. irgendwie nicht auf der Form haben? Ich habe die schlichtweg auf die Form gelegt, aber ich finde das eher unschön.

Ja kann man, man muss sie zur Laufzeit erstellen. Damit geht dann der Komfort der Entwicklungsumgebung verloren. Und stören die in der Entwicklungsumgebung wirklich so arg?

Zitat von Asura:

Des Weiteren habe ich nun die Komponenten ADOConnection, ADOTable und Datasource, reicht dies für mein Vorhaben?
Also auch hier wieder: Sehe ich das richtig, wenn ich bei mehreren Tabellen zur Laufzeit einfach nur den Tablename von ADOTable ändern muss, um damit zu arbeiten?

Scheint so, sonst würde das, was Du hast, ja nicht funktionieren. Ohne genaue Beschreibung dessen, was Du denn nun jetzt wirklich vorhast, kann man da nicht zu vielem Raten. Sollen immer nur die Daten aus einer Tabelle angezeigt werden oder ggfls. auch mal aus mehreren Tabellen? Sollen Inhalte einer Tabelle ggfls. als Nachschlagwerte für andere Tabellen dienen ...

Zitat von Asura:

Mir ist noch was aufgefallen, trotzt der neuesten Version von Delphi kann ich nicht die neueste Version von Access Dateien nutzen (accdb), sondern muss auf (mdb) zurückgreifen, woran liegt das?

Das liegt nicht an Delphi, sondern an dem genutzten Datenbanktreiber.
Siehe:

https://support.office.com/de-de/art...c-7528b9f074b6

Benötigst Du für Deine Anwendung alles das, was accdb zusätzlich zu mdb bietet?

Überleg' Dir bitte zuerst, was Du genau machen möchtest und halte das irgendwie fest. Dann kannst Du gezielt fragen, was Du wie genau umsetzen kannst. Mit dem bisherigen Input ist eine effektive Hilfestellung nicht möglich.