spежели предусматривается как в 1С и MSCRM выгрузка и загрузка конфигураций - то тут без GUID в качестве ключей - никуда!Составной ключ, одна из частей которого "код реплики", спасет отца русской демократии. Решаемо без всяких GUID - легко и непринужденно!..
"Исключительная бесполезность" GUID в качестве ключа имеет весьма относительный смысл только при слиянии данных из категорически РАЗНОРОДНЫХ источников...
И исключительно в тех случаях, когда в хотя бы одной из "сливаемых" систем используются именно такие ПК...

тверскойsphinx_mvпропущено...

Не вопрос... Но тут такое дело... Например, есть задача, в котоой достаточно часто (раз в несколько секунд) требуется выбрать последние N вставленных записей в таблицу (что-то под десяток млн. записей в месяц, примерно 20 ГБ данных на диске)... Данные в таблицу вставляются несколькими "тупыми железяками"... Прикажете делать еще одно поле с датой/временем вставки и индексировать его? вариант, конечно, но вот только в случае с целочисленным автоинкрементным суррогатным ключом это даже не просто, а ОЧЕНЬ просто - выбрать последние записи по индексу... Без всяких дополнительных накладных расходов...
Что показывает данный конкретный случай? Что в некоторых условиях самое большое значение автоинкрементного поля, скорее всего, совпадает с самыми "новыми" данными, но с этим никто и не спорит )))
Стоит одной из "тупых железок" задержать отправку данных (сбой на канале, увеличение буфера на железке, изменение порядка отправки данных из буфера или др.) и последние N записей уже могут не быть самыми новыми. Заменит производитель в одной из железок алгоритм "очередь" на "стэк", и использование автоинкрементного поля пойдет лесом.
И это без учета особенностей обработки вставляемых данных в процедурах/триггерах БД.
Вот только не надо высосаных из пальца детских страшилок рассказывать!
Во-первых, максимальная длина необработанной очереди в любом стеке должна быть равна 0!
Во-вторых, аварийное состояние системы тем и отличается от нормального , что в системе "происходит не совсем то и не совсем так"...
В-третьих, от того, что "канал упал" или "стек забился" последние вставленные в таблицу данные НЕ перестают быть последними вставленными данными, даже если они относятся к данным за позапрошлый век.
И весьма актуальное "а-на-на" кому надо (по чем надо) за аварийное состояние системы, минимальные требование по доступности которой ограничиваются на уровне "24/7/365", будет прописано с гораздо большей оперативностью (с сильно меньшими затратами).

тверскойzeon11,
тема, если прочитали, - где заполняете PK, на клиенте или на сервере
GUID - один из примеров ключа (обсуждение его преимуществ и недостатков оставим)

Обсуждать варианты БЕЗ обсуждения плюсов и минусов - бред!
GUID - это единственный разумный способ генерации ПК на клиенте.
И все бы бы хорошо, но вот только количество недостатков этого способа вполне зашкаливает по сравнениями с теми, якобы, преимуществами, которые он предоставляет...

vadiminfosphinx_mvНо тут такое дело... Например, есть задача, в котоой достаточно часто (раз в несколько секунд) требуется выбрать последние N вставленных записей в таблицу (что-то под десяток млн. записей в месяц, примерно 20 ГБ данных на диске)... Данные в таблицу вставляются несколькими "тупыми железяками"... Прикажете делать еще одно поле с датой/временем вставки и индексировать его? вариант, конечно, но вот только в случае с целочисленным автоинкрементным суррогатным ключом это даже не просто, а ОЧЕНЬ просто - выбрать последние записи по индексу... Без всяких дополнительных накладных расходов...
Заплатки тоже часто выглядят как Очень просто. Но вседа ли на протяжении ЖЦ системы не снижают качества системы? Ить они могут увеличивать неопределенность програмного обеспечения.

В РМД нет понятия последние, первые записи - там неупорядоченность типа задекларирована. И стало быть если нужно такое, то с точки зрения МД, это должно быть поле сортитовки, т.е. не суррогат: его значения имею смысл в предметной области и должны контролироваться в общем случае юзерами. Т.е. он должен иметь их возможность подправлять в случае несоотвествия. Это сразу же ухудшает основное достоинсво суррогата - его неизменность.

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

Ну, и по поводу порядка/беспорядка...
Доступ к данным "по индексу" подразумевает, что данные упорядочиваются...
К чему сентеции о недекларированности упорядоченности в РМД - не понятно...

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

Ну-ка... Про "full scan" поподробнее...
Например, на основе вот этого примера - select top NNN * from tblXXX order by id desc
Индекс по ID присутствует... Я даже больше скажу: это первичный индекс по автоинкрементному полю...
"Получить последние NNN записи, вставленные в таблицу" - так звучала задача...
vadiminfoОбъявив поле суррогатным, Вы типа задекларировали, что его значения смысла не имеют, поэтому их изменение,например админом или другим разработчиком допустимы. Не важно зачем ему это понадибится, но имеет право. А если теперь юзаются непосредственно какие-то значения в запросах, то это надо поддерживать с помошью ОЦ. Например, запретить смену. А это уже доп затраты.

Внятно объяснить ДЛЯ ЧЕГО нужно менять первичный ключ вряд ли кто-то сможет...
ПОСЛЕ чего - я могу... Но я столько не выпью...

