А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись?
Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
Здравствуйте, Artem Korneev, Вы писали:
AK>А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись? AK>Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
AK>База — MS SQL, если это важно.
cascade update?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Artem Korneev, Вы писали:
AK>А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись? AK>Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
AK>База — MS SQL, если это важно.
Создать bigint колонку, заполнить её данными из ID, поменять первичный ключ, удалить старую колонку.
Здравствуйте, Artem Korneev, Вы писали:
AK> А что делают с таблицей, если у неё диапазон доступных ID закончился
Вызываю дизайнера БД на ковер и тычут носом.
Затем расширяют разрядность ID во всех таблицах с помошью ALTER TABLE.
AK> Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
Здравствуйте, Artem Korneev, Вы писали:
AK>А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись? AK>Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.? AK>База — MS SQL, если это важно.
Здравствуйте, gandjustas, Вы писали:
G>Создать bigint колонку, заполнить её данными из ID, поменять первичный ключ, удалить старую колонку.
G>превысить bigint пока еще никому не удалось
А зачем создавать/удалять колонку? Ограничения в виде PK, FK и прочее разрывать все равно придется. Поэтому можно просто сделать alter table … alter column bigint и восстановить связи.
Здравствуйте, Artem Korneev, Вы писали:
AK>А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись? AK>Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
AK>База — MS SQL, если это важно.
Я бы пересоздал таблицу с изменением типа данных на более широкий (8 байтов видимо).
Перетрясти можно, в принципе любая адекватная база данных спокойно переименовывает поле и все ссылающиеся на него поля (on update cascade). Но тут могут вылезти неожиданные проблемы с другими системами, использующими эти ID, историческими логами и т.д. Да и это слишком временное решение, как мне кажется, через какое то время проблема опять возникнет. Требует вероятно остановки всей системы. А пересоздание таблицы можно делать "рядом", а потом быстро переименовать их туда-сюда. Ну или столбец создать/изменить, если ваша база не залочит таблицу при этом на длительное время.
Здравствуйте, Artem Korneev, Вы писали:
AK>А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись? AK>Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
AK>База — MS SQL, если это важно.
Такая проблема возникла пару лет назад у известной кампутерной онлайн игрушки
ID-шники внутриигровых денежных транзакций превысили положительный int32.
Некоторое время они изгалялись реюзом старых ID-шников, но потом таки перешли на int64
Так что лучше сразу переползать на int64 чем пытаться вставлять костыли в колёса.
--------------------------------------------------------------
Правильно заданный вопрос содержит в себе половину ответа
Здравствуйте, Artem Korneev, Вы писали:
AK>А что делают с таблицей, если у неё диапазон доступных ID закончился, но при этом в списке используемых ID есть большие пробелы — данные удалялись?
Находи самый большой неиспльзуемый диапазон и переставляй identity (или sequence) на его начало.
Пока будет работать -- готовься расширять поле PK.
AK>Есть ли какие-нибудь стандартные средства перетрясти используемые ID чтоб перенумеровать их заново, автоматически перенастроить внешние ключи других таблиц и т.д.?
Здравствуйте, AndrewN, Вы писали:
AN>Такая проблема возникла пару лет назад у известной кампутерной онлайн игрушки
AN>ID-шники внутриигровых денежных транзакций превысили положительный int32. AN>Некоторое время они изгалялись реюзом старых ID-шников, но потом таки перешли на int64
Дурни, надо было перейти на отрицательные ID, ещё бы столько же времени прожили, а там глядь --
уже и игрушка бы сама собой померла...
Здравствуйте, AndrewN, Вы писали:
AN>Так что лучше сразу переползать на int64 чем пытаться вставлять костыли в колёса.
Если этот ID показывается клиенту — есть проблема с обратной совместимостью, когда старые версии клиента могут быть не готовы обрабатывать int64. Особенно это актуально для проектов в длинной историей.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Olaf, Вы писали:
O>> Ограничения в виде PK, FK и прочее разрывать все равно придется.
W>Зачем?
Это конечно же нужно делать при условии, что поле участвует в ограничениях (PK, FK, DF, CH и т.д.). Если создавать новую колонку, со старой эти ограничения придется снять в любом случае и поставить на новую. Если делать alter column без создания новой колонки, то для выполнения инструкции alter table есть требования
The modified column cannot be any one of the following:
...
Used in a PRIMARY KEY or [FOREIGN KEY] REFERENCES constraint.
Used in a CHECK or UNIQUE constraint. However, changing the length of a variable-length column used in a CHECK or UNIQUE constraint is allowed.
Associated with a default definition. However, the length, precision, or scale of a column can be changed if the data type is not changed.
...
Здравствуйте, Olaf, Вы писали:
O> The modified column cannot be any one of the following: O> Used in a PRIMARY KEY or [FOREIGN KEY] REFERENCES constraint.
Не знал об этом ограничении, спасибо. Казалось бы, уж SQL 2014 на дворе, а воз и ныне там.
