Изменение таблицы SQL Server без последствий

Question

У меня есть таблица с 30 столбцами, которые уже широко используются в приложении. Т.е. операции выбора, вставки и обновления для этой таблицы написаны разными способами (какими бы удобными ни были разработчики) в количестве хранимых процедур и пользовательских функций. Теперь передо мной стоит задача расширить функциональность, для которой служит таблица, и мне нужно добавить дополнительную информацию в таблицу (обычно ее можно рассматривать как дополнительный столбец таблицы). Добавление дополнительного столбца в таблицу - это сложная и неэффективная задача, которую я не хочу выполнять, учитывая влияние, которое она окажет в других местах.

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

Использование SQL Server 2000 в случае необходимости.

Edit:

К сожалению, столбец не должен принимать значения NULL. Пропустил эту важную информацию действительно

Я думаю, что последствия, которые могут произойти из-за уже внедренных плохих практик,

1) «SELECT *» и привязка к некоторым DataGrid непосредственно к переднему концу. (очень очень низкая вероятность)

2) использование номеров столбцов для выборки из набор данных или данные вместо столбца имена в переднем конце при использовании «SELECT» * "

3) «Вставить в» со значениями последовательно вместо столбца имена.

Каким-то образом, если я смогу сделать так, чтобы столбец принимал значения "NULL" (немного изменяя требования), какое-либо влияние из-за вышеупомянутых пунктов?

Я сомневаюсь в анализе существующего кода, потому что количество SP и функций, использующих эту таблицу, может исчисляться сотнями.

Answer 1

Если добавление нового столбца в существующую таблицу недопустимо, добавьте новую таблицу в соотношении один к одному со старой таблицей. Он должен содержать поле первичного ключа, как в старой таблице, и новые столбцы. Это ключевое поле является первичным ключом также для новой таблицы (для обеспечения однозначного (нулевого или одного) количества элементов).

Недостатком является то, что:

• чтобы найти новые данные, вам нужно сделать соединение (собственно внешнее соединение).
• при вставке / обновлении / удалении записи, вы должны сделать это в два Таблицы

Answer 2

любой подход будет работать со следующими предостережениями:

• если у вас есть SELECT * ... где-то, ваши новые столбцы будут отображаться в наборе результатов, что может быть нежелательно, например,

  вставить в #tmpTable select * from sometable, где blah-blah-blah

вызовет ошибку, если в столбце temp не определены новые столбцы

• использование таблицы «расширения» менее эффективно, но менее эффективно, однако это единственный гарантированный способ не нарушать существующие хранимые процедуры, представления и т. Д.