SQL Express Alternative

[berndniph]

hallo,

wir sind auf der suche nach einer ms sql server express alternative.
da der express immer umfangreicher wird, die installation sehr zeitaufwendig ist und wir viel mit attach und detach arbeiten suchen wir eine alternative datenbank.

wir suchen jetzt schon ne woche rum und testen versch. , doch leider ohne positivem ergebnis.

hier mal kurz ne erklärung der anwendung und somit der anforderungen.

unsere kunden arbeiten lokal sowie im netz und auch terminalserver (alles windows). jeder kunde zig datenbankfiles. bei jedem neuen auftrag erzeugen sie ein neues datenbankfile, welches dann am datenbankserver oder lokal (je nach infrastrutktur) abgespeichert wird.
jetzt arbeiten die kunden teilweise in der firma starten unser programm welches die datenbankfiles am jeweiligen sql server attached. teilweise arbeiten mehr am selben fall (multi user). wenn der letzte das programm beendet wird die datenbank wieder detached.
teilweise arbeiten unsere kunden auch auser haus. dazu nehmen sie den ordner mit datenbankfiles , excel files, word usw. mit. unser programm attached dann bei bedarf die files am sql server am laptop.
datenbankgröße atm bis zu 200 mb wobei tendenz steigend.

was wir uns bisher näher angeschaut haben:
1) mysql --> kein attach , detach
2) postrgre --> kein attach, detach
3) sql lite --> transactions sperren die komplette db.
4) sql compact --> kein multiuser
5) msaccess --> atm noch nix dagegen. schneller als sql server bei select ( wundert mich stark) , langsamer bei insert und update.

über ein paar tips würd ich mich sehr freuen.

lg bernd

[fanderlf]

Es kommt drauf an was ihr braucht, aber evtl. wäre auch eine No Sql Datenbank was für euch. Wir haben derzeit z.B. auch ein Projekt mit MongoDB
Ich denke mit dieser wäre auch das Attachen und Detachen relativ problemlos funktionieren. Schließlich liegen die Daten ja nur in einem Ordner auf der Festplatte. Multi User sollten die auch können

Schau mal hier:

www.mongodb.org/

[berndniph]

ist nicht wirklich ne alternative,

da wir alles in sql haben wollten wir zumindest den ansatz beibehalten
und nicht die gesammte applikation neuplanen.

grad am firebird testen. alter ist das langsam im verlgeich zu access oO

[hwoess]

...bei jedem neuen auftrag erzeugen sie ein neues datenbankfile...

Ich denke, man sollte eher da mal darüber nachdenken, denn so eine Aussage stimmt mich schon sehr bedenklich.

bye,
Helmut

[berndniph]

okay,
vielleicht nochmal etwas genauer.

die software gibt es schon 10 jahre oder länger.
geschrieben in vb6 mit msde 2000 damals.

derzeit wird überlegt eine portierung auf .net
sowie ein umstieg bzw weggang von sql express.
(da mit jeder neuen version von sql express die installation schwieriger wird
und wir das den kunden nicht mehr länger antun wollen)

unsere kunden arbeiten sehr viel außer haus teilweise auch im team.
dazu nehmen sie sich daten von datenserver mit uns müssen
die dann abends auch wieder einspielen.
das programm wird gestartet , ein datenbankfile (mandant) ausgewählt.
dieses wird dann geladen und damit gearbeitet.
teilweise arbeiten dann mehrer laptops auf demselben file.
multiuser , transactions werden daher gebraucht.
die arbeit besteht hauptsächlich darin dokumentation zu erstellen,
reihen von fragen zu beantworten welche in einem webbrowser dynamisch reingeladen werden.

mir is schon klar, dass die ganze attach und detach logik
ne totale katastrophe ist.

ev. ist ne non sql datenbank doch in betracht zu ziehen,
nur hab ich mich damit noch überhaupt nie beschäftigt.
ich werd mir mal das mongodb heut anschauen.

für weitere vorschläge würd ich mich sehr freuen.

lg

[fanderlf]

Super dann portiere ich auf .NET und hab im Endeffekt denselben Mist auf dem .NET Framework. Nur weil ich das dann auf dem .NET Framework habe heisst es nicht dass dann alles besser wird/ist.
Zumal man vor 10 Jahren mit Sicherheit auch eine komplett andere Architektur und ein komplett anderes Design hatte als heutzutage.

Warum wollt ihr denn auf das .NET Framework wechseln?

Und von Access würde ich mal ganz schnell meine Finger lassen.

[berndniph]

Super dann portiere ich auf .NET und hab im Endeffekt denselben Mist auf dem .NET Framework. Nur weil ich das dann auf dem .NET Framework habe heisst es nicht dass dann alles besser wird/ist.
Zumal man vor 10 Jahren mit Sicherheit auch eine komplett andere Architektur und ein komplett anderes Design hatte als heutzutage.

