allgemeines zu Datenbanken

Ich habe ein paar Verständnisprobleme zum Thema Datenbanken. Vielleicht kann mir da mal jemand auf die Sprünge helfen. Jeder kennt Datenbanken, jeder nutzt Datenbanken, aber die Frage, wozu sie in der Lage sind ist mir noch unklar. Im eigentlichen Sinne geht es eigentlich darum, warum es so viele Varianten gibt. Ich rede jetzt der Einfachhalt halber mal über den SQL-Server.

Da gibt es den SQLServer Compact, Express, Standard, Enterprise, DataCenter usw.

Bei den großen Versionen, die mit größeren Datenbanken und mehr unterstützten CPU-Kernen trumpfen, kann ich den Unterschied noch verstehen. Aber spätestens bei Compact oder Express verstehe ich den Unterschied in der Funktionalität nicht mehr. Sind die Unterschiede darin begründet, ob ich eine Datenbank lokal oder im Netzwerk verwende?

Wie verwende ich überhaupt eine Datenbank im Netzwerk? Liegt die auf einem Server und wird für alle Nutzer freigegeben? Das ginge doch dann mit einer Compact genauso wie mit einer Express oder?

Und was ist, wenn meine Anwendung (WPF) plötzlich mit Silverlight arbeiten soll, liegt die Datenbank dann irgendwo in einer Cloud oder wie funktioniert das? Die Frage ist also, wie komme ich aus dem Browser an meine Datenbank?

Sorry wird die blöden Fragen. Aber mir fehlt das ein Grundverständnis, was man auch nicht so eibfach mal bei Google suchen kann, weil ich eigentlich nicht weiß nach was ich suchen soll. 😃

Hallo Cannon,

Bei den großen Versionen, die mit größeren Datenbanken und mehr unterstützten CPU-Kernen trumpfen, kann ich den Unterschied noch verstehen.

Genau - da geht's hauptsächlich darum, wie gut die DB skaliert.
Das wird aber nur interessant, wenn riesige Datenbanken von vielen Usern gleichzeitig verwendet werden sollen.

Sind die Unterschiede darin begründet, ob ich eine Datenbank lokal oder im Netzwerk verwende?

Ja - der SQL Server Express ist eine "echte" Datenbank.
Beim SQL Server Compact Edition handelt es hingegen um eine embedded Datenbank.
So lange nur ein User bzw. eine Anwendung gleichzeitig auf die Datenbank zugreift (und sich die Größe der DB in Grenzen hält), macht es quasi kaum einen Unterschied, welche SQL-Server Version du verwendest - meist greift man hier aber zu Comapct Edition, um den SQL Server nicht installieren zu müssen (der "echte" Server bringt ja einen eigenen Dienst etc. mit, während die Compact Edition hauptsächlich aus ein paar DLLs besteht).

Wie verwende ich überhaupt eine Datenbank im Netzwerk? Liegt die auf einem Server und wird für alle Nutzer freigegeben? Das ginge doch dann mit einer Compact genauso wie mit einer Express oder?

Nein, eine einfache Freigabe erlaubt keinen gleichzeitigen Zugriff - da kann dann immer nur ein User gleichzeitig Änderungen vornehmen bzw. lesen.

Der "echte" SQL-Server hingegen erlaubt es auch, dass mehrere Benutzer gleichzeitig Transaktionen auf die Datenbank offen haben können und ermöglicht somit wirklich gleichzeitigen Zugriff (es muss nicht erst gewartet werden, bis die DB wieder "frei" ist, bevor sie verwendet werden kann).
Dabei erfolgt der Zugriff aber nicht direkt "auf die Datenbankdatei", sondern z.B. via TCP/IP auf den Sefrverdienst, der die Koordination übernimmt.

Und was ist, wenn meine Anwendung (WPF) plötzlich mit Silverlight arbeiten soll, liegt die Datenbank dann irgendwo in einer Cloud oder wie funktioniert das? Die Frage ist also, wie komme ich aus dem Browser an meine Datenbank?

Aus SL direkt auf eine Datenbank zuzugreifen ist eher nicht zu empfehlen (u.a. auch wegen Sicherheitsaspekten).
Besser ist da die Verwendung eines Webservice (z.B. mit WCF oder SL RIA).

Vielen Dank für die gute Erklärung. Das heißt jetzt im Falle einer kleineren Anwendungsentwicklung folgendes. Nehmen wir mal eine Firma, die Kundendaten (vielleicht 1000 Kunden pro Niederlassung) verwaltet und 1-5 Niederlassungen hat.

Variante 1:
Firma hat nur eine Niederlassung und entscheidet das bei der Installation. Der SQL Server Compact wäre hier die einfachste Variante.

Variante 2a:
Die Firma hat zwei Niederlassungen und möchte auf beide Bestände zugreifen. Also installieren wir den SQL Server Express auf einem Server auf den beide Standorte zugreifen können und auf beide Clients. Der Server könnte im ungünstigsten Fall sogar einer der Clients sein.

Variante 2b:
Die Firma hat zwei Niederlassungen und möchte separat auf Bestände in getrennten Datenbanken zugreifen. Also installieren wir den SQL Server Express auf beide Clients und greifen ggf. wechselseitig darauf zu.

Variante 3:
Die Firma hat eine Niederlassungen und möchte mittels Notebook (Außendienst) die Kundenbestände mitnehmen. Also installieren wir den SQL Server Express in der FIrma und aufs Notebook und synchronisieren die Daten, wenn der Außendienstmitarbeiter wieder in die Firma kommt.

Habe ich jetzt alles richtig verstanden und sind die Lösungen die Richtigen?

Firma hat nur eine Niederlassung und entscheidet das bei der Installation.

