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 не очень большой, но заявлять об абсолютной его уникальности во вселенной - не "круто"...

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

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

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

В конкретном проекте, однозначно, может например страховой номер. Есть типа некоея предельная сила идентификации, которой может хватить проекту.
Есче раз хочу сказать про оценку достоинств и недостатков для конкретного проекта.

А теперь вопрос на засыпку - ЧТО есть суть страхового номера?
Пусть меня отшлепает тапком первый, кто внятно докажет, что это НЕ суррогат!
Естественный ключи!.. Естественные ключи!.. А как присмотришься по-внимательнее - СУРРОГАТЫ! ВСЕГДА И ВЕЗДЕ!

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

Я как бы не в курсе что какие-то там списки имеют отношение к РМД. Вот в иерархичесих упорядоченность, вроде, присутствует: там типа на уровне МД поддерживается первые последние и т.д.

Сортировка и поиск - суть, основные алгоритмы при обработке данных...
Читайте первоисточники - они, как бы, рулес...
vadiminfosphinx_mv"Халва, халва"... Ну, хотя бы один, который отсутствует в естественных?

Ну так это ж широко вроде известно. Еще, вроде, Кодд не хотел ничего, чего нет в предметной области иметь в МД. Ну даже не знау. Вам что слово "суррогатный" не говорит о некоем предвзятом отношении?

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

Ну поробуйте занести Сидорова с естественным по страховому. А я с разными суррогатами, думаю, смогу занести.

А это ничего, что "естественный по страховому" ничто иное как автоинкремент внутри информационной системы страхавания?
И, кстати, ошибки ввода никто не отменял...
В результате операторской ошибки НЕВЕРНОЕ значение иденитификатора начинает произвольным образом разгуливать по информационной системе. Кстати, некто Сидоров ЛЕГКО И НЕПРИНУЖДЕННО зарегистрировался в системе дважды... А то и трижды... В результате АНАЛОГИЧНОЙ ошибки...
vadiminfo
sphinx_mvНо только автоинкрементные суррогаты делают это с максимально возможной эффективностью...

Ну мне ничего про это не известно: планы запросов вроде никак не учитываю автоинремент это или нет.

А не надо аппелировать к тупому оптимизатору запросов...
Любые операции над целочисленными данными выполняются ЭФФЕКТИВНЕЕ, чем операции над их строковым представлением.
ЭТОГО достаточно - естественные ключи (практически) НИКОГДА не могут быть представлены как ЧИСЛО.
vadiminfosphinx_mvВообще-то. даже на соседних компьютерах синхронизация времени "улетает" - это даже если не учитывать переход на зимнее/летнее время и часовые пояса... Будем такое ненадежное значение считать достоверным?

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

Вы НЕ представляете особенности функционирования АВТОИНКРЕМЕНТНОГО поля!
НИКОГДА (в штатной ситуации!) НЕЛЬЗЯ ВСТАВИТЬ в такой ключ значение, которое меньше любого ранее введенного!
Соответственно, в следствии этой ПРОСТУЮ особенности автоинкрементного ключа ВСЕГДА есть возможность определения ПОРЯДКА ВСТАВКИ записей в таблицу.
vadiminfosphinx_mvВы всерьез считаете, что целостность данных не нарушится?
А что нам скажут неформальная ссылочная целостность и репликация?
Кстати, как вариант репликации имеет смысл рассматривать отчеты...

Ну а для кого я написал, что ОЦ не изменит. Ну так извините моно по ошибке всю БД стереть. Про неформальную ссылочную целостность оставлю неформалам думать. Что до репликации, ну отреплицирует. По любасу это проблемы репликации если у нее траблы, када юзе меняет данные ниче не нарушая.

При использовании репликации любые изменения значений первичных ключей ведет к НАРУШЕНИЯМ в целостности данных с практической НЕВОЗМОЖНОСТЬЮ разрешения конфликтов и ИСПРАВЛЕНИЯ ошибок - ошибка начинает РЕПЛИЦИРОВАТЬСЯ!
Если Вы с этим не согласны, это принуждает усомнится в Вашей квалификации.
vadiminfosphinx_mvВы забыли одну ма-а-аленькую нюансину...
Ссылочная целостность может быть задекларированной, а может быть реализована в программной логике...
И все каскадные радости идут в горы...
Не говоря уже об ограничениях каскадных операций на разных платформах...

Ну уж извините. В гору пойдет проектировщик. Мы здесь вроде и обсуждаем, чтобы снизить подобные риски.

Самый простой способ снижения рисков нарушения целостности данных - запрет пользователю ЛЮБЫМ способом изменять значения первичных ключей...
У Вас есть в этом сомнения?
vadiminfosphinx_mvПоследняя физически вставленная запись при серверном автоинкременте определяется как запись с максимальным значением ключа.

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

"Импосибл мистер Карабасофф" (с)
Автоинкремент на то и автоинкремент, что любое следующее значение должно быть больше предыдущего.
А то, что Вы описываете - это все что угодно, но с автоинкрементом даже не сидело на одной поляне!
vadiminfoВпрочем, я раньше думал что последняя вставленная запись может иметь значение для админов разработчиков: в предметной области не понятия вставка записей. Есть сущности и может иметь значение последие созданные. Админам же и разработчикам предпочтительное получать свою инфу не оказывая влияния на МД. Например, с помощью аудита.

Во-первых,в ЛЮБОЙ предметной области ЕСТЬ понятие вставки записей - иначе откуда данные попадут в систему.
Во-вторых, в ЛЮБОЙ "транзакционной" системе (образно - некоторая последовательность операций) ЕСТЬ понятие ОЧЕРЕДЬ, т.е. существует понятие "первый" и "последний". Отдельно в разрезе создания и обработки... И аудит к этому как бы "даже близко не стояло" - у него задача категорически другая...
vadiminfosphinx_mvВообще-то, некоторая выборка в которой участвует значение суррогатного ключа справочника НЕ перестает быть выборкой по значению суррогата... Если некто пишет некоторый запрос и НЕ представляет КАКОЙ результат он хочет получить - это несколько в стороне от обсуждаемого вопроса...

Не в стороне. Совсем не в стороне. Поскоку там пояснялось про особенности юзания суррогата. Вы же его вставили в запрос по значеню для сортировки. Пришел другой разработчик. Увидел в табле суррогаты. Если он не знал об особенностях юзания их в Вашей БД, то взял да их, так что то что в Вашем запросе было вставлено раньше теперь окажется позже. Ну действительно, термин "суррогат" означает, что его конкрентные значения не влияют на инфу в БД

Если другой разработчик НЕ разобравшись в системе начинает делать запросы к ней и получает результаты которые НЕВЕРНО интерпретирует - (ОЧЕНЬ) мягко говоря, КТО ЕМУ ДОКТОР???
И, действительно, главное преимущество суррогатов - ОНИ НЕ ВЛИЯЮТ НА ИНФОРМАЦИЮ В БД!
Они обеспечивают идентификацию записей и контролируют ссылочную целостность.
vadiminfoВот если бы у колнки было наименование SORT или Дата, и он бы их понял, то его бы спросили потом: "А чего же Вы хотели, молодой человек?" Раз поле SORT то по нему что-то отсартировано. А суррогат - главное чтобы ОЦ были не нарушены: меняй если надо на здоровье.

Круть немеряная! По названию колонки определять его назначение! А я грешным делом (даже не знаю почему) полагал, что об этом надо читать в документации на информационную систему...
Возник ОЧЕНЬ нескромный вопрос... Вы точно уверены, что проектирование БД - это Ваша сфера деятельности?
vadiminfosphinx_mvДля GUID с сетевой платой формируется на основе MAC-адреса... Ну, так вот... Уникальные MAC-адреса бывают... Но только НЕ в этой вселенной... Специально в подтверждение этому существует возможность а) "ручками" перебить MAC-адрес и б) склонировать его с другого интерфейса... Соответственно, шанс на получение дублированного GUID не очень большой, но заявлять об абсолютной его уникальности во вселенной - не "круто"...
В ООМД такие идетификаторы присваиватся системой объектам. И, вроде, они декларируют уникальность во вселенной. РМДшники им ответили на это GUID. Вот я и подумал. Впрочем не вникал.

Надо не думать... Надо знать... И вникать...
То, что ООМД везде где ни попадя используют GUID - это ОГРАНИЧЕНИЕ, связаное с невозможностью единообразного получения идентификаторов на разных платформах. Для GUID сделано допущение, что оно "в-общем случае" уникально и сравнительно просто генерируется - вот поэтому и применяется...
vadiminfoВ любом случае по сравнению с инкрементом, который совсем не уникален за переделами таблы, большая разница в плане силы идентификации. Т.е. преимущества GUID в этом плане есть как ни крути.
В рамках ЛЮБОЙ информационной системы НИКТО и НИКОГДА НЕ МОЖЕТ запретить использование "СКВОЗНОГО" АВТИНКРЕМЕНТА для идентификации ЛЮБЫХ (вплоть до ВСЕХ) объектов системы... А на тему "абсолютной уникальности" GUID уже писалось...

vadiminfosphinx_mvА теперь вопрос на засыпку - ЧТО есть суть страхового номера?
Пусть меня отшлепает тапком первый, кто внятно докажет, что это НЕ суррогат!
Естественный ключи!.. Естественные ключи!.. А как присмотришься по-внимательнее - СУРРОГАТЫ! ВСЕГДА И ВЕЗДЕ!

