NoSql ist kein Ersatz für SQL-Datenbanken, aber eine gültige Alternative für viele Situationen, in denen Standard-SQL nicht der beste Ansatz zum Speichern Ihrer Daten ist.
Da uns beigebracht wurde, dass immer dann, wenn Sie Daten in einem „Data Warehouse“ speichern und diese Daten zur Extraktion abfragen müssen, SQL die beste Lösung ist, müssen Sie sich nur noch entscheiden, welche SQL-Engine Sie verwenden möchten, und das Spiel ist vorbei.
Im Jahr 2012 war dieser Vorschlag falsch, ich meine, dass Sie nicht mehr davon ausgehen können, dass SQL die „einzige Möglichkeit“ ist, Daten zu speichern, aber Sie sollten wissen, dass es andere Alternativen gibt und diese NO SQL heißen. Unter diesem Begriff haben wir verschiedene Speichermechanismen, die nicht auf SQL basieren, und in .NET haben wir ein außergewöhnliches Produkt namens RavenDB (eine wirklich gute Einführung in RavenDb finden Sie im Mauro-Blog).
Der erste große Unterschied zu Standard-SQL ist das Fehlen eines Schemas
Eine der ärgerlichsten Einschränkungen von SQL Server ist die Notwendigkeit, das genaue Format der Daten anzugeben, die Sie in Ihrem Speicher speichern möchten. Dies ist aus vielen guten Gründen notwendig, aber es gibt Situationen, in denen Sie sich wirklich nicht darum kümmern, insbesondere wenn Ihre Software weitgehend auf dem OOP-Konzept basiert. Angenommen, Sie haben dieses Objekt
1: class player
2: {
3: public String Name { get; set; }
4:
5: public DateTime RegistrationDate { get; set; }
6:
7: public Int32 Age { get; set; }
8: }
Für einen Moment gibt es keine Bedenken, dass dieses Objekt schlecht gekapselt ist (es hat eine öffentliche Methode, es zu erhalten und zu installieren), sondern sich nur auf die Notwendigkeit konzentriert, dieses Objekt irgendwo zu „speichern“. Wenn Sie ein Standard-SQL-Repository verwenden, müssen Sie zunächst eine Tabelle erstellen, dann die Spalten definieren, die maximale Länge für die Spalte Name definieren und schließlich das zu verwendende ORM auswählen oder eine dedizierte Datenschicht erstellen und Abschließend können Sie das Objekt speichern.
Wenn Sie mit einer Krähe arbeiten, ist dies der einzige Code, den Sie benötigen
1: var store = new DocumentStore { Url = "http://localhost:8080" };
2: store.Initialize();
3: using (var session = store.OpenSession())
4: {
5: var player = new Player
6: {
7: Age = 30,
8: RegistrationDate = DateTime.Now,
9: Name = "Alkampfer",
10: };
11: session.Store(player);
12: session.SaveChanges();
13: }
Der Server nimmt einfach das Objekt und speichert es.
Um ein Objekt im Data Warehouse zu speichern, sind nur zwei Funktionen erforderlich:„Save“, um dem Repository mitzuteilen, welches Objekt Sie speichern möchten, und „SaveChanges“, die das eigentliche Speichern durchführen.
Was erhalten Sie mit diesem einfachen Codefragment? Rufen Sie einfach den Standardbrowser unter der Serveradresse auf und Sie sollten den Inhalt der Datenbank sehen.
Datenbankinhalte nach dem einfachen Einfügen von Objekten
In Abbildung sehen Sie den Inhalt der Datenbankkrähe, sie enthält einen Spieler und eine kleine 1 neben dem Objekt ist die ID, die Raven intern verwendet, um dieses Objekt eindeutig zu identifizieren. Ein anderes Objekt namens Sys Doc Hilo / Players kümmert sich um die Generierung einer Kennung für das Players-Objekt mit dem Hilo-Algorithmus.
Das ist alles, es besteht keine Notwendigkeit, das Schema zu definieren, es besteht keine Notwendigkeit, eine spezielle ID-Eigenschaft oder andere Anforderungen zu haben, um das Objekt mit dem Repository kompatibel zu machen, rufen Sie einfach die Store-Methode für ein beliebiges .NET-Objekt und Ihr Objekt auf ist in der Datenbank, Punkt!
