Документно-ориентированная база данных - что, если определения документа изменятся? - PullRequest
Новая
       21

Документно-ориентированная база данных - что, если определения документа изменятся?

5 голосов
/ 17 мая 2010

Насколько я понимаю, вы можете вводить любую неструктурированную информацию в документно-ориентированную базу данных. Давайте представим документ, подобный этому: 

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

Позже, в новой версии, эта структура была изменена на 

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

Как это сделать с документно-ориентированными базами данных? Вам нужно подготовить сценарии слияния, которые изменят все ваши записи в базе данных? Или есть более эффективные способы обработки изменений в структуре?

1 Ответ

3 голосов
/ 17 мая 2010

Рефакторинг здесь подразумевает наличие детерминированного отображения из старой схемы в новую схему. Поэтому наиболее эффективный вариант - сделать то же самое, что вы сделали бы с базой данных SQL, и фактически обновить документы.

Документно-ориентированные базы данных предоставляют вам еще одну опцию, хотя это зависит от того, какой DODB и как вы используете его во внешнем интерфейсе. Этот вариант заключается в том, чтобы просто оставить данные в покое и поддерживать «старое» определение в вашем приложении как вариант обратной совместимости. Другими словами, вы выполняете эти переводы на лету, а не постоянное одноразовое обновление.

На самом деле это не вариант с базой данных SQL, потому что вам придется хранить устаревший столбец и, возможно, индексировать его. С DODB вы на самом деле не тратите ни данные, ни пространство индекса. Вы должны взвесить преимущества против недостатков.

Основным недостатком, очевидно, является несогласованность, которая может со временем расти и приводить к ошибкам. Другим недостатком, возможно, являются вычислительные затраты на выполнение этого на лету или невозможность эффективно использовать новую структуру (например, вы можете захотеть индексировать только на lastname). Поэтому, в большинстве случаев, я думаю, я бы просто выбрал массовое обновление.

Однако есть одно явное преимущество при сохранении старых документов; если вы не уверены, что ваш рефакторинг идеален - например, если данные в вашем столбце name не соответствуют согласованному соглашению, возможно, в некоторых случаях это lastname, firstname, а в других - firstname lastname и в в других случаях это company name - тогда выполнение ваших преобразований на лету без постоянного обновления позволяет вам уточнить сопоставление с течением времени, поэтому вы можете использовать поля firstname и lastname, когда они доступны, но отступать к name игра в угадайку для устаревших данных.

Как уже говорилось, я бы, вероятно, зарезервировал второй вариант для исключительных случаев, когда я не уверен, что смогу добиться правильного "рефакторинга" для каждой записи / документа. Тем не менее вам доступна опция, которой у вас нет в других типах баз данных.

Кроме этих двух, я не вижу других четких альтернатив. Это своего рода двоичное решение; либо вы постоянно обновляете существующие данные, либо нет.

...