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

Question

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

Проблема: Когда создается новая версия, в ТАБЛИЦАХ базы данных происходят изменения, добавляется несколько столбцов, а некоторые изменяются. В этом случае, если база данных одинакова для сервисов, это повлияет на старые сервисы. Каков наилучший способ справиться с этим? Можем ли мы иметь таблицы базы данных с версиями?

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

Answer 1

Прежде всего, это очень хороший вопрос, и дизайн сложен.

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

Можем ли мы иметь таблицы базы данных с версиями?

По-моему, вы можете иметь все, что хотите, но это не рекомендуется из-за сложностей, которые он вносит в систему. Это то, что делается в ответе выше.

Как лучше всего справиться с этим?

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

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

затем скажем, что есть новая версия API, которая требует изменения БД, которая сломает существующую систему / старую версию. Это нехорошо, попробуйте переработать ваше решение для достижения той же функциональности таким образом, чтобы оно не сломать вашу существующую версию. Если это невозможно (очевидно, что все возможно !!), это случай слияния и обновления основного продукта, и его необходимо отложить до удаления старой версии.

По этой самой причине, в самой первой попытке, нам нужно спроектировать таблицы БД и сущности JPA как можно более полными и максимально широкими, чтобы DTO и сущности были различны, поэтому изменения в основном необходимы на стороне DTO, а не на сущности боковая сторона.

Очевидно, что это субъективные мнения, они будут варьироваться от случая к случаю и открыты для обсуждения.

Answer 2

Вы никогда не должны быть в этой ситуации. Если столбцы добавлены, у вас может быть DTO, который не отправляет эти новые добавленные столбцы более старым версиям. Если вам нужно удалить, то не удаляйте, прекратите использовать его для новых API, и если вам нужно изменить, создайте новый столбец и откажитесь, и пусть новые API взаимодействуют с новыми.

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

Существует так много вопросов, на которые нужно будет ответить, кроме того, как нужно обслуживать API и как службы будут управлять изменениями.

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

Я чувствую, что это скорее деловое решение, чем техническое.

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