SQL Server Compact 4.0 <-> SQLite3


  • Administrator

    Hallo zusammen,

    Ich schreibe gerade an einer .Net Anwendung und überlege aktuell, ob ich nicht doch eine kleine Embedded Datenbank verwenden sollte. Dabei bin ich vor allem auf SQLite3 und SQL CE 4.0 gestossen. Allerdings habe ich mühe gute Vergleiche zu finden. Die meisten raten zu SQLite3, aber meistens ohne irgendwelche Gründe zu nennen oder berufen sich auf SQL CE 3.5 und vorher.

    Was mich an SQLite3 etwas abschreckt ist die fehlende Unterstützung für DECIMAL, da ich mit Geldwerten arbeite. Auch ist mir nicht bekannt, wie gut System.Data.SQLite ist, vor allem in Verbindung mit z.B. dem Entity Framework oder NHibernate.

    Wie sind eure Erfahrungen mit den beiden Datenbanken? Oder würdet ihr gar eine ganz andere Datenbank empfehlen?

    Grüssli



  • Dravere schrieb:

    Wie sind eure Erfahrungen mit den beiden Datenbanken?

    Als Erfahrung kann ich leider nur anbieten dass beide funktionieren 😃
    Da wir SQLite und SQL CE nur in total unterschiedlichen Anwendungen im Einsatz haben, kann ich keinen Vergleich aus eigener Erfahrung anbieten.
    Die DB-Grösse in beiden Fällen ist Pipifax, die Abfragen auch (nix komplexes, alles nur ganz einfache JOINs).

    Oder würdet ihr gar eine ganz andere Datenbank empfehlen?

    Ich "kenne" (namentlich) sonst nur noch VistaDB als embedded Datenbank für .NET.

    Was mich an SQLite3 etwas abschreckt ist die fehlende Unterstützung für DECIMAL, da ich mit Geldwerten arbeite.

    Was mich bei SQLite3 schreckt, ist dass effektiv alle Felder vom Typ "kommt drauf an was drinsteht" sind.

    Was evtl. noch eine Rolle spielen könnte: SQLite kann nur "nested loops" Joins. Heisst: bei bestimmten Abfragen, speziell wenn diese viele Zeilen zurückgeben oder erst spät ausschliessen/gruppieren, kann SQLite böse einbrechen.

    Wie gut SQL CE dabei abschneidet kann ich leider nicht sagen - kenne keinen Vergleich der beiden Systeme der solche Abfragen beinhalten würde.



  • Empfehlen kann ich auch noch Firebird Embedded. Aktuelle Version ist wohl 2.5.1: http://www.firebirdsql.org/en/firebird-2-5-1

    Eine (etwas ältere) Kurzübersicht zur Benutzung gibt es unter http://www.codeproject.com/KB/database/EmbeddedFirebird.aspx

    Und Firebird unterstützt auch direkt DECIMAL (bzw. MONEY), s. http://209.183.20.105/dotnetfirebird/firebird-and-dotnet-framework-data-types-mapping.html und http://firebirdsql.org/manual/migration-mssql-data-types.html

    Und auch NHibernate sowie EF werden unterstützt, s. http://www.firebirdsql.org/en/net-provider


  • Administrator

    Danke euch beiden.

    @hustbaer,
    Meine Datenmenge ist auch nicht so umwerfend gross. Würde mich sehr überraschen, wenn die Datenbank irgendwie zum Bottleneck würde 🙂

    @Th69,
    Firebird sieht zwar interessant aus, aber mir fehlt irgendwie der Support für den ADO.Net Provider. Sei es nur eine Mailing Liste, ein Forum oder ganz einfach aktuelle Dokumentation dazu.
    Im 2007 wurde anscheinend die in-offiziellen Dokumentationseiten eingestellt, um sie mit der offiziellen Seite zusammenzulegen. Nur findet man keinerlei umfassende Dokumentation auf der offiziellen Seite.

    Der Firebird ADO.Net Provider scheitert bei mir schon nur bei der Generierung eines korrekten Connection String mit FbConnectionStringBuilder . Wenn man den dann mit der 1.7 Dokumentation vergleicht, weicht er tatsächlich massiv ab. Aber 1.7 ist auch nicht 2.7.

    Es ist immer das Gleiche mit dieser verdammten Dokumentation. Wenn man nichts zahlt, erhält man meistens auch nichts 🙂

    Grüssli



  • Hi,

    wenn es wirklihc nur eine kleine Datenmenge ist, was spricht dann gegen ms-Access?
    Die ADO-Unterstützung für .mdb-Dateien ist ab XP serienmäßig in Windows integriert, man braucht nur noch zugreifen. Auf dem Zielrechner braucht ncihts installiert zu werden, und man hat für Wartungs- und Reparaturarbeiten an der Datenbank mit Access ein einfaches und funktionierendes überall verfügbares Instrument zur Hand.

    Gruß Mümmel



  • Wir haben mit JET einige schlechte Erfahrungen bezüglich Konsistenz nach Crashes/Power-Loss gemacht.
    Für "soll Wartungsfrei funktionieren" Projekte würde ich JET nimmer verwenden wollen.



  • Der Sql Comapct kann im Mamagement Studio Express bearbeitet werden. Was gegenüber SQL Express fehlt sind stored Proc´s, Advanced Stored Proc´s,Skalarwert Funktionen, Tabellenwert Funktionen und Trigger.

    Die meisten anderen freien DB haben keine vernünftige Visualisierung wie das Management Studio, Programmierbarkeit wie der Sql Express, Rollbacks, Wiederherstellung und Replikation.

    Persönliche Meinung, bei einer App die nur locale Daten benötigt ist die Serialisierung oft die bessere Variation.

    Ist eine Datenbank wirkich erforderlich greife ich zum SQL Express. Die 2008 R2 Version hat ein Limit von 10 GB Datenbankgröße ( gegenüber dem Lizenzlimit von 4 Gb der MySql),kann File Stream Store, EBS und hat wie oben schon erwähnt etliche Features.


Anmelden zum Antworten