Должны ли ограничения базы данных соответствовать бизнес-логике

Question

База данных имеет уникальный индекс ограничений для поля ИМЯ пользователей.

Бизнес-служба проверяет через

service.GetUser(userName);

чтобы увидеть, существует ли имя пользователя. Из-за этой логики в сервисе никогда нельзя вставлять повторяющиеся имена. Я не перехватываю исключения для SqlException с номером = 2627, который предназначен для уникальных нарушений ограничений.

Так зачем мне накладывать уникальное ограничение на поле ИМЯ?

Answer 1

Вы должны разместить на уровне данных как можно больше бизнес-логики. Отношения, уникальность, длина, минимальная длина, ценностные ограничения, все, что вы можете.

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

Удачи.

Answer 2

Из-за этой логики в сервисе никогда нельзя вставлять повторяющиеся имена, поэтому ПОЧЕМУ я должен ввести в поле ИМЯ уникальное ограничение?

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

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

Answer 3

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

ИМО, лучше сохранить это уникальное поведение ограничения на уровне базы данных.