Должны ли хранимые процедуры проверять потенциальные проблемы при выполнении?

Question

Позвольте мне немного объяснить этот вопрос:)

Я пишу кучу хранимых процедур для нового продукта. Они будут вызываться только приложением c #, написанным разработчиками, которые следуют той же технической спецификации, что и мне. Я не могу вдаваться в реальные технические характеристики, поэтому приведу достаточно близкий пример:

В технической спецификации нам нужно хранить данные файла в паре проприетарных zip-файлов, с базой данных, хранящей имена и местоположения каждого файла в zip-файле (например, одна база данных для каждого zip-файла)

Теперь предположим, что эта техническая спецификация гласит, что для выполнения «Операции А» необходимо выполнить следующие шаги:

1: Рассчитать требования к пространству для добавляемого файла

2: Получить список zip-файлов и их строк подключения к базе данных (вызвать хранимую процедуру "GetZips")

2: Найти подходящее место в zip-файле для хранения файла (вызывать хранимую процедуру «GetSuitableFileLocation» для каждого соединения с базой данных, пока не будет найдено подходящее)

3: На шаге 2 вам будет предоставлена ​​начальная / конечная точка внутри почтового индекса для добавления вашего файла. Вызовите хранимый процесс «AllocateLocationToFile», передав эти значения, затем добавьте свой файл в zip-архив.

ОК - вопрос в том, должен ли «AllocateLocationToFile» перепроверить указанные начальные / конечные точки по-прежнему «свободными», а если нет, вызвать исключение?

В офисе шла небольшая дискуссия по этому поводу, и хотя я считаю, что это следует проверить и поднять, другие считают, что это не следует, поскольку нет необходимости в том, что разработчик немедленно вызывает метод "GetSuitableFileLocation".

Могу ли я попросить несколько ценных мнений?

Answer 1

Как правило, лучше быть максимально безопасным.Вызывающий код никогда не должен полагаться на внешний код (sp являются своего рода внешними).Идея в том, что вы не можете предсказать, что произойдет в будущем.Новые ребята приходят в компанию ... sps передаются другой команде и так далее ...

Лично тот факт, что B () сразу после A () ничего не гарантирует.Изменить это по какой-либо причине не является чем-то, что нельзя считать невозможным.

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

Мое предложение состоит в том, чтобы сделать проверку, профилировать код и, если это действительно узкое место, удалить его, но напишите где-нибудь, что ЭТО МОЖЕТ ПРЕРЫВАТЬ!.

Answer 2

Учитывая, что вы манипулируете файлами, со всеми возможными последствиями, которые это может создать, я бы сказал, что в этом сценарии риск (компонент ущерба) достаточно высок, чтобы быть осторожным.

И Светлозар прав:Что, если большой успех вызывает повторное использование или другие дополнительные приложения?Не каждый может вести себя так же хорошо, как ваша команда сейчас.

Answer 3

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