Иностранные ключи злые?
Извините за публикацию под вымышленным именем, но я должен держать это анонимным из-за корпоративных ограничений и вообще, чтобы защитить невинных.
Я являюсь профессиональным разработчиком около 18 лет, и хотя я не являюсь администратором баз данных, я тесно сотрудничал с ними на протяжении многих лет и сформировал, как мне кажется, довольно приличное чувство того, что является, а что нет, хорошей практикой работы с базами данных. Я только что присоединился к компании, в которой два разработчика отвечают за схему базы данных, и обнаружил, что они очень против использования ограничений внешнего ключа.
Насколько я могу судить, их аргументация заключается в том, что (1) это затрудняет модульное тестирование хранимых процедур из-за дополнительной настройки данных, и (2) внешние ключи могут вызывать ошибки, так как порядок важен. Они на самом деле предпочли бы потерянные данные, а не прекращение приложения.
Это кажется плохой практикой для меня, но они непоколебимы в своем положении. Мы выявили преимущества, которые предоставляют внешние ключи с точки зрения целостности данных, производительности запросов, создания диаграмм баз данных и т. Д., Но безрезультатно.
Я что-то здесь не вижу? Любой совет?
2 ответа
Я думаю, что они ошибочны или наивны, если вы описали общий подход разработчиков к внешним ключам. Конечно, вполне возможно, что есть веские причины, по которым ограничение внешнего ключа не может или не должно применяться к некоторым конкретным атрибутам в любой конкретной системе. Может быть, это реальная причина очевидной риторики.
Мой совет. Если вы являетесь заинтересованным лицом в рассматриваемой системе, не разговаривайте с разработчиками, не общайтесь с менеджером по разработке или с кем-либо, кто владеет системой. Подкрепите свое дело конкретными примерами того, как отсутствие ссылочной целостности оказывает неблагоприятное воздействие или создает будущие риски.
Если у вас нет текущей проблемы, связанной с РИ, то, вероятно, ваша главная задача - улучшить политику или подход к разработке для будущей работы. Поговорите с менеджерами баз данных, администраторами баз данных или теми, кто отвечает за стандарты и информационные риски. Подумайте о том, чтобы инвестировать средства в обучение, наставничество или консультирование в интересах команды разработчиков.
Я проектирую системы баз данных уже более 30 лет. Вот мое мнение - вам, вероятно, это не понравится. При разработке закрытых систем ваша ссылочная целостность, вероятно, будет встроена в пользовательский интерфейс приложения. Вы можете добавить запись объекта Product только в том случае, если требуется цвет - обеспечивается пользовательским интерфейсом. Так зачем иметь внешний ключ? Я не работаю с открытыми базами данных, где каждый может сделать что-либо, поэтому ваш типичный бэкэнд будет иметь тысячи строк кода переднего плана, защищающих целостность данных. Привязанные к внешним ключам ключи только мешают и не предоставляют вам никакого реального обслуживания. Не похоже, что внешний ключ будет генерировать исключение, а затем вы поймаете это исключение и отправите сообщение пользователю. Никто, и я имею в виду, никто не кодирует таким образом. Все мы, программисты, любим спешить и помещать все эти интересные вещи прямо в пользовательский интерфейс. Но, как я уже сказал, я работаю с закрытыми системами, в которых работает разработчик. Индексы, с другой стороны - ЧРЕЗВЫЧАЙНО ВАЖНЫ. Разберись с этим первым. Внешние ключи - просто синтаксический пух.