Это блестящий вопрос - и, на мой взгляд, одно из преимуществ использования объектно-реляционного картографа.
Как правило, реляционные инструменты, предоставляемые вашей базой данных, предназначены для защиты достоверности данных - у «клиента» должны быть отношения «менеджер аккаунта», «имя_пользователя» не может быть нулевым, «идентификатор_пользователя» должно быть уникальным и т. Д.
Эти инструменты необходимы, но не достаточны для проверки данных, вводимых пользователями в базу данных.
Ваш код переднего / среднего уровня имеет свои собственные правила, которые обычно не выражаются в реляционных терминах;в большинстве современных языков разработки речь идет об объектах и отношениях между объектами или их атрибутами - например, номер телефона должен содержать цифры, а имя должно начинаться с заглавной буквы.
Я предполагаю, что ваши пользователи не взаимодействуют с базой данных через SQL - вы создали какой-то пользовательский интерфейс, который позволяет им искать ассоциации (и, таким образом, заполнять внешний ключ).
В этом случае моя предпочтительная архитектура:
- Проверяйте как можно раньше - в JavaScript для веб-приложений или в коде GUI для настольных приложений.Это уменьшает количество циклов и, таким образом, создает более отзывчивый пользовательский опыт.
- Пусть каждый уровень реализует проверку для своей логики домена ключа - ваши классы должны проверить свои ожидания, ваша база данных должна проверить внешние ключи и обнуляемость.
- Не полагайтесь на "более высокие" уровни дляподтвердить - вы не можете предсказать, как ваш код будет использоваться в будущем;класс, который вы написали для одного приложения, может быть повторно использован другим.
- Разработайте способ синхронизации правил валидации между уровнями - с помощью технологии или процесса.