Разработка и таблицы базы данных T-SQL

Question

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

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

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

Для примера мы получили таблицу с различными рисками, и нам нужно было добавить столбец флага IsSomething (BIT NOT NULL ...). Он полностью соответствует наличию в таблице риска в соответствии с третьей нормальной формой, без транзитивной зависимости от ключа, не ключевого значения ...

НО, парень сказал, что он хочет хранить таблицы так, как они есть нам пришлось создать новую таблицу «riskinfo» и связать данные 1: 1 с новым столбцом.

Что вы думаете?

Answer 1

Мы добавляем столбцы в наши таблицы, на которые ссылаются различные приложения все время.

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

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

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

Answer 2

Этот вопрос действительно субъективен, как комментирует Binary Worrier. У меня нет ответа и никаких предложений. Просто поделитесь своими 2 центами.

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

Answer 3

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

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

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

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

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

Время от времени это не удовлетворит всех потребностей ИТ-руководителя. И если глава ИТ-отдела действительно говорит: «Я не понимаю базы данных, поэтому ничего не меняйте», тогда вы доходите до ручья, пока глава ИТ не изменится или не изменится.