Изменение таблицы SQL Server без влияния

either approach will work, with the following caveats:

• if you have a SELECT * ... somewhere, your new columns will show up in the result-set, which may be undesirable, e.g.

  insert into #tmpTable select * from sometable where blah-blah-blah

will cause an error unless the new colums are defined in the temp table

• using an 'extension' table is lower impact but less efficient, however, it is the only method guaranteed not to disturb existing stored procedures, views, et al

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

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

Ask yourself why adding a column would have a massive impact. Perhaps you have queries that use SELECT *? Find out why the impact would be significant - then consider those to be bugs, and fix them.

Most of the time, adding a column should not break anything. Adding a NOT NULL column will affect anything that does an INSERT, but otherwise, there should be little impact if your database is properly designed.

EDIT after NOT NULL update

The solution is obvious: add the column as NULL, update the data to include non NULL values for every row, then alter the column to be NOT NULL.

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

Возможные проблемы с точки зрения существующего кода заключаются в том, что разработчики могли выполнить команду SELECT * FROM TABLE, которая может испортить этот код, если будет добавлено больше . Тем не менее, это довольно распространенная передовая практика: никогда не выполнять SELECT *.

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

Однако, на мой взгляд, Я бы, вероятно, просто изменил существующую таблицу и решал любые проблемы, с которыми вы столкнетесь. Это, конечно, зависит от реальной "стоимости" ошибки: умрут ли люди?

Мне нравится идея создания новой таблицы. Я считаю, что это самый безопасный способ сделать это. Но если новый столбец, который вы хотите добавить, может допускать значения NULL, у вас не должно возникнуть проблем. Просто убедитесь, что в столбце разрешены нули.

Если он не может разрешить пустые значения, установите в столбце разрешение пустых значений, вставьте нужные значения в столбцы для существующих данных, а затем обязательно установите столбец, разрешающий нули.

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

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

РЕДАКТИРОВАТЬ: Я бы не стал пытаться сохранить отношение один к одному в этой таблице расширений. Я бы ввел строку в таблицу расширений, только если это необходимо, и оставил соединение в представлении. Таким образом, вам не придется беспокоиться о триггерах или тоннах проверки данных, убедившись, что таблицы синхронизированы.

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

Иногда мы не можем исправить все, и единственное решение - просто наложить пластырь.

Если вы используете alter table и добавьте значение по умолчанию, чтобы все записи получили значение, тогда оно не должно быть слишком плохим, если у вас нет миллионов записей. Не делайте этого с помощью Enterprise Manager (вы никогда не должны изменять таблицы с помощью Enterprise Manager, поскольку он полностью воссоздает таблицу, которую не поддерживает Alter table). Если у вас слишком много записей для автоматического заполнения глухих, сначала вам нужно изменить таблицу, чтобы добавить столбец с нулевыми значениями, затем обновить столбец до правильных значений (если у вас много записей, вы можете сделать это в баках, а не блокировать всю таблицу) на основе какие бы правила вы ни применяли для определения правильного значения для существующих записей. Затем измените таблицу, чтобы столбец не допускал значения NULL, если вы знаете, что нет записей без значения. В это время вы можете рассмотреть значение по умолчанию для любых новых записей, у которых нет значения.

Будет ли добавление столбца влиять на существующий код. Если разработчики не использовали select * (который никогда не должен использоваться в производственном коде), это не окажет большого влияния, за исключением того, что вы должны добавить новый столбец для определенной цели, и любой код, связанный с этой целью, должен будет быть обновленным, чтобы включить новый столбец. Поскольку это столбец, не допускающий значения NULL, необходимо будет изменить как минимум ваш код для вставки записей и, возможно, ваш код для их обновления (в зависимости от того, будет ли это значение когда-либо обновляться, когда оно будет на месте). также, вероятно, некоторые элементы, которые могут быть затронуты. Код вставки должен быть на месте примерно в то же время, что и изменение, которое делает столбец не допускающим значения NULL, иначе все вставки не будут выполнены, пока вы не вставите его на место. Вы можете сделать это, сделав все это одним большим скриптом.

Если вы думаете, что многие из них будут затронуты, потребуется некоторое время, чтобы разобрать их все. создайте новую таблицу, включая новый столбец. Заполните его из старой таблицы. Измените вставку / обновления / удаления, чтобы перейти к новой таблице. Затем отбросьте старую таблицу и создайте представление с именем старой таблицы, в которой есть только старые столбцы. Делайте все это в сценариях, чтобы он мог работать на продукте все вместе. Не запускайте его в течение основной части дня, запланируйте его запуск в самые легкие часы использования базы данных.

If adding a new column in the existing table is not acceptable, add a new table in one-to-one relation with the old table. It should contain the primary key field as in the old table, and the new column(s). This key field is primary key also for the new table (to enforce one-to-(zero or one) cardinality).

The disadvantage is that:

• in order to find new data, you need для выполнения соединения (фактически внешнего соединения).
• при вставке / обновлении / удалении записи, вы должны сделать это за два таблицы

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

Вы можете уточнить это?

Добавление столбцов как допускающих значение NULL или со значениями по умолчанию означает, что фактически никому не придется предоставлять значения. нет воздействия

Если вас беспокоит время блокировки при добавлении столбца в таблицу, добавьте столбцы в конец таблицы (таким образом SQL Server не должен создавать новый таблицу, скопируйте в нее данные, удалите старую таблицу и переименуйте новую.) почти не повлияет на время выполнения

Добавление 50 миллионов строк данных почти не повлияет на время выполнения?

Пользователь @BrianWhite кажется чтобы запутаться, как добавление столбца в таблицу, содержащую 50 миллионов строк, может почти не повлиять на время выполнения. Кажется, он думает, что добавление столбца в большую таблицу - дорогостоящая операция, это вызовет проблемы для других пользователей, поскольку расширенная операция блокирует пользователей. Похоже, он думает, что добавление столбца заставляет сервер записывать 50 миллионов строк:

он будет удерживать блокировку таблицы на время, необходимое для записи 50 миллионов записей данных

Важным моментом является то, что он будет не записывать 50 миллионов записей данных. Чтобы продемонстрировать это, у вас есть таблица с 28,176,266 строками ( 4557 МБ ):

--How many rows in the table
SELECT COUNT(*) FROM BigTable

28176266
(1 row(s) affected)

--How big is the table
EXECUTE sp_spaceused 'BigTable'

name      rows      reserved    data        index_size  unused
--------  --------  ----------  ----------  ----------  ------
BigTable  28176266  4681560 KB  4666984 KB  14536 KB    40 KB

Теперь, когда мы установили, что у меня 28 миллионов ], то есть 4,6 ГБ , давайте добавим столбец в эту таблицу:

ALTER TABLE BigTable ADD NewColumn int NULL

Подождите! Вопрос: Сколько времени это займет? Разве это не долгая операция, которая потребует блокировки таблицы при создании 28 миллионов записей?

Нет! Давайте посмотрим, сколько времени это займет: