.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • ACHTUNG - NEUES BLOG

    Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
Download .NET Essentials Installer
Trickkiste

Object Mapping oder doch lieber DataBinding?

22.08.06 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Oft bekommt man in diversen Foren die Frage zu sehen, ob denn nun im eigenen Projekt ein Object Mapping oder doch ein DataBinding verwendet werden soll. Hier ein paar Punkte - aus meiner Sicht - um diese Frage zu beantworten.

Aus meiner Erfahrung sollte Object Mapping dann verwendet werden, wenn untenstehende Fragen mit Ja beantwortet werden können.

* Gibt es jede Menge Data-Objects welche auf ebensolche Tabellen gemappt werden sollen und stammen diese auch alle von der gleichen Basis-Klasse ab?
* Könnte der Fall eintreten, dass das zugrunde liegende Datenbank Management System (DBMS) ausgetauchst wird? Sollte das Projekt generell unterschiedliche DBMSs unterstützen?
* Sind für die Entwicklung der Lösung mehr als 15 Manntage notwendig?
* Soll die Lösung von vielen unterschiedlichen Usern eingesetzt werden? (Open Source Projekt, kostenlose Webanwendung)

Können alle Fragen mit einem klaren Ja beantwortet werden, würde ich persönlich zu einem Object Mapping (beispielsweise NHibernate [1]) raten. In anderen Fällen würde ich dann doch eher ein simples DataBinding vorziehen.

Aber Achtung: Immer gründlich die Zukunft im Auge behalten und nicht immer nur von der Jetzt-Situation ausgehen. Dinge können sich ändern. Wurde einmal eine Entscheidung getroffen, kann diese meist nur mehr sehr schwer geändert werden.

Bei Anregungen oder einfach Dingen die ich nicht bedacht habe, bitte ich einen Kommentar zu hinterlassen.

[1] NHibernate

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


[Tutorial] C# und SQL Server 2005

08.04.06 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Immer wieder stoße ich auf Anfragen, wie denn genau eine Anbindung an den SQL Server 2005 mit C# (oder VB.NET) funktioniert. Grundsätzlich gibt es dazu zahlreiche Tutorials im Internet, die meisten jedoch auf Englisch. Diese Tatsache scheint dann doch sehr viele abzuschrecken. Daher habe ich mich entschlossen, ein Tutorial zu diesem Thema zu verfassen, um eine entsprechende deutschsprachige Ressource bereitstellen zu können.

Inhalt

1. Einführung
2. Verbindung herstellen
3. Daten abfragen
4. Daten hinzufügen
5. Zusammenfassung

1. Einführung

Für den Zugriff auf den SQL Server (2000 oder 2005 ist hierbei unerheblich) werden vom .NET Framework alle notwendigen Funktionen zur Verfügung gestellt. Diese verstecken sich im Namespace System.Data.SqlClient. Für den SQL Server könnten zwar auch die Klassen aus dem Namespace System.Data.OleDb verwendet werden, jedoch ist der DataProvider unter SqlClient auf den SQL Server optimiert und sollte (ausser andere triftige Gründe sprechen dagegen) verwendet werden.

2. Verbindung herstellen

Nun, starten wir damit, eine Verbindung zum SQL Server herzustellen. Dazu verwenden wir die Klasse SqlConnection aus dem oben angegebenen Namespace. Der KLasse SqlConnection muss ein ConnectionString übergeben werden. Dieser definiert wo der SQL Server zu finden ist, welche Datenbank verwendet werden soll und wie die User-Informationen lauten. Beispielsweise würde ein ConnectionString wie folgt aussehen:


Data Source=Aron1;Initial Catalog=pubs;User Id=sa;Password=asdasd;


Die Data Source stellt den Computer dar, auf dem der SQL Server läuft. Zu achten ist hierbei, dass der SQL Server 2005 mit einem Instanznamen angelegt wird, welcher im ConnectionString entsprechend anzugeben ist, da eine Verbindung sonst nicht aufgebaut werden kann. Die Einstellung Initial Catalog beschreibt den Namen der Datenbank auf welche verbunden werden soll. User Id ist der zu verwendende Username und Password sollte selbstsprechend sein. Weitere Informationen zu den ConnectionStrings sind unter [1] zu finden.

In C# sieht ein Verbindungsaufbau nun wie folgt aus:


SqlConnection conn = new SqlConnection(@"Data Source=COMPUTERNAMESQLEXPRESS;Initial Catalog=DatabaseDemo;User Id=sa;Password=MyPassword;");
conn.Open();

conn.Close();


In diesem Fall ist ein SQL Server 2005 Express installiert. COMPUTERNAME stellt den Namen des Computers dar und SQLEXPRESS ist der Instanzname des SQL Servers. Dieser Name wird im Normalfall bei der Installation eingegeben. Ist nicht sicher wie dieser lautet, dann kann dies in der Dienste-Liste ausgelesen werden. Dazu einfach die Dienste anzeigen lassen, den SQL Server Dienst suchen, in Klammer dahinter steht der entsprechende Instanzname.