В БД суррогатный - тот которого нет в предметной области (ПО) (т.е. не представляет информационного интереса для юзеров), а есть тока в энтой БД. Страховой номер усилиями ПФ РФ является свойством персон РФ. Его, к примеру, операторы могут сравнить с докуметами, которые приносят пиплы при приеме на работу. Его могут затребовать заинтересованные лица.

Это ничего, что вы ОГРАНИЧИЛИ возможности Вашей информационной системы ТОЛЬКО гражданами РФ?
Приеду я в РФ - ну, и какой номер Вы нарисуете в вашем "естественном ключе"?
Даже номер удостоверяющего документа я могу ОФИЦИАЛЬНО сменить в течение нескольких часов - утром написать заявление, вечером получить новые...
vadiminfosphinx_mvСортировка и поиск - суть, основные алгоритмы при обработке данных...
Читайте первоисточники - они, как бы, рулес...

РМД предполагает декларативную систему запросов. Т.е. эта МД забила на скока могла на алгоритмы обработки данных на уровне пректировщика БД на логическом уровне. Ну это как бы одно из ее важных достоинств. Не знау как Вы это не увидели в первоисточниках.

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

Ничего. Ить суррогатность не равна инкременту. И кстати, ошибки ввода это траблы юзеров. А вот ежели он ошибок не делал и ввел дубли, то это, скорей всего, траблы разработчика. Проверять то правильность ввода юзер обязан, а вот искать дубли в БД нет. Я сталкивался с примером повторного ввода пачек из 200 инд сведений в одной такой БД.

Не надо все валить на бедных юзеров - им ПОЛОЖЕНО ошибаться.
А вот то, что некоторая информационная система НЕ отреагировала на появившиеся дубли - признак того, что кое-кто слишком доверяет теориям жидкого вакуума...
vadiminfosphinx_mvВ результате операторской ошибки НЕВЕРНОЕ значение иденитификатора начинает произвольным образом разгуливать по информационной системе. Кстати, некто Сидоров ЛЕГКО И НЕПРИНУЖДЕННО зарегистрировался в системе дважды... А то и трижды... В результате АНАЛОГИЧНОЙ ошибки...

Я говорю о достоинствах и недостаках. Eсли юзер не ошибся, он не наберт Сидорова дважды. А с сурогатом то наберет. Этого достаточно, чтобы зафиксировать преимущество естественного.
Т.е. он в этом суррогат явно хуже. Тока и всего.

Если пользователь ОШИБСЯ при вводе значения первичного ключа - последствия этой ошибки на порядки тяжелее, чем при использовании суррогатов.
Пример, как у меня в течение единиц часов меняется номер удостоверяющего документа (с учетом отсутствия у меня страхового номера) приводит к тому, что даже ПРАВИЛЬНО введенные оператором данные ПЕРЕСТАЮТ соответствовать реальной действительности.
vadiminfosphinx_mvА не надо аппелировать к тупому оптимизатору запросов...
Любые операции над целочисленными данными выполняются ЭФФЕКТИВНЕЕ, чем операции над их строковым представлением.
ЭТОГО достаточно - естественные ключи (практически) НИКОГДА не могут быть представлены как ЧИСЛО.

Ну, может быть, не тупее нас с Вами этот оптимизатор.
Кроме того, ЭФФЕКТИВНЕЕ это одно, а какой буит выигрыш в каждом конкретном случае на практике - другое. Опять же колнка предназначенная для соритировки, может быть числовой, если что.

Ура!! Даешь еще одно поле для пользовательского ввода и широчайшего простора для операторских ошибок!
vadiminfosphinx_mvВы НЕ представляете особенности функционирования АВТОИНКРЕМЕНТНОГО поля!
НИКОГДА (в штатной ситуации!) НЕЛЬЗЯ ВСТАВИТЬ в такой ключ значение, которое меньше любого ранее введенного!
Соответственно, в следствии этой ПРОСТУЮ особенности автоинкрементного ключа ВСЕГДА есть возможность определения ПОРЯДКА ВСТАВКИ записей в таблицу.

Да ладно. Инкрементость суррогатных ключей вовсе не предазначалась для определения ПОРЯДКА, а тока для неповторяемости. Есть две тразакции. В первой сгенрилось 101 для записи таблы, во второй 100. Первую закоммитили. А вторую закомиитили через пол час. Т.е. 100 оказалась позжее 101, а может и 200, что за эти пол часа кто-то налабал.

Проблема длинных пользовательских транзакций и вызываемых ими проблемах - НЕ проблема суррогатов.
Допустил проектировщик возможность таких ситуации - это КОНКРЕТНАЯ особенность реализации КОНКРЕТНОЙ информационной системы. И это ВСЕГО лишь означает, что в ДАННОЙ КОНКРЕТНОЙ реализации порядок НЕ РАБОТАЕТ.
vadiminfosphinx_mvПри использовании репликации любые изменения значений первичных ключей ведет к НАРУШЕНИЯМ в целостности данных с практической НЕВОЗМОЖНОСТЬЮ разрешения конфликтов и ИСПРАВЛЕНИЯ ошибок - ошибка начинает РЕПЛИЦИРОВАТЬСЯ!

Если при каких-то видах изменеий в конкретной СУБД данных возникают сложности, что имеет место, то не факт, что это не буит устранено в других версиях.

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

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

Изменения первичных ключей не желательны не только в Oracle, но и в ЛЮБОЙ информационной системе, построенной на ЛЮБОЙ другой реляционной платформе.
vadiminfosphinx_mvСамый простой способ снижения рисков нарушения целостности данных - запрет пользователю ЛЮБЫМ способом изменять значения первичных ключей...
У Вас есть в этом сомнения?

У меня во всем есть сомнения.
Изменение равно удалению и добавлению. Вот автоинкремент для того же объекта реального мира и поменялся.
Возможно, ОЦ и вообще не нарушатся при этом. А вот запросы со значениями суррогатов могут вполне показать не то шо надо.

АФИГЕТЬ!И где такую траву продают? Дайте две!!!
И вы всегда вместо обновления данных сначала удаляете, а потом добавляете новые? А че - оно же ж "равно"!!!
vadiminfosphinx_mvВо-первых,в ЛЮБОЙ предметной области ЕСТЬ понятие вставки записей - иначе откуда данные попадут в систему.

Предметная область - часть реального мира, информация о котором нас интересует. А записи и встаки это часть виртального мира в БД. Да и БД типа сущесвуют не записеориентированные МД. Например, ООБД к таковым, вроде, не относят. Т.е. не во всех и БД есть записи, а не тока в предметной области.

А если я заменю операцию "вставки записей", имеющую смысл в реляционной модели, на операцию "вставки объекта", которые актуальны для ООБД - ЭТО СИЛЬНО изменит смысл соответствующей операции?
Или представить запись таблицы в виде объекта - это действительно так сложно???
vadiminfosphinx_mvИ аудит к этому как бы "даже близко не стояло" - у него задача категорически другая...

Что у Вас скрывается по "этим" я не возьмусь угадать с уверенностью. Но , к последним внесенным записям в таблу аудит может иметь категорическое отношение, если админу нуно отслеживать последние внесенные записи. Ауит разными аспектами "внесения" записей может интересоваться (как впрочем и обновления и удаления).

Ну, да... Ну, да...
Берем огроменную пушку... И стреляем по малюсеньким воробьям... И снаряды чтобы были с ядерным зарядом...
vadiminfosphinx_mvИ, действительно, главное преимущество суррогатов - ОНИ НЕ ВЛИЯЮТ НА ИНФОРМАЦИЮ В БД!

Во це да.
Но у Вас то они влияют: их значения в сортировке. Извинит, если это не влияние, то что? Изменить их значение, получите другой ответ запроса. Это не влияние на информацию, по Вашему.

Подмена понятий!
Наличие в модели данных суррогатных ключей никак НЕ влияет на информацию, которую хранит модель.
А Вы целенаправленно МЕНЯЕТЕ - ручками! - информацию в ключе и тут же предъявляете претензии к суррогату!
НЕ СЕРЬЕЗНО...
И НЕПРОФЕССИОНАЛЬНО!
vadiminfosphinx_mvОни обеспечивают идентификацию записей и контролируют ссылочную целостность.

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

Вас никто не заставляет использовать суррогаты как-то еще, кроме способов, разрешенных Вам религией...
Но и Вам не след запрещать кому-либо использовать имеющиеся возможностии так, как им хочется.
vadiminfosphinx_mvКруть немеряная! По названию колонки определять его назначение! А я грешным делом (даже не знаю почему) полагал, что об этом надо читать в документации на информационную систему...

Погодите. Попробую угадать. У Вас вместо типа имени колонки "Номер телефона", скорее всего там имя типа A12567? А смысл того что скрывается за A12567 в доке нуно искать? Я хде-то это уже слышал.
Хороша МД. Ну что же, одно из достоинств РМД - простая интепритация данных, возможно, идет в гору у Вас там.

Срочно меняете хрустальный шар - он у вас испортился...
И повторно пройдите курсы - новые версии требуют переэкзаменовки...
vadiminfosphinx_mvВозник ОЧЕНЬ нескромный вопрос... Вы точно уверены, что проектирование БД - это Ваша сфера деятельности?

