# Datenbank - filebasiert und tranportabel - welche?



## vierlagig (26 November 2010)

brauche für eine Anwendung eine Datenbank - die Anwendung soll einfach auf vielen, nicht vernetzten Clients zum Einsatz kommen und jeweils eine eigene oder unter wenigen vernetzten Clients geteilte, auf einem netstorage zur Verfügung gestellte DB benutzen (wobei ich in kauf nehmen würde, dass immer nur einer auf die DB zugreifen kann). Vorrausetzung ist, dass die Datenbank-File einfach unter den (nicht vernetzten) Clients kopiert werden kann, ohne sie großartig mounten zu müssen.

habe bis jetzt gefunden:
*SQLite* - sieht recht solide aus - wer hat erfahrungen damit und kann mir mehr darüber erzählen?
*MS SQL Compact* - ist halt MS, womit ich immer weniger ein Problem habe - hat einer Erfahrungen mit dem Handling, am besten aus .net-Anwendungen heraus?
*Access-mdb* - fällt aus, nicht noch einmal!

kennt einer andere und/oder kann zu oben genannten Statements ablassen?


----------



## seeba (28 November 2010)

Wenn du mit .NET programmieren willst, dann nehm die SQL Compact. Denn dann kannst du das Entity Framework nutzen, mit dem man bei Datenbankanwendungen deutlich schneller zum Ziel kommt.


----------



## Rainer Hönle (28 November 2010)

Wenn es auch ein altes Format sein darf: http://www.codebase.com/


----------



## Jochen Kühner (28 November 2010)

Also mit SQLLite hab ich letztes mit meinem Protokoller benutzt. Die einrichtung ist eigentlich recht problemlos. 

Probleme machte aber später die Geschwindigkeit, da es kein multi Insert gibt, und Ich relativ viele Datensätze pro Sekunde speichern musste, kam Ich da schon an die grenzen.

Auch ist der gelchzeitige Zugriff von mehreren Clients aus nicht ohne weiteres möglich, das war mit mdx Files weitaus einfacher!

DBF gibts noch: -> http://www.codeproject.com/KB/database/dbfdotnet.aspx


----------



## vierlagig (29 November 2010)

danke soweit.

SQLite - in der INSERT-geschwindigkeit seh ich keine Probleme. Wie sieht es mit SELECT aus? sollte aber bei den einzelnen DBs abhängig von der Systemleistung an sich sein, oder?

SQL Compact - ja, den Vorteil der Einbettung ins .net-Studio habe ich auch schon erkannt. Darüber hinaus scheint es mir das einzige System zu sein, dass ohne weiteres auf 32 und 64bit zu laufen... (funktioniert SQL Compact eigentlich auch mit dem SQL Server Managment Studio (Express)?  )

bei Rainers "älterem Format" bin ich mir im Detail noch nicht sicher, muß ich noch nachlesen, auch hinsichtlich der 64bit-Kompatibilität...

dbf ist ja eigentlich noch älter ...  ...aber kommt jetzt mit in den Evaluierungsprozess

...ich halt euch auf dem laufenden


----------



## Rainer Hönle (29 November 2010)

vierlagig schrieb:


> bei Rainers "älterem Format" bin ich mir im Detail noch nicht sicher, muß ich noch nachlesen, auch hinsichtlich der 64bit-Kompatibilität...
> 
> dbf ist ja eigentlich noch älter ...  ...aber kommt jetzt mit in den Evaluierungsprozess



Da gibt es nicht nur 32-Bit sondern auch 64-Bit und auch für andere Betriebssysteme als für Windows. Außerdem ist der Quellcode erhältlich. 
Ich hatte in früheren Projekten (letztes Jahrtausend ;-)) mal die Lösung drin. Die Weitergabe war hier extrem einfach. Auch das Anlegen der Datenbanken und Indizes, wenn diese nicht vorhanden sind, ist mit ein paar Codezeilen zu lösen.


----------



## Jochen Kühner (29 November 2010)

vierlagig schrieb:


> danke soweit.
> 
> SQLite - in der INSERT-geschwindigkeit seh ich keine Probleme. Wie sieht es mit SELECT aus? sollte aber bei den einzelnen DBs abhängig von der Systemleistung an sich sein, oder?



Also mit dem Select hatte Ich keine Probleme, warn bei mir ca 2 Mio Datensätze was Ich gepuffert habe, und da dauerte es auch nur Sekunden (Ob die Sekunden nun aber der Select oder das darstellen gekostet hat, habe Ich nicht analysiert.)

Soweit Ich weis, je mehr Systemleistung je schneller...

Für 64 Bit gibts für SQLlite auch Wrapper -> http://www.thomasbelser.net/2009/01/25/c-sharp-und-sqlite-eine-kleine-einfuhrung/

