тверскойzeon11Ну, и насчёт GUID:
1.Очевидно, что ожидать ускорения работы БД и уменьшения размера БД в случае использования GUID не приходится.
2.При использовании целочисленного РК вы получаете в качестве бонуса лёгкий способ определения старшинства записи, контроль целостности данных.
3. РК рано или поздно при проектировании БД войдёт в другую таблицу в качестве FK,
и таких внешних ключей в одной таблице может быть не один, а достаточно много. Представьте, как будет выглядеть такая таблица при прямом просмотре?

по 1.
Что очевидно? да, 16 байт GUID в два раза больше, чем 8 байн BigInt, но в масштабах БД это будут копейки

Начиная с того, что абсолютная уникальность GUID, собственно, не очень-то и гарантируется (т.е., могут быть дубликаты и не только теоретически), и заканчивая тем, что GUID по сути - случайное число, последовательная вставка которых в индексы приводит, мягко говоря, к тихому страху и ужасу для дисковой подсистемы при работе с большими объемами данных...
Если GUID-поле входит еще и в кластерный индекс (в стиле MSSQL) - туши свет, пиши письма...
тверскойпо 2.
Определение старшинства записи по значению PK - это, мягко говоря, бред. Подобный метод применяется в БД "на коленке", где данные добавляет только один пользователь и всегда только "по старшинству".

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

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 на сервере (если никто не играется с генераторами) дублирующееся значение получить крайне маловероятно.

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

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


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

Есть некоторый "контингент", который "ничей опыт ничему не научит"...
Для них, как говорит народная мудрость, никакие законы не писаны...
vadiminfosphinx_mvУ некоторой сущности есть нечто уникальное, что пользователь должен вводить и иногда менять?

Ну вообще-то есть, наверное. Выше уже приводили примеры.

Вообще-то нечто, что может измениться идентифицирующим быть не может, да и претендовать на уникальность может с ОЧЕНЬ большой натяжкой - изменение может привести к "занулению" значения поля. Результат проверки уникальности пустых значений - весьма интересный академический вопрос, выходящий за рамки обсуждения.

ну, ладно... Возьмем простой "классический" пример - однозначным образом идентифицировать человека как?
Как говорит "теория" - по номеру удостоверяющего личность документа.
Вопрос на засыпку... У меня этих (действующих!) документов пять штук... Ну, и который из номеров "правильный"?
А еще есть некоторое количество личностей, которые НЕ имеют документов (например, ЕЩЕ)...
vadiminfosphinx_mvНу, и по поводу порядка/беспорядка...
Доступ к данным "по индексу" подразумевает, что данные упорядочиваются...
К чему сентеции о недекларированности упорядоченности в РМД - не понятно...

Ну, возможно, доступ к данным "по индексу" не имеет отношение к РМД. Все таки индексы - средства повышения проиводительности в СУБД, в которых данные хранятся на вторичных носителях. В СУБД "ин мемори" индексы, возможно, вообще не нужны, а РМД все еще нужна. А Вы говорите, что не понимаете.

Т.е., Вы как бы "не в курсе", что несортированые списки - смерть для поиска?
Тем более при нынешних объемах "мемори"...
vadiminfosphinx_mvВас смущает, что суррогатный ключ не укладывается в Вашу модель данных?

Я, вроде, не смущался, а допускал существование недостаков. Т.е. я юзаю суррогаты, но не считаю, что у них нет недостатков.

"Халва, халва"... Ну, хотя бы один, который отсутствует в естественных?
vadiminfosphinx_mvСуррогат, который не имеет отображения в предметной области, НЕ влияет на саму предметную область, но со своими функциями справляется не в пример лучше естественных ключей, любой из которых может в любой произвольный момент времени перестать быть ключем... Даже если это ключ изначально был составным...

А естественные, к примеру, луче суррогатных, тем что "помогают идентифицировать" сущности, а не просто записи. В частности, суррогат не помешает Вам завести дубль сущности, хотя и с разными суррогатами.

