Как обрабатывать старые данные с миграцией базы данных? - PullRequest
Новая
       24

Как обрабатывать старые данные с миграцией базы данных?

0 голосов
/ 21 октября 2019

Я прыгаю в проект, который запущен в течение некоторого времени. Одна из моих первых задач - добавить несколько столбцов, которые по существу заменят существующий столбец. Что мне делать со старыми данными?

Новые столбцы предназначены для «разложения» существующего столбца, чтобы добавить более детальные детали к значению. Следующая структура концептуально совпадает с той, с которой я имею дело: 

# Current Schema
TotalPrice: BigInt

# New Schema
BasePrice: BigInt
Markup: BigInt
Tax: BigInt

Концептуально говоря, TotalPrice == (BasePrice + Markup + Tax).

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

Сохранить TotalPrice

Удерживайте старые данные как есть, сделайте столбец доступным только для чтения через ORM (я использую Django) и внесите в код условные выражения для проверки значения в этом «наследии»колонка первая. На уровне кода это кажется более сложным, но сохраняет данные в изначально предназначенной для них ментальной модели, что упрощает анализ и работу в будущем.

Перемещение TotalPrice в один из новых столбцов

Удерживайте данные, но, так сказать, перемаркируйте их. Это сделает код чище, но настроит нас на потенциально странные ситуации, когда только один из новых столбцов будет иметь значение для большого количества записей, в то время как ожидаемая ситуация состоит в том, что все 3 новых столбца будут иметь значение> 0.

Мне кажется, что первый подход лучше в долгосрочной перспективе. Это более явно (записи с TotalPrice представляют информацию, когда она была создана), и требует меньше комментариев, чтобы объяснить «что здесь происходит», когда имеет дело со столбцами, которые имеют подразумеваемое второе значение (например, BasePrice является основойцена, но иногда TotalPrice для старых записей). Но я не совсем уверен, стоит ли удерживать этот столбец и связанные с ним потоки кода более простой мысленной моделью.

Представьте себе большой код, который выглядит следующим образом: 

if obj.total_price:
    return obj.total_price
else:
    return obj.base_price + obj.markup + obj.tax

Где мыВсегда нужно будет вводить утку, чтобы понять, является ли она «устаревшей» записью.

«Это не имеет значения» также является приемлемым ответом!

...