wir benötigen ein kleine Datenbank bei der Hauptsächlich Leseoperationen ausgeführt werden. Ein paar Stored Procedures sind vorhanden. Das ganze soll ohne eine extra Installation laufen und ist für eine Standalone Desktopanwendung gedacht. SQL Server 2012 LocalDB scheint eine Installation zu benötigen. SQLite scheint ein guter Kandidat. Was würdet ihr empfehlen (inkl. welche .NET API z.B. für SQLite)? Kleiner Nachtrag: .NET 4.0
Ich persönlich nutze für ein paar Projekte, welche eine portable Datenbank ohne Installation benötigen, auch SQLite. Dafür verwende ich den Systen.Data.SQLite-Namespace http://system.data.sqlite.org/
Nicht unerwähnt sollte weiterhin Microsoft SQL Server Compact bleiben, wobei ich da ehrlich gesagt nur den Namen kenne und keine fortführenden Informationen zu habe
Bisher hatte ich damit keine Probleme. Man muss halt beim schreiben eines Commands drauf achten, was SQLite kann und eben nicht kann. Ob SQLite Stored Procedures kann weiß ich gerade auch nicht ausm Kopf, aber anhand der Infoseite was es _nicht_ kann, scheint es zu gehen. Sonst lässt sich über .NET (C#) mit SQLite nicht anders arbeiten als mit anderen Datenbanktypen. Wo man vllt. noch Fehler machen könnte ist der Connectionstring, aber dazu sollte es genug Beispiele geben wie der auszusehen hat.
Ja klar, also mit Sqlite und Firebird hab ich vor jahren mal gearbeitet und war damals mit beiden sehr zu frieden. Sqlite ist schlanker hat dafür aber im Vergleich zu Firebird weniger Features. Firebird unterstützt Proceduren, Trigger, Funktionen etc. und ist somit deutlich Featurereicher. Mit Vistadb hab ich selbst noch nichts gemacht und kann dazu auch nichts sagen.
Zum MS SQL SC kann ich auch keine praktischen Erfahrungen vorweisen, jedoch kenn ich einige Projekte die diesen unterstützen. Hat natürlich den Vorteil das alles was man mittels MS SQL SC entwickelt auch auf den großen Brüdern 1 zu 1 funktionieren sollte und somit eine sehr gut skalierende Lösung ist. Linq2XML ist letztendlich prima für Blogs, kleiner Foren etc. Über all dort wo wenig geschrieben, aber viel gelesen wird. Durch intellegentes Caching auf im ASP.Net oder in deiner Anwendung lassen sich die Leseoperationen auf ein Minimum beschränken.
Zudem kann man das ganze mit einer In-Memory-Database kombinieren und braucht dann nur beim starten und beenden der Anwendung die XML-Dateien anfassen.
Eine Empfehlung ist schwierig abzugeben. Sqlite würd ich dann empfehlen wenn die wenigen Features ausreichen, da sehr schnell und schlank. Firebird ist eine mächtige alternative wenn man mehr Features braucht. MS SQL SC skalliert besser weil man ohne Änderung direkt auf eine MS SQL Server umsteigen kann wenn dies nötig wird.
Wenn du ein ORM wie NHibernate dazwischen schaltest kannst du alle oben genannten DB's und mehr verwenden. Bei einem kleinen Projekt kannst du dich auch leichter einarbeiten.
Wenn bisher der SQL Server z.B. mit dem Entity Framework eingesetzt wurde, also in diesem Bereich Erfahrungen vorliegen, so läßt sich das Schema der DB komplett Eins zu Eins in den SQL Server Compact übernehmen, wenn man bei der Wahl der Entitäten aufpasst (z.B. longdate). Bzgl. EF muss dann nur der ConnectionString geändert werden, an sonsten bleibt das komplette Mapping bestehen. In einem Projekt hatten wir mal eine mobile Version einer Anwendung entsprechend entwickelt. Für den Abgleich eine SQL Server und einer SQL Server compakt DB gibt es auf CodeProject.com eine kleine Anwendung, die wir auch genutzt hatten. Aber SPs funktionieren unter SQL Server Compact nicht. Aber Logik, wo zu auch SPs gehören, gehören ja eigentlich auch nicht in die DB. Gruß Dirk
"Aber Logik, ..., gehören ja eigentlich auch nicht in die DB." Das würde ich so nicht unterschreiben. Natürlich ist ein Zentraler Buisness-Logik-Layer in Form einer WCF-Anwendung der bessere Weg, aber gerade wenn man gemischte Umgebungen hat, ist eine SP dann häufiger doch die erste Wahl um einen Simplen Buisness-Layer aufzubauen. SP können zusammen mit Functions auch sehr gut als primitiver Data-Access-Layer dienen und sind dabei sogar besser als Views da Sie mehr Möglichkeiten zur Statementoptimierung bieten.
Die Meinungen gehen zu diesem Thema immer auseinander. Als Softwareentwickler sind SPs immer böse, weil sie die Wartung und die Weiterentwickelbarkeit der Anwendung gefährden. Ein SQL-DBA sieht dies natürlich ganz anders. Ich habe diese Frage einmal hier auf codekicker explizit gestellt..
Der SQL Compact unterstützt soweit ich weiß keine Stored Procedures.