Какова наилучшая практика для обработки предустановленных системных объектов в разработке приложений?

Question

Мне сложно на самом деле назвать проблему, но я сделаю все возможное, чтобы описать ее: В приложении для управления базами данных для предприятия есть объекты (строки в базе данных), которые всегда есть. Приложение не может жить без них при запуске, поскольку они являются частью исправления для бизнеса, для которого создано приложение.

Примеры:

• Если приложение является управление контактами контакт, что приложение выполняется (так «наш клиент» сам/сама) уже имеющийся Контакт в приложении.
• Если это приложение, которое создает счета-фактуры для определенного типа бизнеса, должно быть несколько записей типа entitiy, которые уже доступны с определенными свойствами.
• В мобильном телефоне уже есть некоторые предустановленные профили

Эти объекты известны программисту и пользователю. Программист должен иметь доступ к ним (загрузить специальный известный контакт с клиентом или загрузить профиль по умолчанию). Теперь я задаю следующие вопросы:

1. Есть ли общее название для таких объектов/такого типа установки или рисунка? Я могу представить, что это похоже на «тестовые светильники», но я говорю только о производственной среде, а не тестировании.
2. Как обращаться к этим объектам? Где я их храню? Как загрузить их?
3. Как они всегда должны присутствовать, как я могу сообщить системе, что они являются readonly и не должны быть удалены?

Answer 1

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

Этот вид данных, называемый Env-специфичной схемой и контентом (по крайней мере, они называются здесь, где я работаю), и он обычно развертывается в базе данных с помощью какого-либо средства развертывания/автоматизации (проприетарный/CD/ansible/docker/вы его называете - и если вы уже развертываете схему в базе данных, было бы лучше, если бы добавление в нее контента было бы связано с тем же механизмом).

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

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

Так что мой ответ:

1. Это называется базы данных по умолчанию Content (Env-специфические, или нет)
2. Хранить в хранилище кода, usess их (как SQL файлы или JSONs в зависимости от вашего тип базы данных). И загрузите инструмент CD/Ansible/Docker/собственный скрипт/(есть так много инструментов, которые хороши в такой ситуации).

3. Несколько возможных стратегий -

   базы данных/ОРМ/разъем связан: добавление своего рода type собственности для моделирования схемы, а затем регулировать поведение на штекере/уровень ОРМ - модификация любого запроса, брошенной к базе данных после удаления, добавление WHERE type NOT IN ('default')

   programatic - то же самое, но фильтрация/отказ делается на уровне программы, в пределах уровня API.