С абсолютно таким же успехом я могу задублировать сущности на "естественных" ПК!
vadiminfosphinx_mvНу-ка... Про "full scan" поподробнее...

Имелось ввиду Икремент сам по себе не отменяет фулскана. По крайней мере, во многих СУБД. А с индексами не тока суррогаты инкрементные фул скан могут отменить.

Но только автоинкрементные суррогаты делают это с максимально возможной эффективностью...
vadiminfosphinx_mvНапример, на основе вот этого примера - select top NNN * from tblXXX order by id desc
Индекс по ID присутствует... Я даже больше скажу: это первичный индекс по автоинкрементному полю...
"Получить последние NNN записи, вставленные в таблицу" - так звучала задача...

Ну приндексируйте по дате. Кроме того, там было про другие колонки для сортировки, которые не являются суррогатами и даже РК.

Вообще-то. даже на соседних компьютерах синхронизация времени "улетает" - это даже если не учитывать переход на зимнее/летнее время и часовые пояса... Будем такое ненадежное значение считать достоверным?
vadiminfosphinx_mvВнятно объяснить ДЛЯ ЧЕГО нужно менять первичный ключ вряд ли кто-то сможет...
ПОСЛЕ чего - я могу... Но я столько не выпью...

Зато если изменит, то не нарушит информационное содержание БД. Для особо придирчивых: не нарушая ОЦ, изменит.
И стало быть Вы буите рассмативать серьезную ОШИБКУ?

Вы всерьез считаете, что целостность данных не нарушится?
А что нам скажут неформальная ссылочная целостность и репликация?
Кстати, как вариант репликации имеет смысл рассматривать отчеты...
vadiminfosphinx_mvВам нужно менять что-то "уникальное" - это альтернантивный ключ. И все!

Это был приказ?

Да. И исполнять БЕГОМ!
vadiminfosphinx_mvНикаких проблем с проверкой ссылочной целостности и каскадными обновлениями!..

Вообще-то ссылочную целостность моно организовывать не тока по первичным ключам, с одной стороны. А с другой, в Аксцессе, вроде, проблем нет с каскадными обновлениями и при изаенении первичных ключей.

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

Может быть буит поздняк метаться.
Смеяться не буду, хотя именно на преимущество ДАТы перед инкрементом я намекал.
Дату задним числом то не проставить в общем случае: вот и поздняк решать буит.

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

Вообще-то намекалось на то, что если кто-то юзает суррогаты по значениям в запросах, то это особенность по сравнеиню с суррогатами, которые юзаются именно исходя из того что их значения смысла не имеют.
Например, Если в запросе написано
WHERE id=5, то после замены 5 на 500 запрос покажет не то что должен, скорее всего. Например, данные пропали и их восстанвливали из доков вручную.

Вообще-то, некоторая выборка в которой участвует значение суррогатного ключа справочника НЕ перестает быть выборкой по значению суррогата... Если некто пишет некоторый запрос и НЕ представляет КАКОЙ результат он хочет получить - это несколько в стороне от обсуждаемого вопроса...
vadiminfoА GUID - во вселенной. Это может иметь значение в каких-то случаях.
А вот с матчастью как-то слабовато смотрится...
Для GUID без сетевого интерфейса относительная уникальность гарантируется в пределах компьютера... Вот такая супер-пупер крутейшая информационная система... ДЕСКТОПНАЯ...
Для GUID с сетевой платой формируется на основе MAC-адреса... Ну, так вот... Уникальные MAC-адреса бывают... Но только НЕ в этой вселенной... Специально в подтверждение этому существует возможность а) "ручками" перебить MAC-адрес и б) склонировать его с другого интерфейса... Соответственно, шанс на получение дублированного GUID не очень большой, но заявлять об абсолютной его уникальности во вселенной - не "круто"...