Das DBF Format sollte aber in 64 Bit ja auch funktionieren, da der DBF Provider ja Full Manged Code ist. Das Problem bei dem DBF ist nur, es kann kein SQL!


----------



## Jochen Kühner (5 Dezember 2010)

Bin gerade noch auf folgende Seite gestoßen:

http://www.asp.net/data-access/tutorials/creating-a-data-access-layer-cs

Dort wird auch der Einsatz von SQL Server Express erwähnt. Habs noch nicht ganz durchgelesen, aber ein finde Ich guter Einstig in Datenbanken mit .NET


----------



## drfunfrock (6 Dezember 2010)

Ich kann SQLite uneingeschränkt empfehlen, weil

1) die Installation ist einfach und greift nicht sonderlich tief ins System ein. 
2) Funktioniert auf diversen Betriebssystemen
3) und lässt sich ohne Probleme auf andere DB migrieren.
4) Die Zahl der Tools ist fantastisch Ich verwalte SQLite mit einem Firefox-Plugin.
5) Es funktionieren auch umfangreichere JOINs

und am wichtigsten: 

Die Doku ist klar und kurz. Es ist nicht notwendig darin etwas zu suchen. MS Produkte sind in der Regel auf eine umständliche Weise dokumentiert.


----------



## seeba (6 Dezember 2010)

Ja, die SQL Compact DB-Files lassen sich auch mit dem Management Studio anschauen.
DataSets aus dem verlinkten Tutorial von Jochen sind auch irgendwie überholt, ich kann dir nur das Entity Framework empfehlen. Ein gutes Buch darüber gibt's von O'Reilly (englisch).


----------



## drfunfrock (7 Dezember 2010)

Ach ja, PostgreSQL gibt es auch noch. Die braucht nicht viele Ressourcen und kann von den Fähigkeiten her, es ohne Probleme mit dem SQL-Server aufnehmen. Was interessant sein dürfte, dass man Default-Werte mit einer Funktion belegen kann, wie der Uhrzeit oder einer selbstgeschriebenen Funktion. Trigger gibts natürlich auch. Es sind Sub-Selects möglich, ebenso wie eigene Datentypen.


----------



## Jochen Kühner (7 Dezember 2010)

drfunfrock schrieb:


> Ach ja, PostgreSQL gibt es auch noch. Die braucht nicht viele Ressourcen und kann von den Fähigkeiten her, es ohne Probleme mit dem SQL-Server aufnehmen. Was interessant sein dürfte, dass man Default-Werte mit einer Funktion belegen kann, wie der Uhrzeit oder einer selbstgeschriebenen Funktion. Trigger gibts natürlich auch. Es sind Sub-Selects möglich, ebenso wie eigene Datentypen.



aber PostgreSQL gibt's doch nicht filebasiert, oder?


----------



## drfunfrock (7 Dezember 2010)

Ja und nein. Ja, weil PostgreSQL ein Verzeichnis mit den Dateien anlegt, diese dann aber hinter der Engine verbirgt. Das macht SQLite ebenso, wie das böse Zeugs von Microsoft. Wenn man die Engine nicht direkt in das eigene Programm per Linker integrieren muss, ist PostgreSQL aus meiner Sicht erste Wahl. Die DB kann dann über ODBC, PostgreSQL-Interface oder dieses .Net-Zeugs angesprochen werden.


----------



## Jochen Kühner (7 Dezember 2010)

drfunfrock schrieb:


> Ja und nein. Ja, weil PostgreSQL ein Verzeichnis mit den Dateien anlegt, diese dann aber hinter der Engine verbirgt. Das macht SQLite ebenso, wie das böse Zeugs von Microsoft. Wenn man die Engine nicht direkt in das eigene Programm per Linker integrieren muss, ist PostgreSQL aus meiner Sicht erste Wahl. Die DB kann dann über ODBC, PostgreSQL-Interface oder dieses .Net-Zeugs angesprochen werden.



Ich denke mit Filebassiert, war hier aber wohl eher Serverlos gemeint (oder täusche Ich mich?). Da Filebassiert ja dann wohl jede Datenbank ist (irgendwo müssen die Daten ja landen!) (außer bei expliziten Datenbankbetriebssystemen welche direkt auf Festplatte in einen eigenes Dateisystem schreiben)


----------



## drfunfrock (7 Dezember 2010)

Serverlos geht in keinem Falle  Irgendwo müssen die Daten zentral gelagert werden. Das steht auch im Eingangsposting. Da man das Locking bei einfachen Lösungen dem Betriebssytem überlässt, braucht es schon mal das eine oder andere Experiment. 

Mit Access funktioniert es manchmal, aber nicht immer. Access oder Windows zicken dann ab und zu herum. Selbiges Problem hat man auch mit SQLite, wenn man mit Clients fährt. Da würde ich es gar nicht nehmen. Dann schon lieber die MS-Lösung. SQ-Lite ist etwas für Apps ohne Netzwerk. Meine Empfehlung beruhte darauf, dass ich nicht gründlich genug las. 

