Datenbankanwendung mit welcher Technik ?

verwendetes Datenbanksystem: MSSQL SERVER 2005
IDE: Visual Studio 2008

Ich habe schon einige kleinere Anwendungen mit C# geschrieben und nun wurde ich gebeten eine Datensammlung welche immer noch in Excel verwaltet wird in eine Datenbanknzu geben mit einem entsprechenden FrontEnd.

Ich habe mich jetzt mal ein wenig mit den Möglichkeiten eine Datenbank in einee C# Anwendung zu integrieren, beschäftigt. Jetzt stehe ich allerdings vor einem Problem.
Welche Möglichkeit ist die beste für mich ?

1. Datenquelle im Visual Studion hinzufügen und ggf. mit den automatisch generierten DateSets arbeiten
2. ADO.Net Entity Framework 3.5
3. INSERT, UPDATE Methoden von eigenen DataAdaptern nutzen
4. Alles selbst schreiben ( also SQL Statements) und dann entsprechend nur per CMDBuilder an die Datenbank schicken ?

über das zugrunde liegende Schema bin ich mir noch nicht ganz einig, aber ich werde wohl eine Tabelle haben deren Datensätze auf der Auswahl entsprechender Schlüssel in vorherigen Tabellen beruhen. Ich muss also ziemlich oft mehr als 2 Tabellen joinen und mir irgendwelche PrimaryKeys raussuchen. Also welcher der oben genannten Methoden wäre wohl am einfachsten ?

Vielen Dank schon mal 😃

Ich schreib mir die Statements gern selber, denn da hab ich komplett die Kontrolle über die Feldnamen in der Datenbank und den Objekten. Obwohl die ja gleich sein sollten, um sich nicht unnötig Missverständnisse zu machen.
Aber wenns an berechnete Felder geht oder zusammengesetzte oder einfach nur Zähler die man irgendwie nennen muss usw, dann seh ich gern auf einen Blick was ich da wie zurückbekomme, ohne viel in grafischen Designern rumzuklicken. Das ist zwar alles schon komfortabel und auch intelligent gemacht, aber bei mir kommt dann gern der Gedanke, hey wieso schreibst du eigentlich nicht einfach die gewünschten Felder hinter ein SELECT und fertig...

Wenn man was 1:1 darstellen und editieren können will, ist ein DataSet ne schöne Sache. Aber auch dann mache ich mir da meistens meine Statements händisch.
Das ist natürlich alles auch eine Frage des Programms, was das genau mit den Daten macht und wie kompliziert die aufgebaut sind. Wenn du immer alle Felder der Datensätze anzeigen willst, bist du mit einem Entity Framework sicher gut bedient.
Oft gibt es Aktionen bei denen nur eines von vielen Feldern aktualisiert werden soll und der betroffene Datensatz ist dabei gar nicht im Programm geladen. Ein Aktualisierungsdatum oder ein Status oder so. Da wärs dann sündhaft wenn man den erst in eine automatisch generierte Struktur lädt, ein einziges Feld ändert und die Struktur dann wieder rausfinden muss was sich getan hat und die Änderung schreibt...

So viel als Anregung zu Überlegungen 😃

Hallo,

ich würde das ADO.NET Entity Framework verwenden. So kannst du in wenigen Schritten eine Anwendung erstellen die über einen DB Zugriff verfügt. Du kannst dich also um die wesentliche Aufgabe kümmern. Dem anzeigen und bearbeiten der Daten.

Selber SQL Statments schreiben würde ich vermeiden. Generell sind „hardcoded“ Sachen in meinen Augen unnötiger Ballast. Außerdem steckt dann doch einige Arbeit dahinter, wenn man das alles selber machen will. Diese Zeit kannst du dir sparen.
Was ist wenn sich etwas in der DB ändert? Das Model mit dem Entity Framework hast du schnell neu generiert.

Solltest du trotzdem lieber selber mit eigenen SQL Statments arbeiten wollen, würde ich den Einsatz von Views und SPS empfehlen.

@xell83:
Deine Frage zu beantworten ist eigentlich unmöglich.

Wenn Du nur ein paar hundert Datensätze hast, wäre jede der 4 Möglichkeiten übertrieben.
Hast Du Massendaten mit häufigen Aktualisierungen ist ein ORMapper auch eher fehl am Platz.

Hast Du millionen von Datensätzen, mit häufigen Lese Operationen die von Vielen Clients aus kommen, kann auch eine DocumentDB ( NoSql ) besser sein.

Hallo xell83,

wie FZelle schon sagte ist das eine Entscheidung die man von Fall zu Fall treffen sollte und kann generell eigentlich nicht beantwortet werden.

