Acabei de começar com bancos de dados não relacionais e ainda estou tentando entender isso e descobrir qual seria o melhor modelo. E só posso falar pelo CouchDB.
Ainda assim, tenho algumas conclusões preliminares:
Você criou designs alternativos que funcionam muito melhor no mundo não relacional?
O foco do design muda: O design do modelo de documento (correspondendo às tabelas do banco de dados) torna-se quase irrelevante, enquanto tudo depende do design das visualizações (correspondentes às consultas).
O tipo de banco de dados de documentos troca as complexidades: o SQL tem dados inflexíveis e consultas flexíveis, os bancos de dados de documentos são o contrário.
O modelo CouchDB é uma coleção de "documentos JSON" (basicamente tabelas hash aninhadas). Cada documento possui um ID exclusivo e pode ser facilmente recuperado por ID. Para qualquer outra consulta, você escreve "visualizações", que são conjuntos nomeados de funções mapear / reduzir. As visualizações retornam um conjunto de resultados como uma lista de pares chave / valor.
O truque é não consultar o banco de dados no sentido de consultar um banco de dados SQL: os resultados da execução das funções de exibição são armazenados em um índice e apenas o índice pode ser consultado. (Como "obter tudo", "obter chave" ou "obter intervalo de chaves".)
A analogia mais próxima no mundo SQL seria se você pudesse apenas consultar o banco de dados usando procedimentos armazenados - toda consulta que você deseja oferecer suporte deve ser predefinida.
O design dos documentos é extremamente flexível. Encontrei apenas duas restrições:
- Mantenha os dados relacionados juntos no mesmo documento, pois não há nada que corresponda a uma junção.
- Não torne os documentos tão grandes a ponto de serem atualizados com muita frequência (como colocar todas as vendas da empresa para o ano no mesmo documento), pois cada atualização de documento aciona uma reindexação.
Mas tudo depende do design das vistas.
Os designs alternativos que descobri que funcionam melhor com o CouchDB do que com qualquer banco de dados SQL em ordens de magnitude, e não no nível de armazenamento, mas sim no nível do sistema. Se você possui alguns dados e deseja veiculá-los em uma página da web, a complexidade do sistema total é reduzida em pelo menos 50%:
- sem criação de tabelas de banco de dados (pequeno problema)
- nenhuma camada intermediária ODBC / JDBC, todas as consultas e transações via http (problema moderado)
- mapeamento simples de banco de dados para objeto de JSON, que é quase trivial em comparação com o mesmo em SQL (importante!)
- você pode potencialmente ignorar todo o servidor de aplicativos, pois pode projetar seus documentos para serem recuperados diretamente pelo navegador usando AJAX e adicionar um pouco de polimento de JavaScript antes de serem exibidos como HTML. (IMENSO!!)
Para webapps normais, bancos de dados baseados em documento / JSON são uma grande vitória, e as desvantagens de consultas menos flexíveis e alguns códigos extras para validação de dados parecem um preço pequeno a pagar.
Você bateu com a cabeça em algo que parece impossível?
Ainda não. Mapear / reduzir como meio de consultar um banco de dados não é familiar e requer muito mais raciocínio do que escrever SQL. Há um número relativamente pequeno de primitivas, portanto, obter os resultados de que você precisa é principalmente uma questão de ser criativo ao especificar as chaves.
Há uma limitação em que as consultas não podem olhar para dois ou mais documentos ao mesmo tempo - nenhuma junção ou outros tipos de relacionamentos de vários documentos, mas nada até agora foi intransponível.
Como limitação de exemplo, contagens e somas são fáceis, mas as médias não podem ser calculadas por uma visualização / consulta CouchDB. Correção: Retorne a soma e conte separadamente e calcule a média no cliente.
Você preencheu a lacuna com algum padrão de projeto, por exemplo, para traduzir de um para o outro?
Não tenho certeza se isso é viável. É mais um redesenho completo, como traduzir um programa de estilo funcional para um estilo orientado a objetos. Em geral, existem muito menos tipos de documentos do que tabelas SQL e mais dados em cada documento.
Uma maneira de pensar nisso é examinar seu SQL em busca de inserções e consultas comuns: quais tabelas e colunas são atualizadas quando um cliente faz um pedido, por exemplo? E quais para relatórios de vendas mensais? Essa informação provavelmente deve ir no mesmo documento.
Ou seja: Um documento para Pedido, contendo ID de cliente e ID de produto, com campos replicados conforme necessário para simplificar as consultas. Qualquer coisa dentro de um documento pode ser consultada facilmente, qualquer coisa que requeira referência cruzada entre, digamos, o Pedido e o Cliente, deve ser feito pelo cliente. Portanto, se você deseja um relatório de vendas por região, provavelmente deve inserir um código de região no pedido.
Você pelo menos faz modelos de dados explícitos agora (por exemplo, em UML)?
Desculpe, nunca fiz muito UML antes de documentar bancos de dados :)
Mas você precisa de algum tipo de modelo que diga quais campos pertencem a quais documentos e quais tipos de valores eles contêm. Para sua própria referência posterior e para se certificar de que todos os usuários do banco de dados conheçam as convenções. Uma vez que você não receberá mais um erro se armazenar uma data em um campo de texto, por exemplo, e qualquer pessoa puder adicionar ou remover qualquer campo que desejar, você precisa do código de validação e das convenções para compensar. Principalmente se você trabalhar com recursos externos.
Você sente falta de algum dos principais serviços extras que os RDBMSs fornecem?
Não. Mas minha formação é desenvolvedor de aplicativos web, lidamos com bancos de dados apenas na medida em que devemos :)
Uma empresa para a qual trabalhei fez um produto (um webapp) que foi projetado para rodar em bancos de dados SQL de vários fornecedores, e os "serviços extras" são tão diferentes de um banco de dados para outro que tiveram que ser implementados separadamente para cada banco de dados. Portanto, foi menos trabalhoso remover a funcionalidade do RDBMS. Isso se estendeu até mesmo à pesquisa de texto completo.
Então, seja o que for que estou desistindo, é algo que nunca realmente tive. Obviamente, sua experiência pode ser diferente.
Uma advertência: estou trabalhando agora em um webapp para dados financeiros, cotações de ações e outros. Esta é uma combinação muito boa para um banco de dados de documentos, do meu ponto de vista eu obtenho todos os benefícios de um banco de dados (persistência e consultas) sem nenhum incômodo.
Mas esses dados são bastante independentes uns dos outros, não há consultas relacionais complexas. Obtenha as últimas cotações por ticker, obtenha cotações por ticker e intervalo de datas, obtenha meta-informações da empresa, isso é praticamente tudo. Outro exemplo que vi foi um aplicativo de blog, e os blogs também não são caracterizados por esquemas de banco de dados extremamente complicados.
O que estou tentando dizer é que todas as aplicações bem-sucedidas de bancos de dados de documentos que conheço foram com dados que não tinham muitas inter-relações em primeiro lugar: documentos (como na pesquisa do Google), postagens de blog, artigos de notícias, dados financeiros .
Espero que existam conjuntos de dados que mapeiam melhor para SQL do que para o modelo de documento, então imagino que o SQL sobreviverá.
Mas para aqueles de nós que querem apenas uma maneira simples de armazenar e recuperar dados - e eu suspeito que existam muitos de nós - bancos de dados de documentos (como no CouchDB) são uma dádiva de Deus.