Ich benutze gerne Python zusammen mit PostgreSQL und dem Modul Psycopg. Aber auch VB.net ist easy. Mit dem SQL-Server funkt das auf die selbe Weise, kostet aber. 

Meine neueste Idee zum Lagern von Messwerten ist die, dass ich einen Threaded-Server (TCP) mit Python bau (ganz interessant hier ist das Modul Zero Messaging), der dann der die Werte entgegennimmt und sie in eine Queue steckt. Der Sinn dahinter ist, dass ich nicht auf die DB warten muss, wenn Werte geschrieben werden. Während zB. ein Test läuft, kann die DB die Werte vom letzten Test schreiben. Das spart wertvolle Millisekunden. Ich hatte nämlich mal, dass Problem, dass bei einer Maschine mit einer Zykluszeit von 11s, das Schreiben von 200 Messwerten in verschiedene Tabellen etwa 400ms brauchte.


----------



## vierlagig (8 Dezember 2010)

wenn ich nüchtern bin, reden wir drüber ... bis dahin.

und ja, filebasiert heißt, dass ich keinen sever einrichten will (und auf bestimmten zielsystemen vielleicht auch nicht kann)


----------



## drfunfrock (8 Dezember 2010)

Jupp und du willst ein Client-Server-System, denn die Daten sollen deiner Beschreibung nach, auf einem zentralen System landen. Da kannst du auch so etwas wie MS-SQLServer oder Oracle verwenden, weil die Clients nicht wirklich viel können müssen und der Server bei deiner wagen Beschreibung zufolge auch nicht.

Ich würde die Unterscheidung filebasiert und DB gar nicht machen. 

So und nun: 

1) Laut SQlite-Seite: Das Teilen einer DB unter Windows funkt schlecht bis gar nicht, weil das Locking bei manchen Windows-Installationen nicht funktioniert. Kommt also nicht in Frage. 
2) Dann bleibt MS SQL Compact . Die basiert auf dem selben Prinzip wie SQLite. Aber vielleicht kann MS es besser. Hier sind die Chancen gut. 
3) MySQL: Die Installation ist einfach, allerdings kostet die kommerzielle Verwendung. Die Doku ist gut. 
4) MS-Access: Ich empfand das Locking bei Access 2010 nicht wirklich als praktisch. Es gab jede Menge Probleme. Es sind File-Servereinstellungen zu beachten und trotzdem gabs immer wieder Ärger, dass Anwender die Anwendung nicht öffnen konnten. 
5) Sql-Server: Installation ist einfach. Aber die Doku ist grauenhaft. Nach MS seiner Art ist die nicht nur verteilt ohne grösseres Inhaltsverzeichnis, sondern auch einfach umständlich. Ansonsten es funktioniert und das sogar auf WinXp
6) PostgreSQL: Braucht ebenso wie MySQL wenig Speicher, kann aber mehr und ist kostenlos. Die Doku ist übersichtlich und sehr brauchbar. 
7) Direkt in Dateien schreiben: Man kann sich auch gleich selbst umbringen. 
8.Oracle DB: Die ist zu teuer, aber funkt
9. RPC (Remote Procedure Call) per HTTP-Server. Damit kann ein HTTP-Server Anfragen beantworten und bedient eine lokale DB. Mit Python ist das ganz einfach (Siehe Beispiele im Netz). Mit .Net ist es dann sicher auch easy. Der Witz dahinter ist, dass man dann genau einstellen kann, wer Access hat. Es braucht dann kein spezialisiertes DB-Interface auf dem Client. Der Client sendet nur per TCP RPC-Aufrufe und bekommt vom HTTP-Server Antworten zurück. Z.B. mit Web2Py (siehe www.web2py.com) kann man ganz einfach einen XMLRPC-Server bauen.  Das Tool lohnt sowieso, sich mal anzuschauen.


----------



## LowLevelMahn (8 Dezember 2010)

> filebasiert heißt, dass ich keinen sever einrichten will (und auf bestimmten zielsystemen vielleicht auch nicht kann)



@drfunfrock: d.h. er will/kann nicht einen Service laufen lassen, scheinbar hat er aber Zugriff auf ein Netzlaufwerk - damit bleiben nur SQLite, MS-Access und der Compact-Server

Access ist leichtens korrumpierbar - fällt damit mehr aus als alles andere

Ich würde den Compact-Server benutzen


----------



## drfunfrock (8 Dezember 2010)

Es könnte sich aber noch herausstellen, dass MS-SQL-Compact das File-Locking im Netz nicht beherrscht, weil diese DB in erster Linie für das Speichern von Daten einer App konzipiert wurde. Das wäre zu testen.


----------