Warum wollt ihr denn auf das .NET Framework wechseln?

Und von Access würde ich mal ganz schnell meine Finger lassen.

ja mag sein, nur was ist die alternative ? mongodb ?

ich les mich grad in nosql ein.

[Thomas Steinmaurer]

Ich würde bei einem RDBMS bleiben. Schau dir mal Firebird an. http://www.firebirdsql.org

Gibts für unterschiedliche Plattformen, 32/64-bit, hat alles, was ein gescheites RDBMS braucht, bietet sehr gute Connectivity an (JDBC, .NET, Delphi über Third-Party), Embedded Server für No-Install-Deployment, aber auch richtigen Server etc.

[hwoess]

Irgendwie das Konzept generell mal überdenken könnt/wollt ihr wohl nicht. Aber einfach nur die Datenbank zu wechseln bringt wahrscheilich mehr Nach- als Vorteile. Habe auch einiges durchprobiert, bin aber schlußendlich beim SQL-Server geblieben, da der meiner Meinung nach die meiste Leistung bei "FastNullAufwand"-Administration bietet. Und als Microsoft-Produkt hat er logischerweise die beste Unterstützung von Windows her. Auf das würde ich nicht mehr verzichten wollen.
Und wenn's nur daran liegt, das der SQL-Server Express immer umfangreicher und aufwändiger zu installieren ist, dann bleibt doch einfach bei der MSDE

bye,
Helmut

[fanderlf]

muss ich dir recht geben hwoess. Ich sehe auch nicht dass ein reiner DB wechsel irgendwelche Vorteile bringen sollte. Im Grunde machen sowieso alle DBs dasselbe.
Ich würde auch eher auf Code Seite anfangen was besser zu machen. Ein reiner Port von VB6 auf .NET bringt im Endeffekt nur Bugs, weil sichs doch irgendwie nicht 1 zu 1 portieren lässt. Entweder komplett neu machen und nicht mehr übers alte nachdenken oder mitm alten weitermachen.
Und wenn neu machen, dann bitte auch nicht mit derselben Methodik und denselben Denkansätzen wie vor 10 Jahren. Sonst werdet ihr kaum was von der Portierung haben.

[Wernfried]

Wie wichtig ist denn die SQL Funktion? Nach deiner Beschreibung könnt ihr doch SVN oder ein anderes Versionierungstool nehmen.

Gruss

[Wernfried]

Kombination verschiedener DB's

Hallo Bernd

Mir ist da noch eine Idee gekommen, vielleicht wäre das eine Lösung für euch:

In der Firma installiert ihr eine zentrale Datenbank (MySQL, Oracle, MS SQL Server, etc.). Beim sog. detach wird aus den Daten ein SQlite (oder eine andere stand-alone DB, z. B. MS SQL Server Compact) DB-File erzeugt. Der Kunde kopiert es auf seinen Rechner und arbeitet damit. Je nach Anforderung kann man die SQlite DB auch in der Nacht erzeugen und gleich als Binärdatei in der zentralen DB ablegen.

Beim sog. attach wird die SQlite DB wieder eingelesen und die Daten auf der zentralen DB entsprechend upgedatet.

DIe Methode ist vielleicht ein wenig unkonventionell und die de- und attach Prozeduren verlangen natürlich ein wenig Programmierarbeit von euch, aber ich sehe keinen Grund weshalb es nicht funktionieren sollte.

Gruss
Wernfried

[Ralf Jansen]

Beim sog. attach wird die SQlite DB wieder eingelesen und die Daten auf der zentralen DB entsprechend upgedatet.

Hört sich nach einer selbstgemachten Replikation an. Wenn Replikation im Rahmen der Anwendung denkbar ist wäre, bevor man das selbst programmiert, dann vielleicht wieder die SQL Server - SQL Server Compact Kombination sinnvoll. Eine SQL Compact Datenbank kann Subscriber bei einer Replikation sein.

[Wernfried]

Hört sich nach einer selbstgemachten Replikation an. Wenn Replikation im Rahmen der Anwendung denkbar ist wäre, bevor man das selbst programmiert, dann vielleicht wieder die SQL Server - SQL Server Compact Kombination sinnvoll. Eine SQL Compact Datenbank kann Subscriber bei einer Replikation sein.

Ja genau, je nach Anforderung ist es nicht zwingend nötig, dass die lokale DB eine vollständige Replikation der zentralen DB ist, sondern nur Teile davon in die SQlite, bzw. SQL Server Compact kopiert werden müssen. Die "Teil-Replikation" wäre sicher kleiner und schneller aber dafür geht es nicht per Knopfdruck.

Gruss