Durch den obigen C# Code kann man sich nun zur Datenbank verbinden. Für das Öffnen der Verbindung ist die Methode Open() zu verwenden. Close() sorgt für das Schließen der Verbindung.

3. Daten abfragen

Da wir nun eine Verbindung aufbauen können, erfolgt der nächste Schritt: Daten abzufragen. Hierfür werden die Klassen SqlCommand und SqlDataReader verwendet.

Folgender Code übernimmt das für uns:


SqlCommand com = new SqlCommand("SELECT * FROM tPerson", conn);

SqlDataReader reader = com.ExecuteReader();
while (reader.Read())
{
Console.WriteLine("ID: {0}, Firstname: {1}, Lastname: {2}", reader[0].ToString(), reader[1].ToString(), reader[2].ToString());
}
reader.Close();


Hier passiert nun folgendes: Zuerst erstellen wir einen SqlCommand, der auf der Datenbank ausgeführt werden soll. Als Parameter übergeben wir ein SQL-Statement und die geöffnete Verbindung conn.

Danach instanzieren wir einen SqlDataReader. Dieser ist für das Auslesen der Daten zuständig. Der Befehl com.ExecuteReader() sorgt dafür, dass der Command ausgeführt wird und ein DataReader zurückgegeben wird. Mit dem DataReader kann Datensatz für Datensatz durch das Ergebnis iteriert werden, was wir auch mit Hilfe der while-Schleife tun. Nachdem die Daten bezogen wurden, ist der DataReader wieder zu schließen. Darin geben wir die Daten lediglich auf der Console aus. Die Aussgabe würde wie folgt aussehen:


ID: 1, Firstname: Norbert, Lastname: Eder
ID: 2, Firstname: Test, Lastname: Person
ID: 3, Firstname: Franz, Lastname: Nachname


Es empfiehlt sich, auch die weiteren Möglichkeiten der Klasse SqlCommand im MSDN [2] nachzuschlagen, da viele weitere Funktionen zur Verfügung stehen. Alle zu beschreiben würde jedoch den Umfang dieses Tutorials sprengen.

4. Daten hinzufügen

Da wir nun eine der Möglichkeiten gesehen haben wie Daten abgefragt werden können, werden wir nun einen Datensatz hinzufügen. Dies passiert wie folgt:


SqlCommand com = new SqlCommand("INSERT INTO tPerson (Firstname, Lastname) VALUES (@firstname, @lastname)", conn);
com.Parameters.Add(new SqlParameter("@firstname", "fritz"));
com.Parameters.Add(new SqlParameter("@lastname", "huber"));
com.ExecuteNonQuery();


Wieder erstellen wir einen SqlCommand, der ein SQL Statement übergeben bekommt sowie die Datenbankverbindung. Hier passiert dann noch etwas spezielles. Aus Sicherheitsgründen werden die Daten nicht direkt ins SQL Statement geschrieben, sondern via SqlParameter. Dieser Schritt hat einige Vorteile was das Thema SQL Injection etc. betrifft. Sollte also immer in dieser Form angewandt werden. Mittels der ExecuteNonQuery-Methode des SqlCommand-Objektes wird der Befehl auf der Datenbank ausgeführt und der Datensatz eingefügt.

4. Zusammenfassung

Dies war ein kurzer Einblick in die Datenbank-Thematik unter C#. Alle Klassen und Methoden können auf die gleiche Art und Weise unter VB.NET verwendet werden. Es empfielt sich, die angegebenen Klassen im MSDN genauer anzusehen, sowie auch die vorhandenen Beispiele zu den einzelnen Methoden durchzuarbeiten. Danach sollte dieses Thema kein Problem mehr darstellen.

[1] http://www.connectionstrings.com
[2] http://msdn2.microsoft.com oder http://msdn.microsoft.com

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Objekte und relationale Daten in einer Datenbank

13.02.06 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Auf die Beiträge von Thomas und meiner Wenigkeit hat sich auch Alex zu Wort gemeldet. Sein Ansatz (angelehnt an den Microsoft SQL Server 2005) verfolgt das Ablegen von Objekten und relationalen Daten ein einer einzigen DB.

Auch hierzu ein paar Gedanken von mir:

Prinzipiell gibt es den Ansatz der ORDBMS (Objektrelationale Datenbank Management Systeme). Dabei wird ein relationales System um objektorientierte Fähigkeiten erweitert. Oft wird auch nur ein objektorientierte Zugriffsschicht darüberlegt. In der Tat werden allerdings keine Objekte mit relationalen Daten vermischt.

Wie würde das Speichern von Objekten zusammen mit relationalen Daten in einer Datenbank in der Praxis aussehen?

Prinzipiell stehe ich dem Vermischen von Objekten mit relationalen Daten eher negativ gegenüber. Der Ansatz von XML-Feldern in einer Datenbank (siehe SQL Server 2005) ist durchaus praktisch und in manchen Fällen auch sinnvoll. Dies jedoch zu nutzen, um Objekte abzulegen macht eher weniger Sinn. Aus folgenden Gründen (wenn ich von Serialisierung spreche, beziehe ich mich auf die XML-Serialisierung):

