Datenbank mit C#

Hallo Boris,

klar darfst Du das! Ich habe aufgrund Deines Vorschlags z.B. den 
folgenden C#-Wrapper gefunden:
http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
Ist das der Richtige?
Gibt es da noch andere? Falls ja, welchen sollte man benutzen und warum?

Schöne Grüße...Thomas

Ich würde dir auch stark SQLite empfehlen, da die Datenbank Datei 
portabel ist. Für anspruchsvolle Sachen würde ich MySQL nehmen, geht 
easy in C#.

Hallo,
wirf mal einen Blick auf MongoDB.org. Tolle Datenbank!

MongoDB hat aber einen vollkommen anderen Ansatz als eine "normale" SQL 
Datenbank und sicherlich nicht für Einsteiger geeignet.

Nimm MySQL, damit hat man erstmal zu tun bis das ausgereizt ist.
Sollen Daten hauptsächlich gelesen werden, dann geht auch SQLite wobei 
das eben kein richtiges Datenbanksystem ist.
Was soll das ganze denn werden? Hört sich jetzt eher nach privatem 
ausprobieren, mal rumspielen an & verstehen der Technik an

also wenn du schon unter windows mit C# arbeitest dann würde ich MS-SQL 
verwenden. Da würde ich mir mysql nicht antun. (je nach Storatype gehen 
Contraints, foreign keys, Transaktionen nicht oder so sachen wie case 
insensitive Tabellennamen ).

funky schrieb:
> MongoDB hat aber einen vollkommen anderen Ansatz als eine "normale" SQL
> Datenbank und sicherlich nicht für Einsteiger geeignet.

Gerade diese "andere" Ansatz ist es, der den Umgang mit MongoDB so 
elegant und einfach gestaltet.

Eine Option wäre sicherlich der Microsoft SQL Server Compact

http://www.microsoft.com/en-us/download/details.aspx?id=17876

Zusammen mit den EntiyFramework hast du gute Optionen.

>Bei Compact kann ich glaube ich nur lokal auf dem Client auf die
>Datenbank zugreifen.

Grundsätzlich hat das aber was mit der Architektur zu tun, etwas weniger 
mit den DB. Auch eine DB, welche mehrere gleichzeitige Zugriffe erlaubt, 
schützt dich nicht vor einer Lösung um konkurrenzierende Zugriffe auf 
die Daten zu verwalten.

Ein Weg ist es sicherlich, in den Clients nicht via DB Verbindungen zu 
arbeiten sondern via REST/WebService eine Service Factory aufzubauen, 
welche ihre Daten in einer DB (oder wo auch immer) hält. Nachteil, etwas 
mehr Overhead in der Umsetzung aber dafür via HTTP. z.B. hier die RIA 
Services.

Arc Net schrieb:
> Ob man jetzt bspw. LINQ gegen eine ausgewachsene MSSQL, Oracle,
> irgendwas oder lokal bspw. gegen eine Liste mit Objekten im Speicher
> ausführt macht keinen Unterschied.

gilt aber nur wenn man nicht anspruchsvolles mit einer Datenbank machen 
will. Jede Datenbank hat fähigkeiten die über den normale SQL 
hinausgehen. Da muss man sich halt fragen was man will.

Robert L. schrieb:
> bestimmte Sachen, wegen 2% Performancesteigerung einfach mal nicht
> zu machen (Server-Seitige Trigger usw.) ist jetzt langfristig nicht
> unbedingt immer ein Nachteil..

ich arbeite (sehr) viel mit SQL-Server. Dort gibt es z.b.

Row_Number (http://msdn.microsoft.com/de-de/library/ms186734.aspx)

und solche sachen wie

select
  sum() over( partition by xyz )
from
  askdf

http://msdn.microsoft.com/de-de/library/ms189461.aspx

das kenn ich von keiner andere DB. (wenn vorhanden, dann bestimmt einen 
anderen Syntax)

oder

merge http://msdn.microsoft.com/de-de/library/bb510625.aspx

damit bekommt man nicht nur 2% Performancesteigerung sondert kann sich 
dazu noch viel Code sparen.

Damit legt man sich aber auf die Datenbank fest.

Minipli-Thomas schrieb:

> Irgendwo habe ich gelesen, dass man die Abfragen und ähnliches besser
> als Parameter an Funktionen übergibt("abkapseln"), um eine spätere
> Portierung auf ein anderes Datenbank-System zu erleichtern.

Dafür gibt es das Repository-Entwurfsmuster:

http://martinfowler.com/eaaCatalog/repository.html
http://devtyr.norberteder.com/post/Das-Repository-Pattern-anhand-eines-Beispiels-inkl-Tests.aspx