Реляционные базы данных и итеративная разработка

Во многих подходах к разработке программного обеспечения, таких как гибкие методологии, доменно-ориентированное проектирование и объектно-ориентированный анализ и проектирование, нам предлагается использовать один итеративный подход к разработке.

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

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

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

Обновление кода может быть сложной задачей, если код не разработан должным образом и если система большая. Но это можно сделать со временем, у нас есть такие инструменты, как Git, которые помогают нам делать это, не повреждая готовую версию.

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

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

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

Этот подход, кажется, не самый лучший. Мой вопрос здесь: есть ли известные и рекомендуемые подходы для согласования итеративной разработки с реляционными базами данных?

Это не обязательно должны быть специальные классы, но да, вам нужно что-то, что возьмет базу данных в предыдущем формате и преобразует ее в текущий.

Дело в том, что вам необходимо разработать процесс написания и тестирования этих сценариев и дисциплины, чтобы никогда не касаться тестовых и производственных баз данных вручную, но всегда с помощью сценариев миграции.

Каждый раз, когда вам нужно внести изменения в базу данных, вы пишете скрипт, который будет это делать, будь то в SQL или с использованием вашего уровня ORM, и фиксируете его в вашем контроле версий вместе с изменениями, которые требуют новой схемы. Затем у вас есть некоторый управляющий сценарий, который обновит базу данных, применив все сценарии миграции, которые еще не были применены в последовательности.

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

Новая установка выполняется просто путем применения всех сценариев. Через некоторое время у вас может появиться несколько сотен из них, и вы подумаете, что это очень неэффективно, но не попадайтесь в ловушку попыток оптимизировать его. Установка является единовременным занятием, а надежные козыри делают его быстрым.

@Doc Браун уже связал Мартина Фаулера: эволюционный дизайн баз данных и /programming/334059/agile-development-and-database-changes , и я бы добавил Алекса Пападимулиса: изменения в базе данных сделаны правильно , что короче и есть несколько примеров.

В качестве достойного примера инструмента, реализующего такой процесс, я предлагаю Alembic . Он основан на платформе SQLAlchemy Python , но вы можете использовать его с другими языками и средами, если у них нет собственной поддержки миграции. На странице Википедии о переносе схем перечислены другие инструменты .

Как ни странно, это та самая проблема, с которой сталкивается моя нынешняя команда разработчиков. Вопрос содержит несколько подвопросов, поэтому они будут рассмотрены независимо.

Прежде всего, не слишком ли сильно ограничивает реляционную базу данных модель данных, делая изменения очень трудными?

Скорее всего , но не обязательно по указанным причинам. К сожалению, универсальность систем управления реляционными базами данных также приводит к их падению. СУБД изначально была разработана для того, чтобы предложить относительно простую платформу хранения данных, которая будет принимать большие наборы данных и уменьшать их до относительно небольшого размера. Это было сделано за счет сложности модели данных и требуемой вычислительной мощности. С ростом сложности базы данных появились хранимые процедуры, представления, функции и триггеры, чтобы помочь администраторам базы данных справляться со сложностью согласованным и масштабируемым образом.

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

Это приводит ко второй части вопроса, которая на самом деле была скорее предположением, но должна рассматриваться как вопрос: должны ли мы сделать нашу модель предметной области правильно с первого раза?

Да, в некоторой степени. Как указывал вопрос, редко можно полностью понять проблему, когда мы начинаем процесс проектирования. Тем не менее, разница между совершенно неверной моделью данных, в отличие от модели, которая может быть изменена при более глубоком понимании предметной области, заключается в модели, которая последовательно сопоставляется с реальным миром. Это означает, что мы должны приложить все усилия для создания исходной модели данных, которая согласуется с нашим пониманием проблемы с точки зрения ее реальных сущностей. Если мы начнем нормализовывать неправильные объекты, модель данных будет неправильной в двух отношениях, и восстановление будет затруднено.

Во многих отношениях переход к решениям для баз данных «без SQL» является результатом проблем несогласованности моделей данных. Использование объектно-ориентированного подхода No SQL заставляет нас больше думать о сопоставлении между нашими объектами в коде и объектами в реальном мире, и когда мы сталкиваемся с несогласованностью, это часто самоочевидно, потому что это невозможно реализовать в нашем база данных. Это приводит к улучшению общего дизайна.

Это приводит к последнему вопросу: не противоречит ли реляционная модель данных гибкому подходу?

Нет, но требуется больше навыков. В то время как в мире No-SQL добавление поля или преобразование свойства в массив тривиально, это вовсе не тривиально в реляционном мире. Требуется как минимум тот, кто способен понимать как реляционную модель данных, так и сущности реального мира, которые они представляют. Этот человек является человеком, который будет способствовать обновлению реляционной модели по мере изменения понимания модели реального мира. Для решения этой проблемы нет серебряной пули.

Суть не в том, чтобы реорганизовать столько, чтобы ваша модель изменилась до неузнаваемости. Даже с итеративной разработкой вы должны действительно опираться на существующие вещи, а не реорганизовывать их в клочья.

Это дает вам 2 основных варианта для обработки больших изменений, когда они приходят: во-первых, построить слой БД в виде API, использовать хранимые процедуры, чтобы их можно было изменять в соответствии с требованиями клиента без изменения базовой схемы данных.

Другой способ - заменить таблицы небольшим переносом данных. Когда требуется крупномасштабное изменение, вы создаете новую схему и реализуете набор сценариев, чтобы взять старые данные и преобразовать их в новый формат. Это требует времени, поэтому вы больше полагаетесь на более дешевые методы изменения доступа к данным (например, через SP) в качестве первого выбора.

Итак: 1. попробуйте подумать о дизайне, чтобы вам не пришлось ничего менять.

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

3. Потратьте время, чтобы обновить должным образом, если вам нужно.

Эти шаги применимы ко всему, а не только к базам данных.