Kauf- und Kontenverwaltung - Datenbank notwendig?

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

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