Да уж Вам не позавидуешь в плане не скромности: ить таким вопросом Вы претендуете на то, что в то что это Ваша сфера усомниться незя. Что безусловно не ОЧЕНЬ скромно.

Не моя, но к сожалению, мне приходится копаться в этом д%^%&.
vadiminfoЯ не в чем не уверен. В том числе и в том что моя сфера деятельности.
Не знаю, правда, какое это отношение имеет к достоинствам и недостаткам суррогатных инкрементных ключей.

Самое прямое...
Начиная с того, что любое допущение изменения значений ПК набивает шишки на самом первом проекте БД...
И заканчивая умениями не совсем стандартного использования некоторых имеющихся возможностей...
vadiminfosphinx_mvНадо не думать... Надо знать... И вникать...

Да Вам не в сфере проектирования каких-то там БД тусить. Вам ба лозунги для митингов проектировать. Цены б Вам, может быть, не было.

Выше Вашего "харекришна" (как в этом обсуждении) мне, к сожалению, не прогнуться...
vadiminfosphinx_mvВ рамках ЛЮБОЙ информационной системы НИКТО и НИКОГДА НЕ МОЖЕТ запретить использование "СКВОЗНОГО" АВТИНКРЕМЕНТА для идентификации ЛЮБЫХ (вплоть до ВСЕХ) объектов системы...
Ну ну. Нет конечно в мультимастер репликации (равноправная репликация в Оракле) для двух узлов мне приходлось за счет разной четности на узлах инкрементов добиваться типа усиления силы идентификации для копий.

"Нормальные герои всегда идут в обход" (с)
Оказывается, это так сложно в оракле создать составной ключ!
vadiminfoНо в Рамках ЛЮБОЙ ИС гемориться с усилением силы идентификации инкрементов, надеюсь, НИКТО и НИКОГДА НЕ БУДЕТ заставлять.

Реплики ЛЕГКО сводятся (и разводятся) с использованием составных ключей.
Более того - этим способом ЛЕГКО сливаются даже данные разных платформ - в рамках обобщенной информационной системы...
vadiminfosphinx_mv А на тему "абсолютной уникальности" GUID уже писалось
...
Ну достаточно для фиксация наличия хоть одного преимущества над инкрементными и этого:
sphinx_mvДля GUID сделано допущение, что оно "в-общем случае" уникально и сравнительно просто генерируется...
.
Я правильно понимаю, что внетранзакционное нечто типа "i++" для вас - это архисложно и является верхом программистической мысли?

vadiminfosphinx_mvЭто ничего, что вы ОГРАНИЧИЛИ возможности Вашей информационной системы ТОЛЬКО гражданами РФ?
Приеду я в РФ - ну, и какой номер Вы нарисуете в вашем "естественном ключе"?

Ничего.
Был просто пример показывающий достинства естественных ключей. И только.

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

Это - демонстрация уровня квалификации аналитиков...
Первый же тест "не глядя" - и вся система в ауте!
vadiminfoА Вы что суррогатом зарешаете всю идентификацию глобально? А они придумывают там всякие биометрические. Бабло тратят. Им ба к Вам обратиться.

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

Вот у меня, например, как раз паспорт с биометрией...
Но к моему ИДЕНТИФИКАТОРУ в системе документирования соотносится сугубо как дополнительный (и даже не-ключевой) атрибут...
Впрочем, номера ВСЕХ моих документов к идентификатору - точно таким же образом...
vadiminfosphinx_mvВаша "сферическая информационная в система в вакууме" может сколько угодно забивать чего угодно и на что угодно...
Вот только в "реальном" мире "забивать" на некоторые вещи крайне не рекомендуется...

Я про мои системы вообще ниче не говорил.

Я бы тоже не особо афишировал системы, которые проваливают первые же тесты...
vadiminfoТам про РМД была речь. Вам мож луче иерахические подойдут? Там есть и упорядоченности записей на уровне МД и алгоритмы - там навигационный доступ к данным.

А еще какие умные слова вы знаете?
vadiminfoЛано, все чисто митинговое буду опускать далее.

Никто и не заставляет... Только почему вы решили что Ваш митингизм - лучше?
vadiminfosphinx_mvА вот то, что некоторая информационная система НЕ отреагировала на появившиеся дубли - признак того, что кое-кто слишком доверяет теориям жидкого вакуума...

Ну вот и хорошо: там хде суррогат не отриагирует, естесвенный отреагирует(када юзер правильно заносит). Када не правильно суррогат все равно не поможет.

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


Теперь КОНКРЕТНАЯ?
Ну так пример и был приведен против ЛЮБОЙ системы. Ить Вы вроде инкрементный суррогат как самое надежное продвигали. А теперь согласны что может НЕ РАБОТАТЬ? Ну прогресс есть.

"Дядя! Вы - ДУРАК?" (с)

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

vadiminfosphinx_mvИ вы всегда вместо обновления данных сначала удаляете, а потом добавляете новые? А че - оно же ж "равно"!!!

Ну Вы ловкач.
Вы же хотели запретить пользователю менять первичный ключ. И спрашивали про мои сомнения на этот счет.
Я типа сказал, Вам по сути, что удаление и вставка помогут ему преодолеть такие запреты в случае суррогата. Что тада Вам и удаление и вставку придется ограничивать как-то. Тока и всего.

Я, может, и ловкач... Но шулер гораздо меньшего уровня, чем Вы.
При этом элементарных познания в том, что в ЛЮБОЙ информационной системе ОБЯЗАНЫ существовать ограничения на вставку, обновление и удаление данных, Вам, к сожалению, не известно...

Во избежание Ваших инсинуаций - точно такие же ограничения должны быть и при использовании естественных ключей...
И не только в реляционных моделях данных...
vadiminfosphinx_mvПодмена понятий!
Наличие в модели данных суррогатных ключей никак НЕ влияет на информацию, которую хранит модель.
А Вы целенаправленно МЕНЯЕТЕ - ручками! - информацию в ключе и тут же предъявляете претензии к суррогату!
НЕ СЕРЬЕЗНО...
И НЕПРОФЕССИОНАЛЬНО!

Даже если я не меняю ничего, это она у Вас влияет, так как значение в запросе. Изменение, тока для тестирования что влиет.
Вот если бы поменяли и инфа в запросах не изменилась, то не влияет.
Чет-то Вы как-то очень "ПРОФЕССИОНАЛЬНО" понимете ответы, на Ваши утверждения.

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

Реплика это копирование - физика. Структура и ОЦ - логика БД.
Внесение изменений в логику ради физики, возможно, существенный недостаток. Это не совершество данной версии СУБД.
СУБД как бы должна обеспечить отделение физического от логического.

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

Т.е независимость изменения значений генераторов, последовательностей, идентити и прочих аналогов автоинкрементов от контекста транзакции - для Вас это откровение? У, как все запущено...

Кстати, попытки "пугать ассемблером" незнакомых людей выглядят весьма нижеплинтусово...
vadiminfoПо любасу попытки превратить инкремент в GUID, скорее всего плохая идея, раз на ея не пошли производители СУБД.
Инкремет свои преимущества перед GUID начнет утрачивать, а всех достоинств так и не достигнет, скорей всего.
Слов много, смысла - ноль...

vadiminfosphinx_mvЧто же это за достоинства такие, которые заваливают первый же тест системы?

В том что Сидорова не занесли дважды набрав номер, если юзер все правильно введет.

Повторяю для тугодумов: есть системы хде нет никого без страховых в РФ.

Простой вопрос, требующий точно такого же простого ответа...
ФМС всех не-граждан (честных, которые по разрешению и т.п.) тоже в ПФ всегда регистрировало?
А если нет - откуда у этих трудовых мигрантов пенсионный номер?
Ну, а сколько их миллионов на территории РФ, мусьё, в курсях?

Да и этот пенсионный номер, котрый как бы "главный идентификатор в правильных системах", не является СТРОГО ОБЯЗАТЕЛЬНЫМ... Вот такой не-обязательный первичный ключ... Который, типа, идентифицирует данные в системе...
vadiminfoТам ваш тест, не проканает: нет страхового идете лесом, вас не допустят, в систему не занесут на том предприятии.

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

Поможет не позволить Сидорова занести многократно?

Поможет!
Альтернативные ключи - такому гуру, как Вы, это должно хоть о чем-нибудь говорить...
Но судя по всему, какой гуру, такие и познания теории...
vadiminfoА народ заносил и по 100 и более раз. Доводилось сталкиваться в некоторых таких продвинутых системах, написанных профи.
Правда не в БД, а драйверах.

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

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

А Вы не ДУРАК?

Или дурочку запускаете?

Вы бы беспокоились за собственную дурочку, которая уже и на уровень дебила не дотягивает...
vadiminfosphinx_mv
Там и было, что "перестает работать ...порядок ввода данных на основе значения сурогата!"
Вы же суррогат для этого учета юзали. Разхваливали как он находит паоследние. А я привел пример, када это не работает. А теперь Вы хотите мне приписать, что якобы я говорил, что суррогат не работает?
Ловко.

Ваш столик в детском саду!.. С точно такими же "профи"...

