#.net #sql #sql-server
#.net #sql #sql-server
Вопрос:
Пример, который я использую, заключается в том, что я пытаюсь обновить запись в базе данных, и я получаю нарушение ограничения уникального значения. Текст сообщения содержит имя ограничения и значение, которое дублируется. В принципе, я мог бы проанализировать текст сообщения, чтобы извлечь эту информацию. Но я ненавижу это делать, потому что подобная обработка текста имеет тенденцию добавлять двусмысленности. Например, значение заключено в круглые скобки. Но если я ищу в тексте круглые скобки, что, если круглые скобки встречаются где-то еще в сообщении, например, кто-то создал имя ограничения с круглыми скобками в нем или что-то подобное? Что, если в будущих версиях движка DB изменится формулировка или формат сообщения? И т.д. Итак, доступна ли эта информация в четко определенных полях?
(В частности, я использую VB.Net но я полагаю, что любой ответ будет применим к .Сеть в целом.)
Ответ №1:
Обработка текстовых данных исключения — единственный способ сделать это в настоящее время. Детализированная информация не возвращается в исключении.
Хотя было бы неплохо вернуть эту информацию, обычно с этим мало что можно сделать из кода. Такие проблемы, как простые нарушения внешнего ключа, должны учитываться в бизнес-логике для начала, поэтому подобные вещи должны быть исключительными случаями, когда вы должны предоставить пользователю какой-либо способ доставить как можно больше сообщений об ошибках команде разработчиков.
Комментарии:
1. Это единственный способ сделать это, и это плохой способ сделать это, поэтому ответ заключается в том, чтобы не делать этого.
2. RE: невозможно сделать: облом, но спасибо за информацию. Что касается того, почему я хочу знать: 1. Предоставьте пользователю более красивое сообщение об ошибке, например, «Номер социального страхования, который вы пытаетесь ввести, уже назначен другому сотруднику», а не «Ошибка TSQL 2967 нарушение уникального ограничения при ограничении UQ__2390320923093» или как бы там ни было, этот текст идет. 2. В зависимости от бизнес-логики бывают случаи, когда вы могли бы что-то с этим сделать, например, заменить поле-нарушитель на значение по умолчанию, возможно.
3. @Jay: Я слышу, что вы говорите, и это «приятно иметь», но на самом деле в этом нет очевидной ценности. Перечисленные вами примеры легко учитываются в бизнес-логике. Как правило, плохая идея полагаться на базу данных для проверки вашего пользовательского ввода, поскольку ограничения базы данных являются последней остановкой, которая обеспечивает целостность ваших данных. Если в базу данных попадают неверные данные, программное обеспечение уже неисправно, и в этот момент вам нужно начать предоставлять пользователю информацию, которую он должен будет предоставить вам, когда обратится в службу поддержки.
4. Не для того, чтобы вступать в дискуссию по этому вопросу, но: да, в большинстве случаев я мог бы написать бизнес-логику для выполнения такой проверки. Но это означало бы повторение ограничения в коде приложения, что нарушает DRY. Кроме того, в случае, вызвавшем этот вопрос, я пытаюсь написать некоторый общий код, который можно использовать не только для нескольких таблиц, но и для нескольких проектов, т. Е. Я хочу взять эту же функцию и просто перенести ее в другой проект, и она работает без необходимости настраивать ее с учетом ограничений для этогоконкретная база данных и таблица.
5. @Jay: Такие ограничения почти всегда повторяются в коде приложения. Это не нарушение DRY, потому что они разные: один (база данных) предназначен для обеспечения абсолютной уверенности в том, что данные в вашей базе данных на 100% согласованы, независимо от пользовательского интерфейса, необходимого для этого. Другая (ваша бизнес-логика) предназначена для обеспечения отправки правильных данных в базу данных и предоставления пользователю подходящего способа предотвращения или исправления ошибок ввода. Я понимаю, что вы говорите, но люди все время спрашивали, так это или нет…