Мне было поручено проверить нашу базу данных. Это тестовая база данных, и мы можем сделать с ней все, что захотим, и легко откатить ее. Мне дали эту задачу, потому что мы все еще на этапе разработки (то есть, могут произойти любые изменения в любой момент времени проекта ... переименование столбца Person.FirstName в [First_Name] и затем переименование его в [ Имя]. Моя цель - дать приблизительную оценку того, к какой боли мы приближаемся, когда вносим изменения, чтобы мы могли планировать это заранее. Мы также можем ожидать такого рода изменения и во время производства.
Предметы, которые у меня есть в моем списке, и имеют письменные тесты для:
Отправьте слово null (не буквальное значение null, а "null"), потому что при использовании динамического SQL оно может перевернуться, думая, что вы действительно имеете в виду null. Мы выяснили это потому, что кто-то с фамилией «ноль» вызвал исключение.
Использование одинарных кавычек, поскольку в динамическом SQL нет вероятных одинарных кавычек. Опять же, кто-то с одним из них вызвал аварию.
Никогда раньше этого не делал, это все, что я знаю, что может привести к сбою. Есть еще идеи? Мы пытаемся эмулировать данные, которые пользователь может ввести.
edit 1: Наша проблема в том, что у нас есть экран поиска с примерно 25 полями, по которым они могут искать. Некоторые из этих полей поиска являются простыми (например, имя), некоторые являются менее простыми (категория 1 с датой меньше 2, но также имеет категорию 2 с датой больше 2 ИЛИ имеет категорию 4 в любой период времени). Экран поиска позволяет пользователю выбирать разных операторов и предикатов для каждого из этих 25 полей. Есть ли лучший способ справиться с этим, чем динамический SQL? Я нахожусь в положении и моменте, когда мы можем изменить что-то другое, если это будет лучше.
edit 2: Не знаю, стоит ли упоминать об этом, но мы используем LINQ для доступа к хранимым процедурам. Мои исследования показали, что динамический LINQ не будет делать то, что нам нужно, как динамический запрос SQL. Хотя может и ошибаться.