NoSql nie zastępuje baz danych SQL, ale jest prawidłową alternatywą w wielu sytuacjach, w których standardowy SQL nie jest najlepszym podejściem do przechowywania danych.
Ponieważ nauczono nas, że za każdym razem, gdy musisz przechowywać dane w „hurtowni danych” i wysyłać zapytania do tych danych w celu ich wyodrębnienia, najlepszym rozwiązaniem jest SQL, musisz tylko zdecydować, którego silnika SQL użyć i gra się kończy.
W 2012 ta sugestia była błędna, to znaczy nie można już zakładać, że SQL jest „jedynym sposobem” przechowywania danych, ale należy wiedzieć, że istnieją inne alternatywy i nazywają się one NO SQL. Pod tym terminem mamy różne mechanizmy przechowywania, które nie są oparte na SQL, a w .NET mamy wyjątkowy produkt o nazwie RavenDB (naprawdę dobre wprowadzenie do RavenDb można znaleźć na blogu Mauro).
Pierwszą dużą różnicą w stosunku do standardowego SQL jest brak schematu
Jednym z najbardziej irytujących ograniczeń SQL Server jest konieczność określenia dokładnego formatu danych, które chcesz przechowywać w swojej pamięci. Jest to konieczne z wielu dobrych powodów, ale są sytuacje, w których naprawdę się tym nie przejmujesz, zwłaszcza jeśli Twoje oprogramowanie jest w dużej mierze oparte na koncepcji OOP. Załóżmy, że masz ten obiekt
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: }
Przez chwilę nie ma obaw, że ten obiekt jest słabo zahermetyzowany (ma publiczną metodę jego pozyskiwania i instalowania), ale skupia się tylko na potrzebie „przechowania” tego obiektu gdzieś. Jeśli korzystasz ze standardowego repozytorium SQL, pierwszą rzeczą, którą musisz zrobić, to utworzyć tabelę, następnie zdefiniować kolumny, zdefiniować maksymalną długość kolumny Nazwa, a na końcu wybrać ORM do użycia lub utworzyć dedykowaną warstwę danych, oraz na koniec możesz zapisać obiekt.
Jeśli pracujesz z wroną, to jedyny kod, którego potrzebujesz
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: }
Serwer po prostu pobiera obiekt i zapisuje go.
Aby zapisać obiekt w hurtowni danych potrzebne są tylko dwie funkcje:„Zapisz”, aby poinformować repozytorium, który obiekt chcesz zapisać, oraz „ZapiszZmiany”, która faktycznie wykonuje zapisywanie.
Co otrzymujesz z tym prostym fragmentem kodu? Po prostu przejdź do standardowej przeglądarki pod adresem serwera i powinieneś zobaczyć zawartość bazy danych.
Zawartość bazy danych po wstawieniu prostego obiektu
Na rysunku widać zawartość bazy danych, zawiera ona gracza, a mała 1 obok obiektu to Id, którego Raven używa wewnętrznie do jednoznacznej identyfikacji tego obiektu. Inny obiekt, Sys Doc Hilo / Players, zajmuje się wygenerowaniem identyfikatora dla obiektu Players za pomocą algorytmu Hilo.
To wszystko, nie ma potrzeby definiowania schematu, nie ma potrzeby posiadania specjalnej właściwości Id ani żadnego innego wymagania, aby obiekt był kompatybilny z repozytorium, wystarczy wywołać metodę Store dla dowolnego obiektu .NET i swojego obiektu jest w bazie danych, okres!