Вмешиваетесь в работу системы - и жалуетесь, что "система не работает правильно"?
Хотелось бы посмотреть как поле "SORT", за необходимость которого, не буду тыкать пальцем, кое-кто брызгал слюнями на монитор после изменения порядка значений будет продолжать "правильно" работать...
vadiminfosphinx_mvЯ, может, и ловкач... Но шулер гораздо меньшего уровня, чем Вы.
При этом элементарных познания в том, что в ЛЮБОЙ информационной системе ОБЯЗАНЫ существовать ограничения на вставку, обновление и удаление данных, Вам, к сожалению, не известно...

Вы опять дурку запуститли? Мол де я был против ограничений вообще а Вы мол за?

А в Ваших системах и НЕ существует никаких ограничений!..
Про альтернативные ключи Вам не известно...
Просле этого то у Вас пользователь когда захочет удалит что захочет...
То у Вас по 100 раз одно и тоже в систему попадает...
То вдруг "чего-то в природе не бывает"...
И т.д...
vadiminfoВы хотели запретить изменение ПК суррогатного. Забыли что ли? Я поставил под сомнение идею.

Только "профи" Вашего "уровня" может поставить под сомнение идею об отсутствии необходимости и бессмысленности изменения суррогатных ключей, а про опасность изменения первичных ключей слыхом не слыхивать, видом не видывать...
Только "профи" Вашего "уровня" может ставить под сомнение идею, что если некоторе действие а) не нужно, б) бессмыслено и в) ОПАСНО - это действие ЦЕЛЕСООБРАЗНО ЗАПРЕЩАТЬ!!!
Если некоторым "инициативным" во всем этом чего-то не понятно - это проблема их персональной "гениальности"...
vadiminfoРасжевываю для особо одаренных:

С Вашей-то личной "одаренностью" заниматься такими теориями чревато...
Что и наблюдается (но не Вами!) по уровню проблем в Ваших системах...
vadiminfoВы запретили обновлять суроогатный ключ. Юзер удалением и всавкой может обойти это ограничение. Стало быть Вы буите контролировать ввод и удаление.
Юзер удалил запись про Сидорова. Вы как это ограничили? Запомнили то шо было? Всю запись?
Юзер опять вставил то шо удалил, того же Сидорова. Вы как это ограничили? Сравнили с тем шо было и все отменили, вернули то шо было? Если ниче не сделали, то юзер заменил суррогат: он увеличился.
А юзер возьми и удали пол БД, а всавлять обратно начсал через неделю. За это время и Сидоров сменил фамилие. Че делаете?
Иначе получится что юзер поменял суррогат.

Даже дебил давно бы понял, что ничего такого, с чем бы Вы НЕ столкнулись при использованием ЕСТЕСТВЕННЫХ ключей, Вы НЕ описали - ситуация повторится с точностью до нажатой пользователем клавиши на клавиатуре!
vadiminfoА не про какие-то ограничения удаления и вставки вообще была речь. Нет у Оракла есть Флэшбэк. А юзер возьми и удали пол БД, а всавлять обратно начсал через неделю.

С детскими эротическими фантазиями Вам на другой сайт...
vadiminfosphinx_mvАле! Гараж!
ВЫ! ИЗМЕНИЛИ! ДАННЫЕ!
И после этого Вы имеете наглость предъявлять претензии к информационной системе в том, что "данные поменялись"?!
В том время, как претензии по этому поводу следует предъявлять непосредственно к ВАМ - как к персоне, выполнившей это конкретное действие над данными системы!!!


Скока праведного негодования.
А я ить предупреждал(С). Нечего было суррогаты условиях отбора и сортировках данных юзать. Ниче бы и не было ба с этими запросами после замены суррогатов.

Замечательно дебильный коммент...
Принципиальная разница между ПК на суррогатах и на естественных ключах ОТСУТСВУЕТ!
Поведение системы при изменении значения суррогатного первичногь ключа или естественного первичного ключа - АБСОЛЮТНО ОДИНАКОВО.
А! Нет... естественные ключи "вывихнут мозги" информационной системе на исправлении ссылочной целостности с гораздо большим эффектом, чем суррогаты, которые к тому же "простым смертным" пользователям (обычно!) не доступны из приложения...
В отличие от естественных ключей, которые (обычно!) доступны для редактирования...
vadiminfosphinx_mvСдается мне, что это не проблема конкретной версии СУБД, а проблема Вашей реализации...
Использовать четность/нечетность вместо указания границ значений первичного ключа на основе последовательности - такой повод позаявлять об умении решать простые задачи наиболее сложными способами...

Способ рекомендованный руководством по репликации в Оракле. Альтернатива GUID. Но у них канечно тоже квалификация по сравнению с Вами никакая. Им ба у Вас поучиться жить.

С учетом того, что в Oracle нет многих элементарнейших вещей, которые есть на других платформах, иму действительно ЕСТЬ куда расти... А вот Вас до него допускать не стоит - чревато...
vadiminfoГраницы указывать? Заранеее посчитать скока там буит значений в таблах? Во всех 150? А ить проектировщики потом будут еще таблы добавлять.
Это проще чем тупо поставить в той же последовательности на обной строне четное на другой нечетное и инкремент 2 и забыть об этом раз и на вседа?

Я же говорю - квалификация у Вас слабовата... Вместо того, чтобы сделать составной ключ с кодом реплики (заполняемым по дефолту) устроить танцы с бубном... Универсальное решение, которое позволяет единоообразно "слить" не только Oracle с Oracle'ом, но и многие более других платформы между собой...
vadiminfoДа уж, спасибо не нуно Ваших советов, плиз.
Да за ради бога!
Я знаю, что некоторые "одаренные" вместо того, чтобы один раз, но хорошо написать, будут специально использовать в своих системах потенциально опасные решения, чтобы продолжать получать незаработанный бутерброд с маслом и колбасой на сопровождении...

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

Вообще-то это был пример "хоть одного достоинства" естественного ключа перед суррогатным. На ваш вопрос про таковой.

Комбинация атрибутов, НЕ способная идентифицировать реляционное отношение, на роль КЛЮЧА рассматриваться в реляционной модели НЕ может... Соответственно, РЕАЛЬНОГО примера естественного ключа с Вашей стороны так и НЕ наблюдалось.
Ну, а по причине, что мусьё НЕ умеет определять ключи при реализации информационных ситем, куда он может пойти со своим мнением, он может выбрать самостоятельно.
vadiminfoВы теперь отрицаете не само достоинство, а отсутсвие естественного ключа по сути. Так как первичным моно объявить любой, то естественных нет получается.

Пример естественного ключа, которые может РЕАЛЬНО идентифицировать отношение - ГДЕ ОН? "Имя сестра! ИМЯ!!!" (с)
Как-то не наблюдается... Соответственно, с Вашими претензиями Вам прямая дорога в пешую прогулку с эротическим уклоном...
vadiminfoОжидалось, что Вы все же буите отрицать само достоинство. Ну ожидания не оправдались.

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

НИЧЕГО этот Ваш "идентификатор" НЕ идентифицирует!
Использовать атрибут, который даже НЕ является ОБЩИМ для однотипных объектов, в качестве ИДЕНТИФИКАТОРА - ЭТО ПЕРЛ!!!
Потому в пролете Ваше "первое попавшееся" неизвестно что...
sphinx_mvПоможет!
Альтернативные ключи - такому гуру, как Вы, это должно хоть о чем-нибудь говорить...

vadiminfoТак это не он помог, а альтенативный естественный ключ. Замечу, на всякий случай, если Вы сами еще не поняли, что естественный в подолбной помощи не нуждается - это преимущество (Вам похоже нуно разжевавать все).

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

Ну, НЕ УДОВЛЕТВОРЯЕТ Ваш ключ минимальным требованиям для ПЕРВИЧНОГО КЛЮЧА.
НЕЛЬЗЯ сделать первичным ключом НЕОБЯЗАТЕЛЬНОЕ поле! Не верите? Читайте доки - они рулез (с)
Атрибут, значение которого НЕОБЯЗАТЕЛЬНО и ОТСУТСТВУЕТ у большого количества объектов даже просто ключом должно быть стыдно назвать...
vadiminfoДалее явное ответы по типу я про Ерему, а Вы про Фому.

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

У мусье склероз? Не он ли предлагал использовать какие-то "левые" поля для сортировки? а, ну-да - это же "его идея" и "ему - можно"... И, вполне естественно, что "никто и никогда" именно ТЕ поля менять ни разу не будет... Ага...
А может, мусье настолько ТУП, что НЕ понимает, что ЛЮБЫЕ изменения ЛЮБОГО поля МЕНЯЮТ порядок записей ПРИ ВЫБОРКЕ с СОРТИРОВКОЙ по этому полю? Или, может, мусье просто не знаком с особенностями использования и результатами применения "ORDER BY" в выборках, что в-принципе, ожидаемо?..
Именно ПОЛЬЗОВАТЕЛЬ несет ответственность за СВОИ действия, которые к нарушениям модели никаким боком не относятся! Потому что пользователь МОЖЕТ поменять ЛЮБОЙ порядок логического следования данных!
Может, Вы еще и про то, что порядок выборок ляпните, что это нонсенс? - с Вас станется...