Вам нужно менять что-то "уникальное" - это альтернантивный ключ. И все!
Никаких проблем с проверкой ссылочной целостности и каскадными обновлениями!..
vadiminfoЕсли уж возник вопрос кто первый, кто последний, то, возможно, рано или поздно может возникнуть вопрос на сколько он превый по времени. Сукррогат и вообще не дата на это не ответит.

Во-первых, когда возникнет этот вопрос - тогда он и должен решаться.
А, во-вторых, Вы будете смеяться... Без ДАТЫ правильно получить посленюю "ПО ВРЕМЕНИ" запись вы вряд ли сможете...
vadiminfoНу тут говорили, что суррогаты не должны быть видны типа юзеру. Ну что же. Хорошо. Но тада напрашивается, что их не должны значения ни в каких сортировках. Ведь это в какой-то мере приравнивет их значеня к содержательным данным: но последние можно провенрить, например, по документам или как там у них положены проверки содержания БД, а первые то нет: их в нет в передметной области никак.

В реальных системе первичные ключи используются для идентификации записи и для контроля ссылочной целостности.
Никто НЕ заставляет пользователей и разработчиков использовать их значение в сортировках.
Но кто сказал, что (в некоторых задачах) такая сортировка не может понадобиться?
vadiminfoНужно помнить про особенность данного суррогата, против обычного их юзания. Тоже доп затраты.

Ну, и какие ДОПОЛНИТЕЛЬНЫЕ затраты для суррогата Вы наблюдаете? Особенно - если он "автоинкрементный"?
Ну, хотя бы на вскидку... Неужто резервирование диапазонов ключей?
А ЗАЧЕМ их резервировать?!
vadiminfoИ вообще.

Скорее всего, преждевеременно говороить, что другие альтернативы заведомо хуже.
Выбор между естественным и искусственным (суррогатным) ключем - в пользу суррогата...
Выбор между монотонно нарастающим (ака, "автоинкрементным") суррогатом и генерируемым случайным образом (например, GUID) - в пользу "автоинкремента"...
Генерирование значения ключа на сервере БЕЗОПАСНЕЕ генерации ключа на клиенте...
Собственно, альтернатив, как бы, больше и нет...

тверскойzeon11тверской,
Ну, это другое дело.
Если объём большой, нет ссылочной целостности, для скорости отключаем триггеры
(мы-же в монополии ?), берём начальное значение генератора, устанавливаем генратор в +100 000 000, заливаем данные с клиента, где поле PK формируется на клиенте. включаем триггер.
Но это всё опасно, нужно быть очень тщательным!
Монополия не обязательна. Триггер можно совсем не создавать, вместо постоянного вкл./выкл.
Отвественность на приложении за правильное заполнение PK. Ограничение PK всё равно не даст ввести дубликат в это поле, приложение само должно уметь обрабатывать последствия своих ошибок.
Все бы замечательно...
Но, исходя из поставленной задачи, вставляется МНОГО записей... Например, 1,000,000...
Предположим, возникнет ошибка на 999,999-й записи... Приложение, конечно, "должно уметь обрабатывать" такие ситуации...
И даже предположим, что приложение эту ситуацию обработает...
Вот только на сервере при этом все равно должна откатится вставка всех предыдущих 999,998 штук...
И оно Вам надо?!

тверскойsphinx_mvВсе бы замечательно...
Но, исходя из поставленной задачи, вставляется МНОГО записей... Например, 1,000,000...
Предположим, возникнет ошибка на 999,999-й записи... Приложение, конечно, "должно уметь обрабатывать" такие ситуации...
И даже предположим, что приложение эту ситуацию обработает...
Вот только на сервере при этом все равно должна откатится вставка всех предыдущих 999,998 штук...
И оно Вам надо?!
не вижу проблемы, всё зависит от источника ошибки
если ошибка именно в некорректной вставке ID - надо выявить ошибку и устранить, это не сложно (если генератор никто вручную не крутит туда-сюда, иначе ошибки вылезут и при заполнении ID на стороне сервера)

Изменение последовательностей и значений генераторов для ПК в базах данных - бесполезная трата времени, чреватая наступлением на короткие (чуть ниже, чем по пояс) грабли...

И интересный такой вопрос на тему "простоты"...
Для того, чтобы пофиксить дубликаты, нужно будет в конфликтных заливаемых записях прописать новые значения ПК (при этом как таковые значения могут быть ЛЮБЫМИ)...
Необходимо проверить, что (на момент времени "Ч") новое значение отсутствует в таблице-получателе...
При этом не стоит забывать про ссылочную целостность, и откорректировать все зависимые данные...
Где гарантия, что за время всех этих телодвижений какой-нибудь другой ключ не станет проблемным? (и понеслась новая итерация)
тверскойесли ошибка не в ID (обрыв канала или др.) - от выбора метода заполнения ID (на сервере или на клиенте) она не зависит
Если режим вставки не монопольный , то возникновение проблемы с уникальностью вставки ключа будет не исключительной , а очень стандартной ситуацией... В случае с заполнением ID на сервере (если никто не играется с генераторами) дублирующееся значение получить крайне маловероятно.

Рутинное разруливание конфликтов ПК на вставках больших объемов данных - оно вам ДЕЙСТВИТЕЛЬНО надо?