.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

Häufigkeiten von Wörtern in einer Liste berechnen

24.05.07 - .NET, Base Framework, Datenverwaltung
Beitrag von Norbert Eder
 Heute fand ich eine Frage vor, wie denn ein Array bestehend aus unterschiedlichen Namen durchlaufen werden kann, um die einzelnen Namen und die Anzahl der Vorkommen ausgeben zu lassen. Mein Vorschlag wäre an dieser Stelle eine eigens abgeleitete List<string>. Dies würde so aussehen:
public class NameCounterList : List<string>
{
    private Dictionary<string, int> _names = 
        new Dictionary<string, int>();

    public new void Add(string item)
    {
        base.Add(item);

        if (_names.ContainsKey(item.ToLower()))
            _names[item.ToLower()]++;
        else
            _names.Add(item.ToLower(), 1);
    }

    public new void Clear()
    {
        base.Clear();
        _names.Clear();
    }

    public override string ToString()
    {
        StringBuilder sb = new StringBuilder();
        if (this._names.Count > 0)
        {
            Dictionary<string, int>.Enumerator en = 
                this._names.GetEnumerator();
            while (en.MoveNext())
            {
                sb.Append(en.Current.Key);
                sb.Append(": ");
                sb.Append(en.Current.Value.ToString());
                sb.Append(System.Environment.NewLine);
            }
        }
        return sb.ToString();
    }
}

Die Aufrufe können dann wie folgt aussehen:
NameCounterList ncl = new NameCounterList();
ncl.Add("Peter");
ncl.Add("Harry");
ncl.Add("Sabine");
ncl.Add("Sabine");
ncl.Add("Jörg");
ncl.Add("Harry");
ncl.Add("Harry");
Console.WriteLine(ncl.ToString());

Wodurch sich folgender Output ergibt:
peter: 1
harry: 3
sabine: 2
jörg: 1

Anmerkungen
An dieser Stelle können natürlich noch Verbesserungen vorgenommen werden. Beispielsweise wäre es denkbar, die Werte zu sortieren. Auf der anderen Seite muss jedoch auch erwähnt werden, dass es für große Datenmengen durchaus bessere Möglichkeiten gibt, eine derartige Funktionalität abzubilden. Für kleinere Anwendungsfälle sollte diese Variante aber durchaus ausreichen.

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


SQL Scripter

03.05.07 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Wer ein kleines und einfaches Tool zum Erstellen von DDL-Skripts benötigt (selbst in Zeiten des mächtigen SQL Server Managgement Studios möchte man es nicht immer starten oder gar von Hand schreiben), sollte sich das Tool SQLScripter ansehen. Für manche sicherlich hilfreich.

  2 Kommentare - 776 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


IsolatedStorage (Computerspeicher) verwalten

06.04.07 - .NET, Grundlagen, Datenverwaltung
Beitrag von Norbert Eder
 Wer Konfigurationen oder andere Informationen in den Isolated Storage schreibt, dem wird das Isolated Storage Tool (storeadm.exe) bekannt sein. Wem nicht, der sollte es sich genauer ansehen.

Es handelt sich dabei um eine Konsolen-Anwendung, mit der der Inhalt des IsolatedStorage angezeigt oder gelöscht werden kann. In manchen Fällen durchaus hilfreich.

Das Tool gibt es - wie auch den isolierten Speicher - seit .NET 2.0 und kann einfach über die Visual Studio 2005 Commandline aufgerufen werden.

Wer Informationen dazu benötigt, der sollte sich folgende Links genauer ansehen:
Einführung in die isolierte Speicherung
Szenarien für die isolierte Speicherung

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


Liste der installierten ADO.NET Provider abrufen

14.02.07 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Möchte man überprüfen ob ein bestimmter ADO.NET Provider am System registriert ist, kann dies mit einigen Zeilen Code erledigt werden. Das nachfolgende Beispiel liefert eine Liste aller verfügbaren ADO.NET Provider.

Zu beachten ist an dieser Stelle, dass Provider, die über die App.Config eingebunden wurden, hier ebenfalls mit aufgelistet werden.

private List GetDbFactoryClasses()
{
    List factClasses = new List();
    DataTable dt = DbProviderFactories.GetFactoryClasses();
    if (dt != null)
    {
        foreach (DataRow dr in dt.Rows)
        {
            factClasses.Add(dr[2].ToString());
        }
    }
    return factClasses;
}

Eine Überprüfung ist nicht nur in Problemfällen sinnvoll, sondern sollte auch vor dem Laden eines Providers über DbProviderFactory geschehen. Dadurch kann eine Exception vermieden und der Benutzer entsprechend benachrichtigt werden (oder Eintrag in eine Logdatei und ähnliches).

