SQL SERVER, exclusive lock on table

[Andrey Strelnikov]

Ну ОК и как "имя сущности в предметной области" относится к "плохости" autoincrement ID?

а исчо есть такая телефонная система 3CX. Исторический зоопарк в API. Часть API тоже выдает autoincrement номеров звонков. Причем перестарт сервера телефонии начинает отсчет ID звонков заново... И иногда может упасть несколько раз в день. Уже надо что-то думать кроме autoincrement + date в big interger

[VovaK98]

Где как, очевидно. У нас в одних таблицах sequence, в других max(id) + 1 (обычно secondary id). Разве что oracle вместо sql server, но тут однохренственно.

Во всех non-dictionary таблицах я сразу при дизайне закладываю 3 первых поля - это id = bigint autoincrement, guid = newid() (для репликации и прочих ETL) и created=getutcdate(). И никаких clustered indexes, только обычные.
В таблицах, которые содержат всякие dictionary data, created опционально, но лучше иметь clustered index, он же primary index на id.
Это кроет 99.9% всех приложений и ситуаций, которые я встречал за последние лет так 15.

Там дальше обычно добавляю userguid, чтобы знать, какая скотина что сломала, modified, чтобы знать когда она это сломала, и т п.

[KVA]

@Andrey Strelnikov - Я так и не понял как кривые руки вендора соотносятся с плохостью autoincrement. Представьте что те кривые руки свои ID начнут генерировать. Да еще забудут их unique сделать.

@VovaK98 +1 к подходу с дизайном.

[Andrey Strelnikov]

@Andrey Strelnikov - Я так и не понял как кривые руки вендора соотносятся с плохостью autoincrement. Представьте что те кривые руки свои ID начнут генерировать. Да еще забудут их unique сделать.

А guid не колготки. Кривые не сделаешь

А у нас Новый год на подходе

С праздником вас коллеги!