авторИ вообще сыр-бор как я понимаю только из-за того, что кто-то очень хочет писать
update/delete... where id=:id
вместо
update/delete .... where (division_id,id)=(:division_id,:id)

потому, что в первом варианте короче?
мне надоели эти выпады. А если предположить некое интранет/интернет приложение, которое выводит строки из БД, для последующей модификации/удаления. Самый простой способ - это передать единственный параметр, уникально определяющий запись, чем массив параметров. В большом приложении - это становится настоящей проблемой отслеживать такие вещи. Или вы против того, что чем проще механизм тем он надежнее?

авторСдается мне что причина вообще несколько в другом. У MSSQL имеется только IDENTITY поле, которое обязательно подразумемает индекс. У того же Оракла и ДБ2 есть SEQUENCE. (У ДБ2 есть и IDENTITY тоже в дополнение к SEQUENCE).
Соответственно и подходы диктуются используемым сервером БД.
вряд ли используемый сервер здесь имеет значение. хотя может быть именно отсутствие SEQUENCE для AS/400 и побудило нашу команду использовать IDENTITY и проч? или всё таки удобство?

авторА вопросик можно?
Вы в какой базе этот запрос делаете?
В базе филиала или в консолидированной базе?
Если в базе филиала - то никаких проблем.
А если в консолидированной - это ее проблемы :))

а какие могут быть проблемы в консолидированной? Селективность у уникального индекса куда как очень хорошая. Так ведь? Или о чем вы?

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

авторЯ читаю первое (Ваше) сообщение этого треда. Вижу описание примера, которое на мой взгляд, является типично кривым. Т. е. "выбор identity field в качестве PK - кривое решение" - ответ нет. А вот Ваш пример - это пример кривого решения. Отсюда и вопросы.


identitiy генерится через одну таблицу, затем префиксуется/постфиксуется условным кодом области, полученное id используется в кач-ве первичного ключа в остальных документах БД. Это решение сильно кривое?

авторЧего пример, простите? Что мне этот пример должен объяснить?

softwarercreate sequence S minvalue 1000 maxvalue 2000 - эта конструкция достаточно однозначна - значения не выходят за диапазон.

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

авторТ. е. условный код добавляется в начало первичного ключа и в конец (префикс + id + суффикс; префикс = суффиксу), так? Каков размер первичного ключа? Что Вы собираетесь делать при необходимости описывать филиалы филиалов?

префикс ИЛИ суффикс - у нас префикс. Некоторые делают суффикс - это не имеет значения. размер первичного ключа - integer+2 символа префикса. филиалы филиалов (даже если они будут, что вряд ли :) ) получат свой префикс вот и все.

авторЭто понятно. А почему Вы считаете, что заявленного диапазона Вам должно хватить (причем, в сильно урезанном виде из-за алгоритма формирования первичного ключа)?
в нашем случае диапазон иссякнет не очень скоро. сколько там под интегер отведено? кажется 4 байта, + 2 байта префикс даже при нынешней нагрузке (5000 записей в день) - этого хватит надолго