Неужто, мусье НЕ понимает, что ЕСТЬ множество задач, круг которых может оказаться ГОРАЗДО ШИРЕ пределов его квалификации и опыта, и для которых ИМЕННО ТАКОЙ подход является САМЫМ простым и САМЫМ надежным способом решения вполне конкретной поставленной задачи?
Например, что-нибудь про такую, сравнительно небольшую группу задач, связанную с обработкой FIFO или LIFO мусье слышал?
И как же мусье будет решать такие задачи? Или, таки, не будет в следствие НЕДОСТАТКА квалификации? Ну, так и туда тому мусье и дорога...

Ладно, проявлю "гуманизьм"...
Объясню КАК можно решить подобные задачу, и почему нежелательно использовать не-автоинкрементные или модифицируемые идентификаторы (для конкретно этого круга задач)...
Сортировка по времени - теоретически годится, но за счет ограничения точности типа данных "дата/время" может получиться, что в ОДИН момент времени пришло несколько записей... Следовательно, результат выборки с сортировкой по времени МОЖЕТ НАРУШАТЬ физический порядок поступления записей...
GUID ВООБЩЕ неприменим в целях сортировки - т.е. ПРИНЦИПИАЛЬНО!.. Почему - для самостоятельного домашнего изучения.
И только автоинкремент (с ОБЯЗАТЕЛЬНЫМ запретом доступа пользователя на редактирование ключа) обеспечивает САМЫЙ правильный порядок при обработке такой вот вполне конкретной задачи...
Вот такие "простейшие" соображения для ТАКИХ задач.
vadiminfoНу про попытку запретить Вами суррогатов совсем чет-то стало не ясно. Вы наговорили про что угодно, тока не про то, что спрашивалось об этом запрете.

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

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

vadiminfosphinx_mvКомбинация атрибутов, НЕ способная идентифицировать реляционное отношение, на роль КЛЮЧА рассматриваться в реляционной модели НЕ может... Соответственно, РЕАЛЬНОГО примера естественного ключа с Вашей стороны так и НЕ наблюдалось.

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


Приходит 10 "Ивановых Иванов Ивановичей", НЕ имеющих пенсионного номера - КАК их идентифицировать по ЭТОМУ номеру?
Даже комбинация с другими атрибутами для предложенного Вами варианта никогда НЕ будет гарантированно уникальна!!
vadiminfo2. Вы сами рассказав про помощь альтернативного, признали существование естественных первичных ключей. Или он не естесвенный, тада он опять суррогат и не поможет. Или он не ключ вообще по Вашему? Не реальный? Ну так даже не реальный естественный имеет преимущество, про которое шла речь.

Не надо приписывать мне то, чего Вы НЕ понимаете...
Есть НЕКОТОРЫЕ "природные" атрибуты, значения которых при их ОБЯЗАТЕЛЬНОМ наличии МОГУТ считаться уникальными с НЕКОТОРОЙ, даже ОЧЕНЬ высокой долей достоверности.
Еще раз специально для ВАС - НАЛИЧИЕ значений должно быть ОБЯЗАТЕЛЬНЫМ !
И при этом практически ЛЮБОЙ атрибут, который хоть как-то способен удовлетиворить этому условию по сути - СУРРОГАТ!
vadiminfo3. Суррогат тем более ниче не спосбен идентифицировать вне програмной среды: его там нет. Так че для демонстрации вышеоговоенного достоинсва достаточно, в которм было не про идентификацию.

Необязательный атрибут ТОЖЕ не может ничего идентифицировать - его НЕТ не только ВНЕ , но и ВНУТРИ программной среды...

И специально для некоторых строителей "детских песочниц" еще раз обращаю внимание: ЛЮБОЙ атрибут, который "в реальном мире" хоть как-то годится на роль "естественного ключа" внутри "детской песочницы", НА САМОМ деле за ее пределами является СУРРОГАТНЫМ ключем в системе, которая его эмитировала (для особо непонятливых - "выпустила").
Таким образом, это АВТОМАТИЧЕСКИ ОПРОВЕРГАЕТ тезис о невозможности существования суррогатов ЗА пределами информационной системы.
vadiminfo4. Если Вы не поняли до сих пор не поняли, это достоинство, кстати широко известное - на лекциях на 3 курсе обыкновенно читали, то могу выразить лишь недоумнение.

Теоретические познания о поведении сферических коней в жидком вакукме в реальной жизни мало применимы...
vadiminfoпропущено...

Вообще-то такой пример нужен для сравнения достоисвт естесвенных ключей между собой (какой луче Идетифицирует), либо с другими способами идентификации, но с сурогатом, который изначль может тока ВИРТУАЛЬНО, т.е. на РЕАЛЬНУЮ идентификацию прететендовал.

Однако, даже если бы перетендовал это было бы просто другое достоинство.

Достаточно уникальности для примера того достоинства естественных перед суррогатами.

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

Это Вы себя "подловили" на ПЛОХОМ Вашем примере - теперь юлите, как уж на раскаленной сковородке...

Альтернативный ключ - кандидат на ПК, но именно потому, что он ПЛОХОЙ кандидат он НЕ становится первичным ключом... Критериев непригодности - множество. Один из них - возможное отсутствие значения ключа для некоторых объектов, хотя для существующих значений у остальных объектов комбинация значений атрибутов ключа может являться уникальной...
В-общем, матчасть, батенька, матчасть...
vadiminfoпропущено...

Я уже довнно оценил, Вашу квалификацию, так что моно перестать на ней зацикливаться, тем более она не отменит того примера (иму по барабану квалификация).
Тем более он показавл, что чем шире круг, тем большая осторожность нужна с суррогата. И вообще, последний не обязан быть инкрементом в общем случае широте.

Теоретик, блин!..
Чем ШИРЕ круг решаемых задач, тем МЕНЬШЕ для них подходит использование естественных ключей в качестве первичных.
Студентам третьего курса об этом ЗАБЫВАЮТ рассказать, что не удивительно - лекции читаю точно такие же "теорЭтики"...
А потом люди жалуются - "у нас новый сервер тормозит на элементарных запросах"...

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

С учетом того, что ПК используется (в-основном) для связи между данными РАЗНЫХ таблиц, а сортировка (ОБЫЧНО) выполняется по полям, котоорые вообще могут не быть ключами - аргумент крайне слабый...

Ну, а существование задач, где автоинкрементный ПК вполне может удовлетворять требованиям использования в качестве "сортировочного", опровергать будет только "крайний теоретик"...
vadiminfoНеобходимость контроля свойств, которых нет у реалтьных объектов.

Какие свойства нужно контролировать? Уникальность?
Ну, так это задача сотвествующего констрейнта, которая ДОЛЖНА выполняться при ЛЮБОМ типе ключа - хоть сурогатном, хоть естественном...

Для естественрого ключа "ручками" придется проверить, а правильно ли введено значение, а не ошиблись ли в при вводе ранее введенного значения, которй конфликтует с вновь вводимым, а если ошибка в старом - пофиксить значение и поправить ВСЕ ссылки на него и т.д...
Для суррогата нужно просто взять следующее значение - гарантия, что оно уникально приближается к "десяти девяткам"...
Даже если у кого-то кривые руки поменяли последовательность - какое дело до этого самому механизму?
И это исправляется простой заменой на новое корректное значение генератора - и работай дальше.
Уникальные консрэйнты позволят проверить на уникальность ввод повторов, и в случае ошибки предстоит поправить максимум значения в 2 записях - непосредственно конфликтующие значения альтернативных ключей в новой и в старой записях.
И - уж в котрый раз обращаю внимание! - НИКАКИХ "танцев с бубнами" вокруг ссылок по всем дочерним таблицам!
vadiminfo2. Мой тот пример - о том что суррогаты не для этого и потому запрос не обязан давать правильный результат - использование не по назначеннию. Ить это така один пример. Где гарантии что не нашли другие.

Если такая возможность для данной конкретной системы ДОКУМЕНТИРОВАНА, если список ДОПУСТИМЫХ операций и ОГРАНИЧЕНИЯ действий в системе ОПИСАНЫ - НИКАКИХ использований "не по назначению" при использовании значения суррогатного ключа для сортировок НЕТ! Система работает В СУГУБО ДОКУМЕНТИРОВАННОМ режиме!
И это, кстати, тоже матчасть...
vadiminfo3. Ограничение суррогата инкрементными. Кто-то сеня написал запрос, а завтра пришел другой, ну такой же бескромистный сторонник но GUID.

Ну и пусть приходит!
Выкинуть пинком под зад идиота, который БЕЗ согласования со всеми потребителями и обслуживающими службами начнет самовольно менять способ генерации ПК даже в самой маленькой табличке корпоративной БД весом даже всего в пару сотен гигабайт обойдется значительно дешевле возможных потерь данных и функционала, к которым может привести эта замена.
vadiminfoНуно искать а нет для других. Юзание то не по назначению, которое сводится к обеспечинию уникальности.

В общем, предпочел бы не иметь дела с такими решения до последнего.

Ну, и как Вы идеальное FIFO или LIFO обеспечите без использования автоинкрементного суррогата?
Ни одно ДРУГОЕ решение НЕ позволяет обработать "реального первого" или "реального последнего" в "реальном" порядке последовательности...
vadiminfoпропущено...

Смущал ответ на то как помешать юзеру обойти этот запрет с помощью удаления записми и ввода ее по новой. Иначе какой-же это запрет?