Mit einer kleinen Ergänzung: In der Niederlassung befindet sich nur ein Rechner, der auf die Daten zugreift.

Die Firma hat zwei Niederlassungen und möchte auf beide Bestände zugreifen. Also installieren wir den SQL Server Express auf einem Server auf den beide Standorte zugreifen können und auf beide Clients. Der Server könnte im ungünstigsten Fall sogar einer der Clients sein.

Genau (wobei der "ungünstige" Fall natürlich wirklich sehr ungünstig wäre 😉 ).

Die Firma hat zwei Niederlassungen und möchte separat auf Bestände in getrennten Datenbanken zugreifen. Also installieren wir den SQL Server Express auf beide Clients und greifen ggf. wechselseitig darauf zu

...wobei das vermutlich langfristig darauf hinaufläuft, dass man die Daten in einer DB vereint, um das ständige Geswitche zu vermeiden.

Die Firma hat eine Niederlassungen und möchte mittels Notebook (Außendienst) die Kundenbestände mitnehmen. Also installieren wir den SQL Server Express in der FIrma und aufs Notebook und synchronisieren die Daten, wenn der Außendienstmitarbeiter wieder in die Firma kommt

Durch das "Mitnehmen" kommt man recht schnell zu einer anderen Problematik: Replikation bzw. Synchronisierung von Datenbanken, sodass diese auch offline verfügbar sind und Änderunegn entsprechend übernommen werden.
Hier besteht eine mögliche Lösung in einem SQL Server auf einem Server und pro Client eine Compact Edition.
Siehe hierzu auch: Datensynchronisation verteilter Anwendungen sowie 2 Datenbanken synchron halten

Gut dann habe ich das relativ gut verstanden. Dann ist die flexibelste Lösung die SQL Server Express Variante mit einem Server. Der Server könnte aber auch auf dem WebSpace eines Web-Hosters liegen? Einzige Problematik wäre dann allerdings die Sicherheit. 😦

Ich möchte nochmal auf das Thema zurückkommen, da sich ein paar Gedanken gefestigt haben und ich gerne eure professionelle Meinung hören möchte. Diesbezüglich habe ich mich auch mit dem Funktionsumfang des SyncFramework auseinandergesetzt. Das Kostrukt soll jetzt so aussehen:

Niederlassung 1: 1 Computer, Datenbank SQL Server Compact auf dem Rechner
Niederlassung 2: 2 Computer, Datenbank SQL Server Compact auf jedem Rechner
Zentrale: 1 Computer, Datenbank SQ Server Compact auf dem Rechner

Ziel soll folgendes sein: Jede Niederlassung greift nur auf ihren eigenen Datenbestand zu., sprich kann diesen sehen und bearbeiten. Die Zentrale dagegen soll auf beide Bestände zugreifen können. Die Synchronisation der Daten soll übers Internet erfolgen, was laut der Beschreibung des SyncFramework auch gehen sollte. Das sollte dann auch über 2 Rechner in der gleichen Filiale gehen.

Geht das so? Ist die Compact Variante hier der richtige Ansatz? Und sollten auf allen Rechnern die kompletten Daten gespeichert sein und der Zugriff mittels Nutzerkennung über die GUI erfolgen?

Oder sind die Gedanken völliger Murks und das Ganze ist so nicht umsetzbar?

Hallo Cannon,

die Compact Variante bietet dir serverlosen Zugriff auf eine Datenbankdatei. Du kannst dir das auch wie ein Access-File vorstellen. Sowas macht vielleicht bei einem kleinen Kassaprogram in einem Blumenladen noch Sinn aber sobald mehr als dieser eine Computer inkl. Synchronisierung über mehrere Datenbanken im Spiel ist -> vergiss compact. ((aus meiner Sicht)

Da bist Du falsch informiert.

Sql Compact ( wie alle echten Embedded Datenbanken ) sind durchaus für grosse Datenbestände zu benutzen.
Sql Compact hat eine 4GB grenze und SQLite odet FireBird Embedded haben keine echte Grenze.
Man kann diese Datenbanken für den Singleuser Zugriff bedenkenlos benutzen.

Und genau das ist der Knackpunkt, sobald mehr als ein Benutzer auf die Datenbank zugreift ist ein Server die bessere Wahl.

Und Das Syncframework ist genau für Fälle entwickelt um eben solche Embedded Datenbanken mit eine Hauptdatenbank zu synchronisieren.

Und wenn es nun gar keine Hauptdatenbank gibt, sondern alle Datenbanken untereinander synchron sein sollen? Ich vergleich das mal wie mit der DropBox - da ändere ich Dateien speichere ab und die sind überall synchron. Und so stelle ich mir das vor - ich rede von einer dezentralen Datenbank, die überall synchron ist, vorausgesetzt die Internetverbindung steht. Wenn die Verbindung nicht steht wird sie dann synchronisiert, wenn die Verbindung wieder da ist. Geht das auch mit nur Embedded Datenbanken?

Und du glaubst deine Daten bei DropBox sind nicht Zentral auf deren Server?

Stimmt das Beispiel war blöd. Die Frage ist nur, ob eine dezentrale Synchronisation funktioniert und auch Sinn macht? Denn Alternativ müsste immer irgendwo ein Server zur Verfügung stehen.... was ich eigentlich nicht möchte ...

Du kannst aber nicht einfach von irgendwo auf die Compact/SQlite... Datenbank Datei zugreifen und irgendwas machen.
Das ist sehr langsam ( wenn es denn überhaupt geht ).
Ausserdem ist dann ja auf diese Datei Multiuser Zugriff nötig, denn es kann ja gerade jemand aus der entsprechenden Filiale local zugreifen während du die Synchronisation machen willst.