Zur Vollständigkeit:

Ein Provider kann folgendermaßen dynamisch geladen werden:

// Nur der Vollständigkeit halber
// Wird normalerweise aus einer Konfiguration gelesen
 
string strProviderInvariantName = "System.Data.SqlClient";
string strConnectionString = "...";


// Laden des Providers
// Erstellen der Datenbank-Verbindung
// Zuweisung des notwendigen ConnectionStrings
 
DbProviderFactory dbFactory = 
    DbProviderFactories.GetFactory(strProviderInvariantName);
DbConnection dbConnection = dbFactory.CreateConnection();
dbConnection.ConnectionString = strConnectionString;

Wie bereits in den Code-Kommentaren angemerkt, werden diese Einstellungen normalerweise aus einer Konfiguration geladen oder in einer anderen Form an die Anwendung übergeben. Der Vorteil liegt darin, dass die Anwendung damit mit einem beliebigen ADO.NET Provider ausgeführt werden kann.

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


String in eine XmlNode konvertieren

13.02.07 - .NET, Grundlagen, Datenverwaltung
Beitrag von Norbert Eder
 Es kommt vor, dass XML-Daten in einem String vorhanden sind und man daraus eine XmlNode erstellen muss. Dies ist ja ansich kein Problem, da hierzu die InnerText-Eigenschaft gesetzt werden kann. Was aber, wenn der String eine Node inklusive einiger ChildNodes enthält? Hier ein einfacher Weg die Konvertierung durchzuführen.

XmlDocument doc = new XmlDocument();
doc.Load("categories.xml");
XmlNode xnRoot = doc.SelectSingleNode("/categories");

XmlTextReader xtr = 
    new XmlTextReader(new StringReader(category.ToXml()));

XmlNode xnCategory = doc.ReadNode(xtr);
xnRoot.AppendChild(xnCategory);

Wie zu erkennen ist, wird dazu der XmlTextReader verwendet, da dadurch einfach Xml-Fragmente eingelesen werden können. Mit Hilfe der Methode ReadNode des XmlDocument-Objektes kann nun ein Node generiert werden, welcher anschließend dem Dokument hinzugefügt wird. Anzumerken ist auch, dass die Methode ToXml des Objektes category ein entsprechendes XML-Fragement aus dem besagten Objekt generiert und als String zurückliefert.


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


Daten-Transfer mittels SqlBulkCopy beschleunigen

10.01.07 - .NET, Datenverwaltung
Beitrag von Norbert Eder
 Daten von einem Datenbank-System auf das andere zu verschieben ist ansich keine große Sache. Interesant wird es dann, wenn Performance gefragt ist. Wird das Ziel durch einen Microsoft SQL Server repräsentiert, gibt es seit .NET 2.0 die Klasse SqlBulkCopy, die hier sehr gute Dienste leistet.

Durch ein BulkCopy ist es möglich eine gesamte DataTable zu transferieren ohne sämtliche Commands einzeln abzusetzen.

An dieser Stelle sei darauf hingewiesen, dass ein SqlBulkCopy nur mit einem Microsoft SQL Server als Ziel funktioniert. Die Quelle kann ein x-beliebiges Datenbank Management System darstellen.

Die Verwendung gestaltet sich einfach:

public static void BulkCopy (SqlConnection connection, string destinationTable, DataTable dataTable)
{
SqlBulkCopy sbc = new SqlBulkCopy(connection);
sbc.DestinationTableName = destinationTable;
sbc.WriteToServer(dataTable);
}

In diesem Beispiel werden einer Methode eine gültige Verbindung zu einem SQL Server, der Name der Zieltabelle, als auch eine DataTable übergeben. Mit diesen Informationen ist es möglich die gesamten Daten der DataTable in die Zieltabelle zu kopieren. Hier gilt es zu beachten, dass die Methode WriteToServer weitere Überladungen besitzt, mit der beispielsweise auch ein DataRow-Array kopiert werden kann.

Der Typ SqlBulkCopy bietet jedoch noch weitere Möglichkeiten. Durch die Eigenschaft NotifyAfter ist es möglich eine Benachrichtigung zu definieren. Wird beispielsweise ein Wert von 1.000 gesetzt, wird nach 1.000 verarbeiteten Datensätzen das Event SqlRowsCopied ausgelöst. Dadurch ist es möglich, eine Fortschrittsanzeige zu realisieren.

Weitere Informationen zum Thema Bulk-Copies mit dem Microsoft SQL Server finden sich unter http://msdn2.microsoft.com/en-us/library/system.data.sqlclient.sqlbulkcopy.aspx..
  Kommentar hinzufügen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


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