NoSql не является заменой для баз данных SQL, но является допустимой альтернативой для многих ситуаций, когда стандартный SQL не является лучшим подходом для хранения ваших данных. Поскольку нас учили, что всякий раз, когда вам нужно хранить данные в «хранилище данных» и запрашивать эти данные для извлечения, SQL является лучшим решением, вам остается только решить, какой Sql Engine использовать, и игра закончена.
В 2012 году это предложение оказалось неверным, я имею в виду, что больше нельзя предполагать, что SQL — это «единственный путь» для хранения данных; но вы должны знать, что существует другая альтернатива, и она называется NO SQL. Под этим термином у нас есть различные механизмы хранения, которые не основаны на SQL, а в .NET у нас есть исключительный продукт под названием RavenDB (вы можете найти действительно хорошее введение в RavenDb в блоге Мауро ).
Первая большая разница со стандартным Sql — это отсутствие схемы. Одним из самых раздражающих ограничений Sql Server является необходимость точно указывать формат данных, которые вы хотите хранить в своем хранилище. Это необходимо по многим веским причинам, но есть ситуации, когда вы действительно не заботитесь об этом, особенно если ваше программное обеспечение в значительной степени основано на концепции ООП . Предположим, у вас есть этот объект
class Player
{
public String Name { get; set; }
public DateTime RegistrationDate { get; set; }
public Int32 Age { get; set; }
}
На мгновение не волнует тот факт, что этот объект плохо инкапсулирован (у него есть общедоступный метод получения и установки), а сосредоточен только на необходимости «хранить» этот объект где-либо . Если вы используете стандартное хранилище Sql, в первую очередь вам необходимо создать таблицу, затем определить столбцы, определить максимальную длину для столбца Имя и, наконец, выбрать ORM для использования или создания выделенного слоя данных, и, наконец, вы можете сохранить объект.
Если вы работаете с вороной, это единственный код, который вам нужен
var store = new DocumentStore { Url = "http://localhost:8080" };
store.Initialize();
using (var session = store.OpenSession())
{
var player = new Player
{
Age = 30,
RegistrationDate = DateTime.Now,
Name = "Alkampfer",
};
session.Store(player);
session.SaveChanges();
}
Я просто создал DocumentStore на основе локального сервера, открыл сеанс и сохранил объект, я ничего не определял на сервере, мне не нужно было ORM, сервер просто берет объект и сохраняет его, точка!
Мне очень понравился этот подход, потому что
Мне нужно было сохранить объект в хранилище данных, и все, что мне нужно, это всего лишь две функции: «Сохранить», чтобы сообщить хранилищу объект, который я хочу сохранить, и «SaveChanges», которые фактически выполняют сохранение.
Что я получил с этим простым фрагментом кода? Просто зайдите в стандартный браузер по адресу сервера, и вы должны увидеть содержимое базы данных.
Рисунок 1: Содержимое базы данных после вставки простого объекта
На рисунке 1 вы можете увидеть содержимое ворону базы данных, он содержит проигрыватель и маленький 1 рядом с объектом является Id , что Raven использует внутренне , чтобы однозначно идентифицировать этот объект. Другой объект, называемый Sys Doc Hilo / Players, заботится о генерации идентификатора для объекта Players с алгоритмом Hilo.
Это все, нет необходимости определять схему, нет необходимости иметь специальное свойство Id или любое другое требование, чтобы сделать объект совместимым с хранилищем, просто вызовите метод Store для любого объекта .NET, и ваш объект находится в базе данных, Period !.
Это всего лишь царапина из многих функциональных возможностей RavenDb 
, более подробно о них можно прочитать в моем блоге и в блоге Мауро .
Джан Мария