- Aufwand der Serialisierung. Bedingt durch diesen Aufwand können die Daten ohnehin wieder in eine relationale Struktur gequetscht werden. Performancemässig wird es hier (allerdings hab ich das jetzt nicht getestet) nicht sehr viel Unterschied geben.

- Weiters verleitet dieser Ansatz dazu, eine Tabelle mit mehreren XML-Feldern zu erstellen und darin serialisierte Objekte abzulegen. Eventuell noch von unterschiedlichen Typen. Spätestens dieser Punkt würde durchaus Probleme aufwerfen.

- Durch das einfache serialisierte Ablegen würden in der Datenbank Referenzen nicht mehr ersichtlich sein. In einem reinen relationalen oder reinen objektorientierten System bleibt dieser Vorteil erhalten. Referenzen in XML sind zwar möglich, aber selbst bei einem eigenen XML-Serializer nützt das Einfügen dieser Referenzen wenig, wenn sie durch die Datenbank nicht dargestellt werden können.

Abfragen sind natürlich auch in dieser Form noch auf der Datenbank möglich ohne alle Daten zu laden, aber durch die Vermischung von SQL und XPATH etc. würde ich meinen, dass der Performance-Vorteil eher gering ausfällt -> dürfte wohl im Minusbereich angesiedelt sein.

Und zu guter Letzt: Diese Variante würde kein gemeinsames Ablegen von Objekten und relationalen Daten implizieren. Das einzige was Sinn machen würde, wäre das Ablegen von relationalen Informationen (Metdaten etc.) zu Objekten - aber ich denke das übernimmt ohnehin die Indizierung für uns.

Soweit mal meine ersten Gedanken dazu. Weitere werden vermutlich noch folgen, wenn ich allen "neuen" Gedanken nachgegangen bin ;-)

  3 Kommentare - 1445 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


OODBMS- Object Oriented DataBase Management Systems

07.02.06 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Bezugnehmend auf den Eintrag von Thomas möchte ich hier noch ein paar Worte zu OODBMS verwenden.

Objektorientierte Datenbanken sind schon sehr nett, aber leider auch nicht für alles einsetzbar. Das schöne daran ist, dass die Objekte an sich gespeichert werden, nicht ein relationales Mapping davon. Dies bedeutet, dass das Mappen von relationalen Daten auf das ursprüngliche Objekt nicht mehr notwendig ist.

Allerdings sehe ich hier doch noch einige Probleme, die nicht unausgesprochen bleiben sollten:

1. Fehlende Standards

Einheitliche Standards zu ORDBMS bzw. OODBMS gibt es nicht - auch wenn es diese Systeme nicht erst seit gestern gibt. Dadurch ist es nicht gewährleistet, dass alle Systeme auf gleiche Art und Weise arbeiten. Object-oriented SQL (OSQL) ist ansich recht nett, aber auch hier gibts die gleichen "Fehler" wie beim herkömmlichen SQL -> Jeder implementiert eine eigene Variante.

2. Backup, Restore, Verteilung etc.

Objekte sind wesentlich komplexer als relationale Strukturen. Entsprechend komplexer wird dadurch auch ein Backup, ein Restore, eine Verteilung oder überhaupt nur die Aktualisierung der Daten, das Nachziehen von Referenzen usw. Diese Dinge sind mit hohem Aufwand verbunden, daher ist eine OODBMS in diesen Gebieten sicherlich langsamer als ein herkömmliches RDBMS.

3. Angst?

Das Thema OODBMS ist ansich genau so alt, wie es objektorientierte Sprachen sind. Letztere haben sich in einigen Bereichen (Enterprise etc.) durchgesetzt. Erstere nicht. Warum? Nun, relationale Datenbanken sind einfacher zu handhaben und wurden über lange Zeit erprobt. Viele haben davor Angst, auf eine "neue" Technologie zu setzen (Anm.: die jedoch nicht viel jünger ist). Dadurch fließt auch nicht soviel Entwicklungsarbeit in objekt-orientierte Ansätze bei Datenbank-Management-Systemen.

4. Fehlende Unterstützung?

Viele Lösungen entstehen und verschwinden entsprechend auch wieder, da die Nutzung nicht vorhanden ist. Ich persönlich kenne nur ein OODBMS welches sich lange gehalten hat. Caché. Alle anderen sind entweder "gemeinnützige" Projekte mit mehr oder weniger geringem Support.

Natürlich gibt es da noch andere Punkte. Der Vollständigkeit halber stehen dem jedoch auch sehr viele Vorteile gegebenüber - keine Frage. Allerdings sehe ich hier db4o nicht unbedingt das als Gelbe vom Ei an. Aber der Weg den db4o beschreitet ist prinzipiell nicht so schlecht.

Just my 2 cents.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück