Design de esquema do MongoDB
Quando o MongoDB foi lançado há alguns anos, um dos recursos importantes divulgados era a capacidade de ser “sem esquema” – O que isso significa para seus documentos?
O design do esquema MongoDB não impõe nenhum esquema nos documentos armazenados em uma coleção. O MongoDB armazena essencialmente documentos JSON e cada documento pode conter qualquer estrutura que você desejar. Considere alguns exemplos de nossa coleção de “contatos” abaixo. Aqui está um documento que você pode armazenar:
{
'name':'user1',
'address':' 1 mountain view',
'phone': '123-324-3308',
'SSN':'123-45-7891'
}
Agora o segundo documento armazenado na coleção pode ser deste formato:
{
'name': ' user2',
'employeeid': 546789
}
É muito legal que você possa armazenar esses dois documentos na mesma coleção. O problema, no entanto, começa quando você precisa recuperar esses documentos da coleção. Como você sabe se o documento recuperado contém o formato 1 ou o formato 2? Você pode verificar se o documento recuperado contém o campo 'ssn' e tomar uma decisão. Outra opção é armazenar o tipo do documento no próprio documento:
{
'type': xxx,
'name': ....
...
}
Em ambos os casos, o que você conseguiu foi mover a imposição do esquema do banco de dados para o aplicativo -
Há sempre um esquema, é apenas uma questão de onde ele é implementado.
Se você tiver os índices corretos, isso alivia o problema até certo ponto. Se a maioria de suas consultas for por ‘employeeid’, você sabe que o documento recuperado é sempre do segundo formato – porém, o restante do seu código que não usa esse índice ainda terá o problema mencionado acima. Além disso, se você estiver usando um ODM como o mongoose, ele automaticamente já aplica um esquema para você no MongoDB.
Existem vários aplicativos que se beneficiam dessa flexibilidade. Um cenário que vem à mente é o caso de um esquema onde há vários campos/colunas opcionais. No MongoDB, não há penalidade por ter algumas colunas ausentes. Cada documento pode conter apenas os campos necessários.
Validação do documento
A partir da versão 3.2.x, o MongoDB agora suporta o conceito de validação de esquema usando a construção “validator”. Isso fornece muitos níveis de validação – para que você possa escolher o nível que funciona para você. O comportamento padrão se você não usar o validador é o comportamento anterior sem esquema. Normalmente você criará os “validadores” no momento da criação da coleção
db.createCollection( "contacts",
{ validator: { $or:
[
{ employeeid: { $exists: true }},
{ SSN: { $exists: true } }
]
}
} )
Crie validações de esquema no MongoDB para que você possa escolher o nível necessárioClique para Tweet Coleções existentes
As coleções existentes podem ser atualizadas usando o comando ‘collMod’:
db.runCommand( {
collMod: "contacts”,
validator: { $or: [ { employeeid: { $exists: true }}, { SSN: { $exists:true} } ] }
} )
Nível de validação
O MongoDB suporta o conceito de ‘ValidationLevel’. O nível de validação padrão é 'estrito', o que significa que inserções e atualizações falham se o documento não atender aos critérios de validação. Se o nível de validação for ‘Moderado’, ele aplica a validação aos documentos existentes que atendem aos critérios de validação. Os documentos que existem atualmente e não atendem aos critérios não são validados. Embora conveniente, o nível de validação 'Moderado' pode causar problemas no futuro - por isso, ele precisa ser usado com cuidado.
Ação de validação
Por padrão, a ação de validação é 'Erro'. Se o seu documento falhar na validação, é um erro e a atualização/inserção falha. No entanto, você também pode definir a ação de validação para 'avisar' que basicamente registra a violação de esquema no log , mas não falha na inserção.
Quais exemplos de design de esquema ajudariam você em seu próximo projeto, informe-nos!
