Ответ на »сообщение 223« (Как слышно? Приём!)
___________________________
Имеем три организации E1, E2, E3 независимо ведущие три однотипные базы B1,B2,B3 Решение этой проблемы очень простое:
1. в каждой БД хранится идентификатор этой самой базы IdDB, который задаётся централизовано при создании этой самой БД.
NewId = NextVal + 1E9 * IdDB
2. Использовать в качестве идентификатора GUI

Самопальные изобретения естественных ключей и есть игнорированием исследования предметной области. Распределенные базы данных давно уже существуют (cм. SyBase ASA). У нас это даже более актуально, т.к. существенно снижает нагрузку на убитые телефонные линии.

В случае естественных ключей единообразие законов их образования уменьшает проблему Нужно не уменьшение проблемы, а её решение. Понятное дело, если обмен данными осуществляется с помощью текстовых файликов, то тут остаётся только для каждого человека сверять ФИО+ПОЛ+ДР+МР, но это решение прошлого века.

Прежде всего (соль на рану Сергею Рощину :) философские основания.
Не может быть панацеи - раз.
Критический подход - основа научного мировоззрения - два.

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

Если подумать ещё о таких вещах:
Параллельная обработка и глобальная индексация.
Механизм элегантного решения задачи обработки идентичных записей.
Параллельно завершать по нескольку транзакций - многопользовательская работа с данными.
Интеграция данных приводит к полуструктурированным и изменяющимся данным
и опять же затратная индексация.

Ответ на »сообщение 223« (Как слышно? Приём!)
___________________________
>>> Имеем три организации E1, E2, E3 <...>
Если это три независимые организации, то тут вообще куча проблем: нужно вообще прорабатывать механизмы экспорта/импорта (разный набор полей, разные типы данных и т.п.), а не ограничиваться разборками с первичными ключами.

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

>>> Само безусловно широкое распространение ИК обусловлено игнорированием исследования предметной области
Ничуть того ни бывало. Просто сейчас теория программирования предполагает, что при определении сущностей для всего должен быть собственный атрибут. Это не обязательно касается баз данных. То же самое мы наблюдаем и при разработке классов. А только после того, как черновой вариант подготовлен, и при наличии ОЧЕНЬ веских обоснований допускается использовать один и тот же атрибут для разных целей.

И это не придурь, не мода от Микрософта. Это обобщение опыта работы программистов за большой промежуток времени.

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

Простота реализации клиента стандартными компонентами VCL веским основанием не является ;-)

Ответ на »сообщение 223« (Как слышно? Приём!)
___________________________
Слияние баз данных при объединении организаций, дело многотрудное при любой организации БД. Синтетические ключи такую работу не усложняют. Это единственный случай, когда каскадное изменение становится необходимым.
Самая первая "БД" (еще на лентах), которую я помню, делалась для учета автомобилей в ГАИ. И сразу же выяснилось, что у автомобиля нет естественного ключа: может поменяться регистрационный номер, номер двигателя, номер шасси и т.д.
Кроме того, в естественные ключи, как правило, приходится включать текстовые поля, что, естественно, сильно тормозит работу с индексами.

Ответ на »сообщение 221« (Тимур и Ко)
___________________________

>>> Правда, такое откровенное выдавливание оппонентов из обсуждения <...>
И опять Вы меня не поняли. Я никого не выдавливал. Я просто пояснил, что мои утверждения не носили общего характера. Это были высказывания в частной беседе по частному поводу. Естественно, если попытаться их рассматривать с более общей точки зрения, то они не всегда будут корректны. Я Вам даже примсер привел про школьную физику и ускорение свободного падения.

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

Теперь я не знаю, стоит ли двавть ответы на содержательные моменты, затронутые в Вашем сообщении. Если Вы действительно решили отказаться от диалога, то мне отвечать не имеет смысла. Если же Вы решите продолжать, то тогда я отвечу. Решение за Вами.

Ответ на »сообщение 223« (Как слышно? Приём!)
___________________________
>>> Е1 передает В1 базу в Е2, там её записи получают новые ИК, далее она ведёт базу и передаёт её в Е3.
>>> Е2 также передает через некоторое время в Е3.

Oops!

Е1 передает В1 базу в Е2, там её записи получают новые ИК, далее она ведёт базу и передаёт её в Е3.
Е1 также передает данные через некоторое время (минуя Е2 с её переиндексацией) в Е3.

Имеем три организации E1, E2, E3 независимо ведущие три однотипные базы B1,B2,B3
не имеющие первоначально единой автоинкрементной индексации по ключу.
Е1 передает В1 базу в Е2, там её записи получают новые ИК, далее она ведёт базу и передаёт её в Е3.
Е2 также передает через некоторое время в Е3.
В результате имеем одинаковые записи с разными ИК в Е3.
Если добавить разветвлённую структуру базы данных
и передачу её по частям в разные моменты времени хаос усиливается.

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

Само безусловно широкое распространение ИК обусловлено
игнорированием исследования предметной области
путем введения централизованного единообразия под одну гребёнку.
Крах внедрения дорогостоящих ERP, реинжинирингов и прочая, и прочая - естественное следствие
штамповки безликих кладбищ информации.

Ответ на »сообщение 219« (Тимур и Ко)
___________________________
поддержка каскадных изменений, видимо снижает недостатки "второго подхода". Oracle к примеру поддерживает каскадное удаление, но не поддерживает каскадное изменение. Учитывая, что это одна из самых продвинутых промышленных СУБД, можно удверждать, что этого нету не по тому, что мощщи не хватило сделать, а по тому, что это на столько невостребовано, что и заморачиваться не стоит.
В общем я Ваших сообщениях вижу только некоторые декларации и придирки к постановке фраз. По сути вопроса не наблюдается ни каких доводов.
Расскажите же нам аргументировано, чем естественные ключи, по Вашему мнению лучше синтетических, в каких ситуациях их следует применять, к каким последствиям это ведет. Для подтверждения своих утверждений не обязательно приводить ссылки на Эзопа, Фалеса и Зенона Элейского, нам бы просто на конкретных примерах показать к каким практическим выгодам приводит использование...

Ответ на »сообщение 219« (Тимур и Ко)
___________________________

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