Вот несколько довольно простых причин.
(1) Если запрос (вставка, обновление, удаление) нарушает ограничение, SQL генерирует сообщение об ошибке, которое будет содержать имя ограничения. Если имя ограничения ясное и информативное, сообщение об ошибке будет легче понять; если имя ограничения является случайным именем на основе guid, это намного менее ясно. В частности, для конечных пользователей, которые (хорошо, возможно) позвонят вам и спросят, что означает « FK__B__B_COL1__75435199
».
(2) Если ограничение необходимо изменить в будущем (да, это случается), это очень сложно сделать, если вы не знаете, как это называется. (ALTER TABLE MyTable drop CONSTRAINT ммм ...) И если вы создадите более одного экземпляра базы данных «с нуля» и используете имена по умолчанию, сгенерированные системой, никакие два имени никогда не будут совпадать.
Чтобы идентифицировать ограничение в будущем (например, вы хотите удалить его в будущем), оно должно иметь уникальное имя. Если вы не укажете для него имя, механизм базы данных, вероятно, назначит вам странное имя (например, содержащее случайные данные для обеспечения уникальности).
Это поддерживает администраторов баз данных, поэтому они разрешают определение вашей схемы в производственной базе данных.
Когда ваш код случайным образом нарушает какое-то ограничение внешнего ключа, это чертовски экономит время на отладку, чтобы выяснить, какое именно. Присвоение им имен значительно упрощает отладку вставок и обновлений.
Это помогает кому-то быстро узнать, что делают ограничения, без необходимости смотреть на фактическое ограничение, поскольку имя дает вам всю необходимую информацию.
Итак, я знаю, есть ли это первичный ключ, уникальный ключ или ключ по умолчанию, а также таблица и, возможно, задействованные столбцы.
Правильно назвав все ограничения, Вы можете быстро связать конкретное ограничение с нашей моделью данных. Это дает нам два реальных преимущества: