Hallo,
ich denke darüber nach, in Zukunft unter Windows 7 und folgenden
Windows-Betriebssystemen Datenbank-Software im klassischen
Fenster-Design mit C# zu programmieren.
Ein paar Sachen sind mir leider noch unklar, da benötige ich mal eure
Hilfe:
Zunächst die Wahl der Datenbank-Systems selbst...Es gibt da ja unter
anderem z.B. MS SQL Server Compact, MS SQL Server Express und MySQL in
die engere Wahl gezogen. Wegen der Beschränkungen bei MS SQL Express
glaube ich kaum, dass ich diese Grenzen in absehbarer Zukunft
überschreiten werde.
Bei Compact kann ich glaube ich nur lokal auf dem Client auf die
Datenbank zugreifen.
MySQL kenne ich von Webservern, da kann man dann wohl auch mal eine
Datenbank programmieren, an der viele Leute gleichzeitig arbeiten. Wie
würde man mit C# und MS SQL Express so etwas wie einen Server und
diverse Clients programmieren, die dann über das Internet auf den Server
zugreigen?
Bei Express und MySQL bin ich mir nicht sicher, wo da abgesehen von der
unterschiedlichen Syntax die wesentlichen Unterschiede bestehen?
Kann man mit allen drei Dialekten einfach und schnell Transaktionen
durchführen? Also ungefähr so:
1. BeginTransaktion
2. Diverse Querys nacheinander auf die DB loslassen...
3. CommitTransaktion
4. Ggf. Rollback.
Dann die Wahl des Connectors...ADO.NET, ODBC oder dieses LINQ? Was nimmt
man da am besten und funktioniert ODBC z.B. auch nach dem nächsten
Visual C# Express ServicePack noch?
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. Da ist mir
nicht ganz klar ob und wie das mit LINQ funktioniert...
Und ich frage mich, wie sinnvoll dieses Abkapseln ist, wenn es gewisse
Unterschiede in der Syntax der verschiedenen Dialekte zu geben scheint?
Schöne Grüße...Thomas
Darf ich vielleicht noch SQLite ins Rennen werfen? Davon gibts auch eine Version für C#. Der Vorteil ist: das Ding ist super klein (wenige KB), und kann direkt mit der Anwendung als Assembly ausgeliefert werden. Eine Extra-Installation und ein im Hintergrund laufender Server sind nicht notwendig. Für den Anwender ist das somit deutlich angenehmer (ich hasse es, wenn eine Anwendung mir mein System mit fetten Datenbank-Systemen vollstopft).
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
Einen .NET Wrapper zu benutzen ist die eine Möglichkeit: https://github.com/praeclarum/sqlite-net Es gäbe auch noch eine komplett in C# geschriebene Version: http://code.google.com/p/csharp-sqlite/
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#.
SQlite hat den einen kleinen nicht zu vernachlaessigen Nachteil: wie sehr der Kunde auch beteuert, dass die Anwendung nur Single-User Anwendung sei und bleiben werde: spaetestens nach dem 2. Jahren kommt er mit der Forderung nach Multi-User. Und da hat man mit SQlite ein Problem.
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.
nimm ein Framework dass mehrere datenbanksysteme unterstützt sowas wird es ja wohl hoffentlich auch für C# geben..
Robert L. schrieb: > nimm ein Framework dass mehrere datenbanksysteme unterstützt Warum nicht gleich eine Datenbank, die das leistet was er braucht? Es ist ja nicht so, dass die man die Datenbank jede Woche wechseln will...
>die das leistet was er braucht?
genau deshalb:
wer weiß da schon, was man braucht ;-)
Robert L. schrieb: > nimm ein Framework dass mehrere datenbanksysteme unterstützt > > sowas wird es ja wohl hoffentlich auch für C# geben.. Das ist eingebaut seit es .NET gibt... 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. http://blogs.msdn.com/b/knom/archive/2009/04/27/linq-to-everywhere-list-of-linq-providers.aspx (irgendwo gibt's mit Sicherheit auch eine aktuellere Liste zusätzlicher LINQ-Provider)
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.
@ Peter II du meinst, man müsste sich dann auf den "kleinsten gemeinsamen nenner" einlassen scheint aber nicht (ganz) zu stimmen: hab gesehen, dass es z.b. Transaktionen geben würde, bei LINQ auch wenn bestimmte Datenbank das bestimmt nicht unterstützen.. und: bestimmte Sachen, wegen 2% Performancesteigerung einfach mal nicht zu machen (Server-Seitige Trigger usw.) ist jetzt langfristig nicht unbedingt immer ein Nachteil.. aber ja: "es kommt drauf an" ist sicher die einzige "richtige" antwort.. man sollte trotzdem möglichkeiten aufzählen dürfen... (oft sucht sich auch der Kunde die Datenbank aus: "ich hab M$ SQL Server und was anders kommt mir nicht ins Haus" ;-) )
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.