Kauf- und Kontenverwaltung - Datenbank notwendig?

[jobo]

Zitat von HolgerX:

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

[HolgerX]

Hmm..

Zitat von jobo:

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