Должна ли основная конфигурация приложения храниться в базе данных, и если да, что нужно сделать для их защиты?

Question

Я пишу приложение вокруг большого количества иерархических данных. В настоящее время иерархия фиксирована, но, вероятно, в будущем новые элементы будут добавлены в иерархию. (пожалуйста, пусть они будут листьями)

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

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

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

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

Answer 1

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

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

Обслуживание : Подумайте о сценарии использования для изменения вашей иерархии. Какое внешнее событие вызовет необходимость поддерживать иерархию, и кто будет человеком, обеспечивающим это? Нужно ли сохранять эти изменения, проверять, проверять их версии, утверждать, ставить и т. Д.? Системы контроля версий предоставляют множество этих функций.

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

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