GRANT и REVOKE - главные команды при раздаче прав пользователям...
REVOKE DELETE на таблицу - и ни один пользователь без GRANT DELETE никогда не сможет ничего из этой таблицы удалить.
Одна ПРОСТАЯ команда - а решает столько реальных и надуманых проблем!..
vadiminfoпропущено...

Ну на конец-то свою точку зрения, а не истину не допускающую сомнений.
С точкой зрения можно не соглашаться...
Но когда точка зрения совпадает с объективной реальностью, объективной реальности сугубо без разницы, согласен С НЕЙ кто-нибудь, или нет - она просто больно бьет по голове. И правильно, кстати, делает - особенно, если чужой опыт ничему не учит...

Рассматрим несложный и вполне обычный сценарий...
Большая БД разделена на несколько архивных разделов, каждый из которых периодически архивируется и удаляется...
Оставим за скобками множественность вариантов стратегий разделения и архивирования.. Отметим только, что в каждом из архивов в таблицах как минимум прописаны ссылки на значения ПК. И как только в "оперативной" БД поменяли значения ПК или удалили записи в мастер-таблицах, данные из архивов восстановлению практически НЕ ПОДЛЕЖАТ даже в случае крайней необходимости!

vadiminfosphinx_mvПриходит 10 "Ивановых Иванов Ивановичей", НЕ имеющих пенсионного номера - КАК их идентифицировать по ЭТОМУ номеру?
Даже комбинация с другими атрибутами для предложенного Вами варианта никогда НЕ будет гарантированно уникальна!!

Вы есче спросите как им будут в ПФ пенсию начислять, када придут на них индивидуальные сведения. В ИС страховой обязателен. Без него их не принимают в РФ. Заставят завести страховой, а потом приходить. Говорят, в РФ вообще всем собираются давать страховые с дества.

КОД, которого НЕТ "у всех", и когда он у них появится - неизвестно (и появится ли вообще), использовать как ИДЕНТИФИКАТОР - ПРИНЦИПИАЛЬНО НЕВОЗМОЖНО!!!
vadiminfosphinx_mvЧем ШИРЕ круг решаемых задач, тем МЕНЬШЕ для них подходит использование естественных ключей в качестве первичных.


В узком круге признаете использование естественных? Ну стало быть, то "хоть одно" достоинство у естесвенных есть, раз они сами есть.

Впрочем, Вы признали их использование, а не просто одно какое-то достоинство.


Существование чего-либо само по себе НЕ является ни достоинством, ни недостатком...
Достоинсто или недостаток могут быть определены ТОЛЬКО в сравнении ...
Но третьекурсники-теоретики об этом, естественно, не знают...
vadiminfosphinx_mvКакие свойства нужно контролировать? Уникальность?


Не уникальность, а конкрентные значения. Правильно ли там 5 или все все же должно быть 10 на самом деле.
Раз в запросе конкретные значения. Например, запрос показал непонятный результат.

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

Ну как же. Он предназначен для уникальности. Это типа СУБД поддерживает: не допускаются случаи дубля при любых сложных транзакциях. Остальное не по назначению в том смысле , что СУБД это специально не поддерживает, а не в смысле документации разработчика. Пример тот показал, что может быть неверный результат.

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

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

Чукчи-третьекурсники-теоретики читать по-русски не умеют?
ЛЮБОЕ, даже самое незначительное изменение функционала, ЛЮБОЙ системы НЕЛЬЗЯ выполнять БЕЗ учета ВСЕХ последствий!
vadiminfoМало ли. Мож к тому времени СУБД много полезных фич для GUID надыбает.

Ну, уж на третьем-то курсе теоретики могли бы и узнать, ПОЧЕМУ случайные последовательности в ПК плохо сказываются, как минимум, на производительности серверов БД...
vadiminfosphinx_mvНу, и как Вы идеальное FIFO или LIFO обеспечите без использования автоинкрементного суррогата?
Ни одно ДРУГОЕ решение НЕ позволяет обработать "реального первого" или "реального последнего" в "реальном" порядке последовательности...

На случай отсутсвия других решений в каких-то ситуациях, я и оставил - "до последнего". Вопрос, оптимальности достоинств и недостатков.

Есть КОНКРЕТНАЯ задача... Есть КОНКРЕТНОЕ решение - САМОЕ ЛУЧШЕЕ решение из ВСЕХ возможных...
На третьем курсе не учили, что "ЛУЧШЕЕ" == "обладающее оптимальным соотношением ДОСТОИНСТВ и НЕДОСТАТОКОВ по сравнению с прочими"?
vadiminfosphinx_mvGRANT и REVOKE - главные команды при раздаче прав пользователям...
REVOKE DELETE на таблицу - и ни один пользователь без GRANT DELETE никогда не сможет ничего из этой таблицы удалить.
Одна ПРОСТАЯ команда - а решает столько реальных и надуманых проблем!..

Т.е. ради запрета изменеия значения суррогата запретить удаление вообще. Возможно, это не адекватно: дороговато за запрет суррогата. Все таки удаление правомерная операция в БД в общем случае.

Третьекурсники-теоретики за деревьями леса не видят!
Что будет с Вашими "естественными" ключами, когда кто ни попадя начнет удалять записи - не расскажете?
Наверное, вряд ли - чтобы рассказать, надо иметь понятие... И как только зачеты и экзамены по предмету были сданы?!

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

То, что у ВАс такого "не было ни разу" - даже не подвергалось сомнению ДО того, как был приведен пример...
Держать пол-терабайта архивных данных на каждый год (из почти десятка лет) архивов в "рабочей" базе на активном сервере - лично мне как-то не особо нравится...
vadiminfoЗа скобками оставлять "за скобками множественность вариантов стратегий разделения и архивирования", скорей всего, не лучшее из лучшего.

Стратегий разделения на части БОЛЬШИХ табиц существует МНОЖЕСТВО! Способов РЕАЛИЗАЦИИ - еще больше!
И ни одна из них НЕ является "лучшей из лучших". При этом каждая их них МОЖЕТ оказаться наиболее приемлемая во вполне определенных условиях.
vadiminfoПолагаться на неизменность ПК не смотря ни накие меры при такой цене их изменения, по любасу, выглядит как слишком агрессивный подход.
Слишком "агресивный подход"?! Кому-то зачем-то нужно "полагаться"?! Ну, для "детских песочниц" - возможно...
Вот только в "больших системах" никто ни на что не должен "полагаться" и стратегия защиты данных обязана быть максимально "агрессивной" - это чрезвычайно сильно облегчает жизнь...

vadiminfosphinx_mv Существование чего-либо само по себе НЕ является ни достоинством, ни недостатком...
Достоинсто или недостаток могут быть определены ТОЛЬКО в сравнении ...
Но третьекурсники-теоретики об этом, естественно, не знают...

Ну если существут, но такое достоинство в силу каких-либо обстоятельств не очевидно, то можно проверить:

Создать две таблы. В одной номер, его страхового, прав, карточки или еще чего. Луче пороще, чтобы не ошибиться нри наборе. Ну и ждугие каки-нить атрибуты. Объявить номер первичным ключем. Втораю все тоже, но первичный ключ, суррогат.
Занести себя дважды в перву и вторую таблу.

А че только себя?
И че только два раза?
И почему только в две таблицы? Самое "счастье" начнется, когда пойдут ссылки (хотя бы одна) на любую из таблиц

Ограничиваемся следующими атрибутами:
- ФИО (для простоты);
- пенсионный номер;
- номер паспорта.

В первой таблице (А) первичный ключ - пенсионный номер, альтернативный - номер паспорта...
Во второй таблице (Б) добавляем суррогатный ключ (даже не принципиально автоинкремент, GUID или еще какой-нибудь) и два альтернативных ключа: 1) по пенсионному номеру и 2) по номеру паспорта...

Теперь начинаем "придумываем" примеры. Номера паспортов и пенсионные номера возьмем "с потолка"...

1) Иванов Иван Иванович, пенсионного номера нет (т.к. не обязательное поле), номер паспорта АА111 (условно)
2) Сидоров Сидор Сидорович, пенсионный номер 12345, паспорт ББ123
3) Петрова Марфа Семеновна, пенсионного номера нет, паспорт ВВ432 (было месяц назад)
4) Хлопушкина Варвара Петровна, пенсионный номер 56765, паспорт ВВ567
5) Петрова Марфа Семеновна (п.3) вышла замуж и сменила фамилию на Неизвестную, номер ее паспорта соответственно тоже изменился на ГГ567. В добавок она получила пенсионный номер 98754

Проводим "разбор полетов"...
В таблице А с пенсионным номером в качестве ПК:
- Не можем зарегистрировать данные по пп. 1 и 3...
- Не можем выявить, что ранее занесенный в систему п.3 сменила фамилию, поменяла документы и получила новый пенсионный номер.
Итого - в самом простом случае 2 разных варианта отказов; общее количество отказов - 3 из 5...

В таблице Б с суррогатным ПК:
- Повторение проблемы с п. 3 (как и для таблицы А)
Итого - 1 вариант отказа; общее количество отказов - 1 из 5...

Обе таблицы отработают попытку ввода повторяющегося пенсионного номера или номера паспорта.
Обе таблицы пропустят ввод ошибочного значения в пенсионном номере или в номере паспорта.

Для исправления неправильно введенного пенсионного номера для таблицы А необходимо провести каскадные изменения всех связанных подчиненных таблиц.

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

