Serverlose Datenbank, was nimmt man da? Oder einfach XML?

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Serverlose Datenbank, was nimmt man da? Oder einfach XML?

    Ich muss diverse Stammdaten meines Programms benutzerübergreifend abspeichern und ein "echter" Datenbankserver kommt leider nicht in Frage.

    Ich bin auf Microsoft SQL Server Compact gestoßen, welcher aber wohl seit 2013 nicht weiterentwickelt wird. Die Alternative soll wohl SQL Server Express LocalDB sein.

    Letztendlich könnte ich auch einfach eine XML-Datei benutzen.

    Grundsätzlich sollte es vermieden werden, dass außer dem .NET-.Framework irgendwas auf den Benutzerrechnern installiert werden muss. Die EXE liegt an irgendeinem Ort, wo sie nur hinkopiert wird und wo sie auch übers Netzwerk erreichbar ist, und die Datenbank, was immer ich da nehme, sollte dort auch liegen.

    Was empfielt sich da in meinem Fall?
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum
    Kommt wohl drauf an, wieviel Aufwand Du bei eventuellen Umbauarbeiten vornehmen willst/kannst. Ich würd XML oder SQLite nehmen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    XML dann aber in Verbindung mit typisierten Datasets.

    Für SQLite gibt es zwei wege. Entweder den Standard ADO.NET Weg mithilfe der System.Data.Sqlite library, mit der man dann ebenfalls ein typisiertes Dataset befüllen kann,
    oder, wenn man eher richtung ORM gehen möchte, kann ich das NuGet Paket sqlite-net-pcl Empfehlen. Unterstützt auch direkt async/await, falls benötigt.

    EaranMaleasi schrieb:

    XML dann aber in Verbindung mit typisierten Datasets.
    Denn? Geht ja auch ohne. Aber das ist Geschmacksache.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Marcus Gräfe schrieb:

    benutzerübergreifend
    Wenn mehrere Benutzer gleichzeitig darauf zugreifen sollen, ist XML nicht das richtige.
    SQLite kann mit parallelen Zugriffen zumindest umgehen.
    Das geht aber etwas auf die Performance.
    Wenn du hohen Durchsatz benötigst, kommst du um eine serverbasierte Datenbank nicht herum.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    Es geht nur um gleichzeitig lesen, nicht schreiben. Schreiben macht man quasi nur einmalig nach der Installation über ein Konfigurationsprogramm. Danach ist alles Read-Only. Zudem habe ich insgesamt vielleicht 100 Datensätze. Da müsste XML doch ausreichend sein, oder?

    Bei SQLite müsste ich eine DLL mitgeben, richtig? Das Programm sollte so minimal wie möglich sein, also im Prinzip nur EXE und Datenbankdatei (plus Framework).
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum
    Ja da wird XML ausreichen. Nehm ich auch gerne für kleine Tools um deren Einstellungen zu speichern...
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Da sich die Datenbankanforderung mittlerweile doch etwas geändert hat, entscheide ich mich nun für diesen Weg:

    EaranMaleasi schrieb:

    Für SQLite gibt es zwei wege. Entweder den Standard ADO.NET Weg mithilfe der System.Data.Sqlite library

    Aber eine Frage:

    In der packages.config werden dadurch folgende Pakete eingebunden:

    XML-Quellcode

    1. <package id="EntityFramework" version="6.4.0" targetFramework="net472" />
    2. <package id="System.Data.SQLite" version="1.0.112.0" targetFramework="net472" />
    3. <package id="System.Data.SQLite.Core" version="1.0.112.0" targetFramework="net472" />
    4. <package id="System.Data.SQLite.EF6" version="1.0.112.0" targetFramework="net472" />
    5. <package id="System.Data.SQLite.Linq" version="1.0.112.0" targetFramework="net472" />

    Heißt das, ich muss am Ende insgesamt 5 DLL-Dateien mitgeben? Und wenn ja, dürfen die auch in einem beliebigen Unterverzeichnis meiner Anwendung liegen?
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Marcus Gräfe schrieb:

    dürfen die auch in einem beliebigen Unterverzeichnis meiner Anwendung liegen?
    Du kannst in der app.config, den Suchpfad erweitern.
    docs.microsoft.com/de-de/dotne…specify-assembly-location
    stackoverflow.com/questions/24…an-the-root-of-the-output
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „petaod“ ()

    Danke, das mit dem Pfad ist schon mal gut.

    Aber wie ist das, kann ich davon ausgehen, dass ich pro Zeile eine DLL-Datei brauche?

    Und eine weitere Frage: Nach der Installation von System.Data.SQLite sollte man, laut diverser Tutorials im Netz, danach im SQL Server-Objekt-Explorer die Möglichkeit haben, SQLite als Servertyp auszuwählen. Das taucht aber bei mir nicht auf. Auch bei "Projekt - Neue Datenquelle hinzufügen" ist das nicht auswählbar. Was muss ich dazu noch tun?
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Marcus Gräfe schrieb:

    In der packages.config werden dadurch folgende Pakete eingebunden:

    Aber nur wenn du mit EntityFramework 6 als O/R Mapper arbeiten willst. Kommst du rein mit ADO.Net aus kannst du dir da welche sparen so wie ich das sehe.

    Ich danke aber das für dein Vorhaben wenn ich das richtig verstanden habe kein O/R Mapper benötigt wird da wohl zu viel Overhead.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ich habe es leider immer noch nicht hinbekommen, dass SQlite mit dem "Assistenten zum Konfigurieren von Datenquellen" auswählbar ist, wie es unter docs.microsoft.com/de-de/visua…isual-studio?view=vs-2019 beschrieben wird.

    Ich habe es über den NuGet-Paket-Manager installiert. Laut diverser Quellen im Netz benötigt man aber für mein Vorhaben, also damit SQlite in genannten Assistenten auswählbar ist, ein Paket von der offiziellen Downloadseite, also von hier: system.data.sqlite.org/index.h…/trunk/www/downloads.wiki

    Aber welches muss ich da nehmen? Ich verwende das Framework 4.72, nehme ich dann die 4.6er Version? Ich verwende ein 64bit-Windows, aber VS ist 32bit. Muss ich dann 32 oder 64 nehmen? Laut den Quellen, von denen ich sprach, klappt es nur mit der 32er Version.

    Ich bin verwirrt...

    Was ich vorhabe: Meine extern designte SQlite-Datenbank so einlesen, dass mir das typisierte DataSet angelegt wird (also zur Entwurfszeit).

    EDIT: Ich habe nun die Lösung für mein verbliebendes Problem. Nach ewigem Rumprobieren und der Installation und Deinstallation von verschiedenen Paketen und Extensions habe ich nun die Free-Version von "devart dotConnect for SQLite", dem "ADO.NET Provider for SQLite with ORM Support" (devart.com/dotconnect/sqlite/) installiert, womit ich mich problemlos zu meiner Datenbank verbinden kann und ein typisiertes Dateset mit einem Klick erstellen kann (zur Entwurfszeit). Das SQlite-Paket ist immer noch "System.Data.Sqlite" aus dem NuGet-Paketmanager. Schwere Geburt...
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Marcus Gräfe“ ()