NoSql não é um substituto para bancos de dados SQL, mas é uma alternativa válida para muitas situações em que o SQL padrão não é a melhor abordagem para armazenar seus dados.
Como nos ensinaram que sempre que você precisar armazenar dados em um “data warehouse” e consultar esses dados para extração, o SQL é a melhor solução, você só precisa decidir qual SQL Engine usar e o jogo acaba.
Em 2012 essa sugestão estava errada, quero dizer que você não pode mais assumir que o SQL é a “única maneira” de armazenar dados, mas você deve saber que existem outras alternativas e elas se chamam NO SQL. Sob este termo, temos diferentes mecanismos de armazenamento que não são baseados em SQL, e em .NET temos um produto excepcional chamado RavenDB (você pode encontrar uma introdução muito boa ao RavenDb no blog Mauro).
A primeira grande diferença com o SQL padrão é a ausência de um esquema
Uma das limitações mais irritantes do SQL Server é a necessidade de especificar o formato exato dos dados que você deseja armazenar em seu armazenamento. Isso é necessário por muitas boas razões, mas há situações em que você realmente não se importa com isso, especialmente se o seu software é amplamente baseado no conceito OOP. Suponha que você tenha este objeto
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: }
Por um momento, não há preocupação de que esse objeto esteja mal encapsulado (ele tem um método público de obtê-lo e instalá-lo), mas apenas focado na necessidade de “armazenar” esse objeto em algum lugar. Se você usa um repositório SQL padrão, a primeira coisa que você precisa fazer é criar uma tabela, definir as colunas, definir o comprimento máximo para a coluna Nome e, finalmente, selecionar o ORM para usar ou criar uma camada de dados dedicada e finalmente, você pode salvar o objeto.
Se você estiver trabalhando com um corvo, este é o único código que você precisa
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: }
O servidor simplesmente pega o objeto e o salva.
Para salvar um objeto no data warehouse são necessárias apenas duas funções:“Save” para informar ao repositório o objeto que deseja salvar, e “SaveChanges”, que de fato realiza o salvamento.
O que você ganha com este fragmento de código simples? Basta ir ao navegador padrão no endereço do servidor e você deverá ver o conteúdo do banco de dados.
Conteúdo do banco de dados após inserção de objeto simples
Na Figura, você pode ver o conteúdo do corvo do banco de dados, ele contém um player e um pequeno 1 próximo ao objeto é Id, que Raven usa internamente para identificar exclusivamente esse objeto. Outro objeto, chamado Sys Doc Hilo/Players, se encarrega de gerar um identificador para o objeto Players com o algoritmo Hilo.
Isso é tudo, não há necessidade de definir o esquema, não há necessidade de ter uma propriedade Id especial ou qualquer outro requisito para tornar o objeto compatível com o repositório, basta chamar o método Store para qualquer objeto .NET e seu objeto está no banco de dados, período!
