MSSQL 2005
дано: большая таблица фактов, в которую сыплется 3 разные сущности ( накладные , заказы,остатки). точка входа процедура вставки.
задача: разделить на 3 таблици (нормализация)
Сложности: для сохранения уже написанных отчетов будет существовать представление/ Имеется PK identity , как мне сохранить единый сквозной PK при вставке новых записей.

есть 2 врианта:
1 тригер на каждую из 3х новых таблиц на insert который выбирает из 3х максимальное значение ключа и вставляет +1 с IDENTITY_INSERT ON
2 в процедуре вставки проводить аналогичные операции

Вопрос, можно ли придумать более элегантное решение, к примеру с применением ограничений или суррогатных ключей.

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

Naf,

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

на данный момент склоняюсь к написанию своей функции аналога oracle sequence

iljy,
код мне кажется не таким сложным, а решение более элегантным.

egorychkain111,

GUID чем не подходит?

происходит частое соединение по этому ключу с деталями, если будет varchar GUID то это утяжелит базу

Злой БобрНу создай 3 таблицы. Перепиши отчеты. Перенеси данные.
Непойму за что пытаетесь побороться?..
за производительность все, чего же еще может быть. ну и за общей организацией структуры, долго пересказывать, а на судьбу жаловаться не хочется :)

alexeyvgkain111iljy,
код мне кажется не таким сложным, а решение более элегантным.Интересно, чем это решение элегантнее IDENTITY с разделением диапазонов?
нет пустых значений,
к примеру можно восстановить последовательность появления каждой записи.
Ну и я тут работаю не долго и потому просто пока стесняюсь делать такие резкие изменения.

возможно пояснение изменит мнение. вставка происходит единожды в день одной функцией вызываемой последовательно отдельным сервисом. Табличка очень тяжелая, по сути являющаяся рабочей табличкой с большим колличеством избыточной информации призванной обеспечить доставку и синхронизацию информации, например GUID генерируемые с КПК. Табличка тяжелая (шапка 9млн+ детали 120млн) и сильно растет(500к деталей в день). Моя позиция осложняется желаниями начальства + большой текучкой когда многие задумки и объяснения просто канули в лету.

onedes,

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

авторiljy
kain111
возможно пояснение изменит мнение. вставка происходит единожды в день одной функцией вызываемой последовательно отдельным сервисом. Табличка очень тяжелая, по сути являющаяся рабочей табличкой с большим колличеством избыточной информации призванной обеспечить доставку и синхронизацию информации, например GUID генерируемые с КПК. Табличка тяжелая (шапка 9млн+ детали 120млн) и сильно растет(500к деталей в день). Моя позиция осложняется желаниями начальства + большой текучкой когда многие задумки и объяснения просто канули в лету.

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

По производительности с GUID действительно будет некоторый проигрыш; если таблица узкая, много ссылок, много индексов - то заметный, хотя и не настолько, чтобы о таком варианте забыть.

GUID 32 чар, генерится на кпк дистрибьюторов обычной виндовой функцией, потом сливается инфа в их локальную базу, проверяясь на уникальность по этому guid, затем в общее хранилище уникальность идет уже по коду дистрибьютера и его PK int identity, в частности нехитрым скриптом я нашел дублирующиеся у нас в таблице записи GUID.какая то неправильная реализация на стороне дистрибьютора.

В связи с 1й неделей месяца, а сервер обычно бывает нагружен под 80%, мероприятия откладываются и есть время подумать. Спасибо за мысли и изложенный опыт. Вариант с диапазонами кажется заманчивым.