Banco de dados orientado a documentos - e se as definições de documentos mudarem?

Question

Pelo que entendi, você pode inserir qualquer informação não estruturada em um banco de dados orientado a documentos. Vamos imaginar um documento como este:

{
  name: 'John Blank',
  yearOfBirth: 1960
}

Mais tarde, em uma nova versão, essa estrutura é refatória para

{
  firstname: 'John',
  lastname: 'Blank',
  yearOfBirth: 1960
}

Como você faz isso com bancos de dados orientados a documentos? Você precisa preparar scripts de mesclagem, que alteram todas as suas entradas no banco de dados? Ou existem maneiras melhores de lidar com mudanças na estrutura?

Answer 1

A refatoração aqui implica que há um mapeamento determinístico do esquema antigo para o novo esquema. Portanto, a opção mais eficaz é fazer a mesma coisa que você faria com um banco de dados SQL e realmente atualizar os documentos.

Os bancos de dados orientados a documentos oferecem uma outra opção, embora dependa de qual DodB e como você o está usando no front-end. Essa opção é simplesmente deixar os dados em paz e suportar a definição "antiga" em seu aplicativo como uma espécie de opção de compatibilidade com versões anteriores. Em outras palavras, você está fazendo essas traduções on-the-fly, em oposição a uma atualização única permanente.

Esta não é realmente uma opção com um banco de dados SQL, porque você precisaria manter a coluna obsoleta e possivelmente indexada. Com um dodb, você não está realmente desperdiçando nenhum dado ou espaço de índice. Você teria que pesar as vantagens contra as desvantagens.

A desvantagem principal é, obviamente, a inconsistência, que pode crescer com o tempo e levar a bugs. Outra desvantagem é possivelmente a despesa computacional de fazer isso on-the-fly, ou a incapacidade de usar efetivamente a nova estrutura (por exemplo, você pode indexar apenas no lastname). Então, na maioria das vezes, acho que optaria por executar uma atualização em massa.

Há uma clara vantagem em preservar os documentos antigos; Se você não tem certeza de que sua refatoração é perfeita - por exemplo, se os dados em seu name A coluna não seguiu uma convenção consistente, talvez em alguns casos seja lastname, firstname E em outros casos é firstname lastname E em outros casos é company name -Em seguida, fazer suas conversões on-the-fly sem fazer uma atualização permanente permite refinar o mapeamento ao longo do tempo, para que você possa usar o firstname e lastname campos quando disponível, mas volta ao name Adivinhando o jogo para dados legados.

Como afirmado, provavelmente reservaria a segunda opção para casos excepcionais, onde não estou confiante de que poderei obter a "refatoração" correta para cada registro/documento. No entanto, é uma opção disponível para você que você realmente não tem com outros tipos de bancos de dados.

Além desses dois, não vejo outras alternativas claras. É uma espécie de decisão binária; Ou você atualiza permanentemente os dados existentes ou não.