Исправления неверно введенного номера паспорта для обоих вариантов количество операций одинаково - изменение значения единственного поля "номер паспорта" для единственной записи...

Таким образом, на этом простом примере мы получили результат, по которому, во-первых, количество разных вариантов ошибок системы на естественных ключах БОЛЬШЕ, чем количество вариантов ошибок системы на суррогатных ключах, и, во-вторых, ошибки, возникающие при работе с суррогатными ключами НЕ ХУЖЕ (точно такие же и в тех же самых местах), чем в системе с естественными ключами.

Про коллизии естественных ключей - это к матчасти...

vadiminfosphinx_mvА вот не надо писать запросы, смысла которых Вы не понимаете - и не будет непонятных Вам результатов!

Понятные запросы в силу, например, потери информации в БД могут давать не понятные результаты.

Вы бы определились: Вы рассматриваете случайную внезапную аварию аппаратуры сервера БД или целенаправленные действия "особо инициативного" пользователя-идиота?
vadiminfosphinx_mvВыполнение недокументированных действий и предъявление после этого претензий по поводу неправильного результата, полученного в результате этих действий - это персональный непрофессиональный бред третьекурсников-теоретиков.

Возможно, неправильные результаты могут быть и при выполнении "документированеных" действий.

Неправильные результаты в ответ на "документированные" действия пользователя - наличие ошибки, допущенной при реализации системы. Тестирование информационных систем, выявление ошибок и их устранение - НЕ тоже самое, что неправильные действия пользователя.
Это примерно то же самое, что перебегать дорогу в неположенном месте перед быстро несущимся потоком машин, а потом жаловаться, что, типа, "задавили"...
vadiminfosphinx_mvА те, кто ИМЕЕТ право - ОТВЕЧАЮТ за те действия, которые выполняют.

Ну это означает, что средствами БД полностью запретить не получилось. Раздача прав, это уже не ОЦ, но и ея не хватило, нужен.
административный запрет. Это не интерсно.

А как интересно Вы сможете применить это запрет?
Отключите систему от электричества и локальной сети и зальете ее бетоном в котловане?
А другого способа, собственно, не существует...
vadiminfosphinx_mvТо, что у ВАс такого "не было ни разу" - даже не подвергалось сомнению ДО того, как был приведен пример...
Держать пол-терабайта архивных данных на каждый год (из почти десятка лет) архивов в "рабочей" базе на активном сервере - лично мне как-то не особо нравится...

У меня еще не бывало, чтобы из-за смены ПК, либо вообще чего бы то ни было в оперативной БД, архивы не восстанавливались.

На это только и можно сказать "никогда не говори никогда"... У Вас все еще впереди...
vadiminfoВ Оракле есть секционирование и поддержка "быстрой архивации", в плане сервера: в БД меняется кое-что в словаре и файлы с данными не в словаре БД. При этом, однако, Оракл контролирует отсутсвик каких либо зависмостей в словаре БД архивирумого от всего остального в БД (транспортируемые табличные пространства).

Я не специалист по Oracle. Соответственно, несколько вопросов...

А связи между РАЗНЫМИ серверами БД, обслуживающие РАЗНЫЕ системы разных производителей, Oracle тоже "отслеживает"?
А если это связь с серверами другого типа? А если "других типов" больше двух?
Честно говоря, "терзают смутные сомнения"...

Как в-прочем и в случае, когда Вы заархивируете сегмент данных, удалите его, потом поменяете ПК в мастер-таблице, на которую ссылается таблица из архивированного сегмента... А потом через некоторое время (месяц, пол-года, год) Вам надо будет поднять данные из архива... Просто внятно объясните, КАК в этом восстановленном архивном сегменте "внезапно пофиксятся ссылки"?
vadiminfoНет, кто-то, конечно, может дропнуть ссылочные ОЦ ради архивации. Остается пожелать иму удачи.
Зачем обязательно "дропать ссылки"?
Я вполне могу "пожелать удачи" даже тем, кто считает, что "изменение ПК ни к чему плохому не приведет"...

vadiminfosphinx_mvА че только себя?
И че только два раза?
И почему только в две таблицы? Самое "счастье" начнется, когда пойдут ссылки (хотя бы одна) на любую из таблиц

Этого достаточно чтобы проверить существование данного преимущества в принципе.

Существование преимуществом НЕ является...
Существование преимущества НЕ демонстрируется...
vadiminfosphinx_mvОграничиваемся следующими атрибутами:
…..


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

Не извиняю...
Пример был предложен Вами!
Какой пример предлагался - для того примера и была продемострирована НЕЭФФЕКТИВНОСТЬ использования естесвенных первичных ключей...
vadiminfoЯ приводил примеры, тока пока считал, что Вы утверждаете, что естественные ключи никада не могут использовать.
Как тока Вы сказали, что в "узком круге" они используются необходимость в примерах отпала.

Не утверждалось, что это достоинство а так же в купе с другими перевесят все недостатки во всех проектах при сравнениее с суррогатами.

Естественные ключи КРАЙНЕ ПЛОХО использовать.
И уже хотя бы потому, что они МОГУТ измениться - и плакали связи между таблицами...

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

Ошибки в программе НИКАКОГО отношения к действиям пользователя НЕ имеют.
Забивать гвозди работающим мобильным телефоном ширпотребовского класса (в котором в принципе могут быть глюки) можно, но нельзя после этого требовать, чтобы телефон после этого оставался в рабочем состоянии...
vadiminfosphinx_mvА как интересно Вы сможете применить это запрет?

Так я и не собирался «применть» это запрет. Вы же говорили, что мол нуно это запретить и все такое. Вы же спрашивали, что меня смущает в таком запрете. Вот в частности, применение и смущает.

Небольшая, простая и изолированная система МОЖЕТ допускать все, что угодно пользователю.
Но с превышением некоторого порога в зависимости от типа решаемых задач (порог, кстати, очень небольшой) позволять пользователю делать все, что хочет его левая пятка, уже становится опасным. И сразу же начинаются запреты и ограничения!

Не учитывать при проектировании системы возможностей роста и связанных с этим трудностей роста - не правильно...
А все, что "не правильно" - не допустимо...
vadiminfosphinx_mvА связи между РАЗНЫМИ серверами БД, обслуживающие РАЗНЫЕ системы разных производителей, Oracle тоже "отслеживает"?
А если это связь с серверами другого типа? А если "других типов" больше двух?
Честно говоря, "терзают смутные сомнения"...

У каждого проекта достоинства и не достатки могут иметь разный вес.

Разный вес - это только в начале, пока система не разрослась...
А вот как только начинаем расти - все!.. Туши свет... И менять что-либо в архитектуре системы - смерти подобно...
Не проще ли сразу принять НАИБОЛЕЕ неподверженное "эксцессам" решение? Тем более, что разницы в стоимости решений при выборе типов ПК и допустимых операций над ними вполне известна еще на этапе анализа предметной области. И эта стоимость ОЧЕНЬ НЕ в пользу выбора естественных ключей в качестве ПК или разрешения операций по модификации и удалению ПК в информационной системе...
vadiminfosphinx_mvКак в-прочем и в случае, когда Вы заархивируете сегмент данных, удалите его, потом поменяете ПК в мастер-таблице, на которую ссылается таблица из архивированного сегмента... А потом через некоторое время (месяц, пол-года, год) Вам надо будет поднять данные из архива... Просто внятно объясните, КАК в этом восстановленном архивном сегменте "внезапно пофиксятся ссылки"?

Не ссылается ни на что в том проекте. Это значит в плане сравнения достоинств и недостатков, что не проявились некоторые недостатки, связанные с изменением значения ПК в данном проекте. Потому их вес при сравнении уменьшился в данном случае.

Вот видите - Вы обсуждаете вкус ананасов, ни разу их не попробовав...
В Вашем проекте данные не связаны... Но Вы утверждаете, что "проблем со связями не будет"...
БУДУТ!.. ОБЯЗАТЕЛЬНО БУДУТ! Когда связи появятся...
А когда понадобится поддерживать логическую связность данных не просто на разных серверах, но и на разных платформах - произвольное изменение и удаление ПК вызовет СТОЛЬКО проблем, что в пору будет застрелиться... Из веника...
vadiminfosphinx_mvЗачем обязательно "дропать ссылки"?


Не получится, скорее всего, быстрая архивация (и быстрая же разархивация), если есть какие-то ссылки в нен тока объектов, но и табличных пространсв содержащих эти объекты между на что либо в БД, что не попадает в архив. А внешний ключ прописан в словаре. Поэтому как убрать из словоря, не дропая?
Забавно...
Т.е, Вы пожелали успехов при "дропании ссылок" лично себе?
Ведь Вам как-то удается выполнять все эти операции по архивированию/удалению/восстановлению данных, а БЕЗ удаления ссылок все это невозможно...
А! Вспомнил!.. В Вашем проекте ССЫЛОК НЕТ!!!

vadiminfosphinx_mvСуществование преимущества НЕ демонстрируется...

Ну с етесвенным ключем не ввели копию объектов, а сурогатным ввели. Стало быть демонстрируется именно тока одно преимущество. А не превосходство естесвенного пред суррога по сравнеению всех достоинсв и не достатков.

