Изменение nvarchar (MAX) на nvarchar (n) в базе данных - PullRequest
Новая
       49

Изменение nvarchar (MAX) на nvarchar (n) в базе данных

1 голос
/ 11 марта 2019

Я только что изменил поле nvarchar (MAX) в таблице на nvarchar (250).Может кто-нибудь сказать мне, что происходит с данными, если в них была запись длиной более 250 символов?

Меня беспокоит не видимые данные, а то, что происходит за кадром:

  • Что делается с данными, которые выходят за пределы этого контейнера данных?
  • В нескольких местах я прочитал, что таблицу необходимо удалить и заново создать.Это правда и почему?Я не видел ошибок, которые получили другие.
  • Есть ли способ восстановить усеченные данные после внесения этого изменения?(Я не хочу этого делать, но мне любопытно)

Ответы [ 2 ]

3 голосов
/ 11 марта 2019

Если вы изменили / изменили поле столбца nvarchar (MAX) на nvarchar (250) и не получили никаких ошибок, это означает, что ни один в строках не содержит данных более 250 символов, поэтому SQL-сервер успешно изменил длину столбца и ваши данные точны / полны.

Если какая-либо строка содержит более 250 символов, SQL-сервер выдаст вам ошибку, и оператор alter не будет выполнен. Это означает, что длина типа данных не будет изменена.

Сообщение 8152, уровень 16, состояние 13, строка 12 Строка или двоичные данные будут усеченный. Заявление было прекращено.

При изменении длины столбца, если SET ANSI_WARNINGS OFF, сервер SQL изменит длину столбца без предупреждения, и дополнительные данные будут усечены.

По умолчанию SET ANSI_WARNINGS ON предупреждает пользователя.

Я думаю, что если данные обрезаны, они не могут быть восстановлены позже.

0 голосов
/ 11 марта 2019

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

В зависимости от СУБД и версии, вы можете даже не иметь возможности изменять длину столбца.

Однако, если у вас нет строк, превышающих 250, как вы сказали, тогда проблем быть не должно.

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

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

MySQL автоматически резервирует максимально возможную длину для столбца переменной длины, независимо от того, равна ли строка 15 символам или 45 или 250. Это, как вы можете себе представить, в конечном итоге приводит к узким местам в системе. (Возможно, у вас недостаточно базы данных, чтобы показывать эффекты, но мой девиз «предупрежден, значит вооружен»)

...