mcsharp.de ist alleine keine ausreichende Quelle um all Möglichkeiten zu vergleichen und zu bewerten, aber einige Threads zu dem Thema kenn ich und wer weiter lesen will kann es dort:
Daten direkt in Formularfelder spielen oder mittels einer eigenen Klasse?
typed oder untyped Dataset
3-Schichten-Design?? [harte vs. weiche (Daten-)Objekte / OOP vs. ActiveRecods]
((es gibt bestimmt noch mehr interesante Threads zu diesen Themen, die man über die Suche finden kann))

Gruß
Juy Juka

Hallö liebe Community,

ich traue mich dann doch auch mal eine Frage zu stellen schluck 😃
zunächst, ich hoffe es ist in Ordung, wenn ich mich diesem Thread anhänge, denn meine Frage ist nahezu identisch - wenn ich die FAQ richtig verstehe darf ich das dann. ;P

Also, worum gehts.
Ich lerne jetzt seit gut 6 Monaten C# mit dem klaren Ziel mir eine Anwendung selbst zu schreiben.
Die Anwendung (Itemverwaltung mit individualisierten Komponenten) möchte ich, sofern der Einsatz von Erfolg gekrönt, einer Community zur verfügung stellen.

Das Herz der Anwendung soll eine Datenbank sein, woraus der User verschiedene Abfragen der Items querien kann, also Filterfunktionen nach Eigenschaften, Hersteller usw.
Die Items selbst erhalte ich über eine API Schnittstelle in Form von XML Dateien, welche ich schon erfolgreich via Code abfrage, vorsortiere und entsprechend den benötigten XML-Elements zusammengekürzt habe. Die rohen XML-Files erreichen dabei eine Gesamtgröße von ca. 400MB auf meiner Platte.
Alles in allem handelt es sich um ca. 180.000 Items, welche sich in grob etwa 20 einzelne Kategorien einteilen lassen würden.

Je nach Kategorie besitzt ein Item zwischen ca. 3 bis 50 verschiedene Eigenschaften, wobei Items einer Kategorie untereinander relativ ähnlich sind. Also jede Kategorie hat einen mehr oder minder typischen Pool aus diesen 50 Eigenschaften, muss jede Eigenschaft aber nicht zwangsläufig haben.

Ich bin nun an einem Punkt wo ich die Daten in eine DB oder Storage-Form zu transferieren möchte, die einerseits Performant ist, mich als relativen Neuling aber auch nicht gleich erschlägt 😉
Zu diesem Zwecke habe ich mir mal verschiedene Möglichkeiten angeschaut.

Zum einen wäre da die XML-Storage, allerdings fürchte ich dass diese zwar einfach zu handlen aber bei bestimmten Abfragen absolut unperformant ist.
Die Queries der finalen Anwendung müssen flexibel sein, das heisst, der Anwender soll frei entscheiden können nach wie vielen und welchen Eigenschaften gefiltert werden soll. Das würde bedeuten ich müsste die gesamten 400MB unter umständen komplett durchparsen. Ohne das jetzt konkret probiert zu haben, würde mir sowas zu lange dauern (ich kenne ähnliche Anwendungen die auf sowas basieren, das dauert dann gerne mal 4-5 Minuten).
Der User selbst soll übrigens nichts an der DB selbst verändern/updaten/deleten (können).

Auf der anderen Seite habe ich mich bereits intensiver in das EF eingelesen (Programming EF 2nd Edition & Code First v. Julie Lerman).
Dieser Ansatz erscheint mir zwar, logischerweise, aufwändiger aber auch deutlich flexibler.

Damit kommen wir zu einem weiteren Eckpunkt. Die Anwendung muss offline arbeiten können. Ich würde je nach Notwendigkeit 2x die Woche oder alle 2 Wochen ein DB-Update fahren, das reicht völlig aus da die Itemdatensätze nicht zu 100% aktuell sein müssen. Desweiteren sind die Möglichkeiten der API-Abfrage recht eingeschränkt.
Jedenfall liebäugele ich daher mit der SQL Compact - Variante.

Hier kommt (endlich 😛) meine konkrete erste Frage.
Ich kann absolut nich abschätzen wie "groß" die Datenbank dann in etwa wird.
Ich möchte dem User aber auch nicht zumuten, sagen wir mal 50-60 MB pro Update ziehen zu müssen (wenn ich das richtig verstanden habe unterstützt CE ja keine Datenkomprimierung, oder?). Schnelle Leitungen hin oder her. aber wenn von den 180.000 Items nur 10.000 geändert wurden wäre das ja sinnloser Traffic die ganze DB komplett neu downzuloaden.
Das ganze in mehrere SDF zu stückeln wäre ja ein Ansatz, allerdings kann ich mir nicht vorstellen dass sich je nach Abfrage gegen zb. 3-10 lokale DBs vernünftig querien lässt?

Ich stecke jetzt noch nicht SO tief in der ganzen Materie drin, dass ich von der Lösung EF & SQLCE überzeugt bin. Möchte mich jetzt aber auch nicht wochenlang mit irgendwas beschäftigen, was sich hinterher als nicht praktikabel oder komplett undurchführbar herausstellt.

Daher stehe ich nun am Scheideweg und bin recht verunsichert.
Welche Lösung wäre denn eurer Erfahrung nach in so einem Fall sinnvoll?
Ich hoffe ich habe das Gesamtprojekt ausreichend genau beschrieben (und niemanden erschlagen mit dieser Textwand hust).
Ich hab kein Problem damit komplett umzudenken und mich woanders völlig neu einzuarbeiten. Daher bin ich für alle Vorschläge offen.
Ansonsten würd ich mich weiter in EF einarbeiten und irgendwie versuchen eine anständige Lösung für das "praktikable Updates vs. pratikable Queries"-Problem zu finden.

Ach und zu guter letzt, meine Entwicklungsumgebung ist VS2010 Ultimate.

Vielen Dank im Voraus 😃
Daniel

Edit: paar SchlechtschreibFehler korrigiert 😃

Das spricht ja schon für eine Datenbank. Die sollte (Annahme von mir) auch weniger Speicher brauchen als alles in XML zu halten.
Die Updates müsstest du je nach Logik der Anwendung selbst ermitteln und auf die Rechner bringen. Du könntest das ja zum Beispiel mittels einer Datenbankdatei tun, deren Inhalt dann in die eigentliche DB eingearbeitet wird.

wenn ich das richtig verstanden habe unterstützt CE ja keine Datenkomprimierung, oder?

Sagt wer? In CE ist vielleicht nichts eingebaut, aber "c# zip lib ce" oder so in der Suchmaschine deines Vertrauens dürfte da schnell Abhilfe schaffen 😃
Daten komprimieren, auf den Rechner spielen und da wieder entpacken, fertig.

Hallo Chillic,

Danke für deine Antwort 😃

zur Datenkomprimierung:
hatte mir hier Unterschiede zwischen SQL Server Compact und SQL Server mal einen Überblick verschafft.
Möglicherweise hab ich da auch etwas falsch verstanden, ich bin jedenfalls davon ausgegangen dass die CE die Daten weniger bzw unkomprimiert speichert. Sprich aus den 400 MB wird eine 300 MB Datei oder so, wie gesagt...kann es nicht abschätzen da bisher keine Erfahrung damit.
Jedesmal eine 300Mb file neu downloaden wäre jedenfalls ein Unding 😉

Die Zip-Erweiterung für C#, darauf bin ich auch schon gestoßen.
Habe dabei gleich mal getestet und Kompressionsraten von SDF-Dateien und XML getestet. Während die 400 MB erwartungsgemäß recht klein wurden (glaub waren um die 40mb) gabs bei ner gezippten SDF nich ganz so viel "Raumgewinn" (hatte testweise mal die Northwind.sdf gepackt, aus den 1,5MB wurden glaub 400kb).
Beides waren in jedem Fall gute Neuigkeiten bzgl. des Problems die updates gering zu halten.

Jedoch bleibt im Fall XML dann das problem des kompletten ausparsens der Files (=unperformant).
Und bei SDF...tja, wenn ich nur eine SDF nehme sind die Abfragen wohl einfach zu machen, wenn ich obiges Beispiel fortführe wären das aber immer noch schätzungweise 60-100MB gepackt.
Und wenn ich für jede einzelne Kategorie einzelne SDFs nehme bin ich mir unsicher ob dann die Queries noch "gut genug" laufen. Ich müsste dann ja jede SDf trotzdem einzeln ansteuern, jeweils ne Collection machen, und wenn ich fertig bin alle Collections zusammenführen.
Da bin ich mir halt unsicher ob das so sinnvoll ist.
Für die Updates wäre das freilich ideal. Einfach ein Check wann die File das letzte mal geändert wurde und ein vergleich zur lokalen SDF gezogen, falls bedarf halt download 😃

Die Datenbank an sich kann sich demnach nicht komprimieren, das ist aber ja nachvollziehbar. Du kannst ja trotzdem die Datei für die Übertragung komprimieren.
Denk dir eine Logik aus anhand der du erkennen kannst welche Datensätze auf dem CE-Rechner wie geändert werden können. Die packst du dann in eine Datenbankdatei, packst die und gibst sie dem PC. Dort wird sie entpackt und durchlaufen, alles was drin steht wird entsprechend in der tatsächlichen DB geändert.
Das wär mein schneller Ansatz.

Hallo Exodus1028,

oder du schreibst dir eine eigene Schnittstelle/Import, den du beim Update benutzt. Das ist natürlich aufwändiger als die DBMS-Funktionen zu nutzen, kann aber entsprechend auch optimiert werden.

Gruß
Juy Juka