А вот не надо бредить!
Использование суррогатных первичных ключей НЕ отменяет наличие альтернативных естественных ключей!
Просто естественные ключи НЕ используются в качестве первичных - ВОТ И ВСЯ РАЗНИЦА в информационной модели!
Соответственно, ввести дубликат значения атрибута или группы атрибутов, которые представляют собой альтернантивный ключ НЕ получится даже при использовании суррогатного ПК.

И не надо забывать, что в систему НЕ УДАЛОСЬ добавить объект, который ДОЛЖЕН был быть добавлен, но для которого отсутствовало значение атрбута, выбранного в качестве первичного ключа - автоматически указывает на НЕВЕРНЫЙ выбор ключа.
vadiminfoНапример, админ отключил связь и дропнул по ошибке пол родительской таблы. А в дочерний море ссылается на это. В случае естесвенного, достаточно восстановить родительскую. А в случае суррогата это может иметь драмматический характер, если дочерняя большая, хотя родительская и малая.

...А еще админ может сжечь архивные носители и отформатировать диски на сервере...
Менее драмматической ситуации с админом-идиотом представить себе невозможно...

Никакой разницы в описаной Вами "клинической" картине между суррогатными и естественными первичными ключами нет!
Что там, что там нужно восстанавливать мастер-таблицу... И что там, что там надо будет проверять корректность связей.
И хорошо, если не придется поднимать "бумажные" первоисточники - и тоже в ОБОИХ случаях.
vadiminfosphinx_mv....
Никакие достоинства естественных первичных ключей (даже в купе с достоинствами всех прочих компонентов системы) НИКОГДА не смогут перевесить преимуществ суррогатных ключей в купе с ТЕМИ ЖЕ достоинствами ТЕХ ЖЕ САМЫХ компонентов ТОЙ ЖЕ САМОЙ системы - у суррогатов НЕДОСТАТКОВ меньше при большем количестве собственных ДОСТОИНСТВ... И это соотношение было продемонстрировано непосредственно при разборе предложенного Вами примера.

Это утверждение звучит как теорема, обладающая всеобщностью (НИКОГДА). Стало быть не может быть доказана разбором примеров. Этими раборами может быть доказано только, что это утверждение пока не опровергнуто.
Тем более в моем примере страховые были у всех. Без страховых там на работу не брали. Вы говорили что не у всех (Необязательное). Это вообще разные примеры.

Пенсионных номера "ОСНОВНЫМ идентификатором" еще не стал, да и официально признан как (возможный) "основной идентификатор" совсем недавно - ГОДА НЕ ПРОШЛО! Соответствующее распоряжение было подписано 15 апреля 2011 г...
Для "некоторых категорий" работников наличие пенсионного номера стало обязательным вообще всего лишь 3 (три!) месяца назад.
Соотвественно, "не брать без пенсионого номера" ДО этого времени никто НЕ мог... Даже точнее - НЕ имели права...

Я даже больше скажу - ОНИ обязаны брать БЕЗ пенсионого номера ДАЖЕ СЕЙЧАС !
Читайте ДОКИ - они РУЛЕС!
===
http://news2.ru/story/305402/
...
Согласно закону об индивидуальном (персонифицированном) учете свидетельства обязательного пенсионного страхования выдаются после начала гражданином трудовой деятельности: работодатель , начисляющий зарплату или заключивший гражданско-правовой договор (подряда и др.), подает соответствующие сведения в Пенсионный фонд России для открытия счета. Самостоятельно получить такое свидетельство могут только индивидуальные предприниматели, адвокаты, частнопрактикующие нотариусы и т.п.
...
===
Попрете ПРОТИВ ЗАКОНА ?!

Требования, выходящие ЗА рамки действующих юридических норм - НАРУШЕНИЕ, за которое, кстати, можно и получить "по голове"... Соотвественно, ваш пример - это "сферический конь в эидком вакууме"...
vadiminfoК тому же в общем случае, где гарантия, что завтра кто-то не найдет убийсвенного примера для суррогатов?
Потому, думау, принимать данную теорему на веру все еще преждевременно.

Не выйдет! Реляционной теории уже 40 лет. За это время вполне можно было бы и "наработать негатив" по поводу суррогатов...
Но, почему-то, вместо этого "нарабатывается негатив" по поводу естественных ключей...
vadiminfoОсобенно если юзаешь БД в Аксцессе. В Оракле нет каскадного обновления на уровне системы, а попытки организвать с помощью триггеров, могут привести к взаимным блокировкам. Тем ни менее видел и на Оракле БД с естесвенными ключами.
О, да! Акцесс в качестве примера "большой промышленной СУБД" - это сильно!..

А по поводу "видел/не видел"... Ну, я "ВАЗ" видел... Вроде бы даже "ездит"...
Но (почему-то) "Мерседес" нравится больше...

vadiminfosphinx_mvИспользование суррогатных первичных ключей НЕ отменяет наличие альтернативных естественных ключей!


А использование автомобиля не отменяет использование самолета: самолет может перевести автомобилиь, и поэтому мол у самолета нет преимущества перед автомобилем в том, что он может летать. (перевез то через этот недостаток суррогата естесвенный)

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

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

Вроде не пятница, но ни фига не понял...
vadiminfosphinx_mvНикакой разницы в описаной Вами "клинической" картине между суррогатными и естественными первичными ключами нет!
Что там, что там нужно восстанавливать мастер-таблицу... И что там, что там надо будет проверять корректность связей.
И хорошо, если не придется поднимать "бумажные" первоисточники - и тоже в ОБОИХ случаях.

Естесвенный:
в родительской - A122, AC12, ....-- идентификаторы приборов прописанные в доке.

В дочерней имзмерения этих приборов
внешние ключи A122, AC12, ....--

А можно я угадаю, чтов доке должны быть прописаны приборы с "номерами" A121 или А123?
Или АС11 или АС13? И как же я так "случайно" их угадал?

И, обращаю внимание - сами по себе комбинации "А122" или "АС12" не несут НИКАКОЙ смысловой нагрузки.
Точно как и любой другой суррогат, пока про него не скажут, что "этот номер означает это"...

Ну, а с учетом "возможности восстановления" по этому коду...
А нет ее - НИКАКОЙ!

Где гарантия, что при потере данных из первичной таблицы при этом не потерялись данные в дочерней?
Кто сказал, что при этом не сработают так Вами любимые каскадные операции при обновлении и удалении ПК, когда используется опция удаления подчиненных записей или опция изменения внешние ключи дочерних таблиц на NULL... Получить родителей невозможно - все внешние ключи пустые... И то, если "дети живы остались"...

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

отсутсвует 300 записей. Но их воостановили по доке. В дочерней ниче просматривать не надо.

Суррогаты.

Теперь внешний ключ это ниче не значащие в предметной области числа.

Человек, НЕ СПОСОБНЫЙ понять, что на самом деле происходит за границами маленькой песочницы НЕ способен проектировать информационные системы, отвечающие максимально возможной полноте предметной области.
Номер паспорта, полученный по сути инкрементом на 1 от некоторого предыдущего номера - это суррогат...
Но понять ЭТО горе-проектировщики, к сожалению, НЕ В СОСТОЯНИИ...
Функциональный ключ "пенсионный номер", полученный комбинацией автоинкремента и некоторой контрольной цифры - это ТОЧНО ТАКОЙ ЖЕ СУРОГАТ - Вас просто ТКНУЛИ носом в него и сказали, что теперь этот автоинкремент будет использоваться как "пенсионный номер"...

В-общем, подпускать таких, как Вы "специалистов" нельзя не только к проектированию, но и с учетом детского энтузиазизьма о праве администратора делать в БД все что ему вздумается, включая операции удаления данных, то и к сопровождению и обслуживанию информационных систем тоже...
vadiminfoТеперь все же как-то нуно узнать к чему дочерние относятся.

Возможно, это затратнее.



Сеня узнал, что промышленная СУБД Скуль поддерживает каскадное обновление

ON UPDATE CASCADE

http://msdn.microsoft.com/ru-ru/library/ms186973.aspx

раньше вроде не было.

Раньше - это в каком веке? SQL2000 ее уже поддерживал...
Но про технические ограничения конкретно ЭТОЙ операции (даже для более "свежих" версий MSSQL) Вам рассказать?
Или поверите "на слово", что "не спасает"?
vadiminfoЭто все же в основном снижает недостатки естесвенных в этой СУБД.

Это в купе с появлением естественных идентификаторов типа пенсионного номера, маркеров, и т.д. и т.п., возможно,
не совсем свидельстует об окончательном господстве суррогатов.
Ну, а если попробовать мозги включить?
Пенсионный номер ...
Номер удостоверяющего документа...
Номер накладной...
Что называется, "совсем не-суррогаты"... Ага...
Маркеры... Что они означают ВНЯТНО рассказать можете? Как маркеры "создаются" подумали?
Серийные номера?.. Инвентарные номера?.. Номера счетов?.. Номер партии изделий?..
Что у нас еще в "естественных" ключах крутится?
Номер дома и квартиры? Почтовый индекс? Номер телефона?
IP-адрес? Например, 0x7F000001 - что за IP-адрес подсказать? 127.0.0.1 - он же localhost...
MAC-адрес сетевого интерфейса?
Ну, ХОТЬ ЧТО-НИБУДЬ НЕ-СУРРОГАТНОЕ?..
А нету...