КурдльЭто решение продиктовано моделью.
...
Во всяком случае для OLTP-систем.
Сомневаюсь.
Кроме большого количества проблем разного рода, включая проблемы с оптимизатором (в том числе проблем со стоимостью, join elemination и др.), я уже не говорю про вагон и маленькую тележку очевидных проблем не связанных с апексом, не встречал ни одного полезного свойства (при том, что работать с ними приходилось много).
Это всё скорее ошибки проектирования, имхо.

Курдль,

По теме: В апексе тяжело будет работать с составными ключами.

Начиная с какой-то версии (скорее всего 4.1 или раньше) есть выбор при создании Tabular Form: на основе ROWID или PK.
Для остальных случаев (например, выпадающих списков), можно создать обновляемое представление, и представить в виде PK что угодно. При этом заполнять PK можно в instead of триггере, а не на клиенте, на основе, например, скрытых полей, для которых проставлен default или hidden items. Впрочем instead of - это достаточно тяжелый метод, сильно усложняет разработку, проще переделать на простые ключи, если еще не поздно.

Курдль,

т.е. таблица CITIZENSHIP с полями ID_персоны и ID_государства - первичный ключ ?

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

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

Люди тоже постоянно меняют фамилию. Не редко бывают запросы от людей: когда первый раз у них одна фамилия, во втором запросе другая (и другой паспорт), соответственно их часто заводят как разных людей (и даже если паспорт одинаковый, такое часто бывает), а потом нужно объединить => меняется идентификатор человека.

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

Касательно апекса, если делать по вашему, можно сделать вью: PK - составное поле через разделитель, и отдельно поля, сделать вью обновляемой. Соответственно в Tabular Form первичный ключ - составное поле из view, для новых строк будет null, указать, что генерируется на основании триггера. view пересчитывает значение уже после внесения записи, соответственно, MRU смотрит, если поле первичного ключа null - запись новая, если не null - существующая.

Petro123ID ФИО Гражданство(FK)2 Петров РФ3 Сидров5 Иванов "то что в паспорте"
Даже в таком варианте, если заменить в FK естественный ключ на суррогатный, для программиста будет +.
Сожмёт таблицу, улучшит производительность. Рано или поздно понадобится изменить значение => облегчит модификацию в справочнике гражданств.

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

Курдль,

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




Typ=96 Len=8: 208,161,208,161,208,161,208,160Typ=2 Len=2: 194,2
Соответственно, данные в значительно большей таблице занимают больше места => нужно смотреть по большой таблице.

Курдль,

Байты считать в СУБД- не моветон. Чем больше Гб будет лопатить sql, тем хуже будет производительность.
Пара лишних ГБ умножить на несколько тыщ запросов от каждого пользователя...

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

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

КурдльЛогическая ошибка - это ошибка в определении логических взаимосвязей между сущностями предметной области.
Продемонстрирую приложенной моделью. Как Вы иначе сможете смоделировать такое отношение сущностей предметной области?
Не вижу никаких проблем в наличии простого первичного ключа ID или citizenship_id в этой модели. Уверен, в вашем софте есть такая возможность - указать пару свойств.

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

Так ли это на самом деле? Типичная ситуация: меняется значение естественного ключа - ломается функционал в интегрированной системе, завязанный на ключ, для которой поддержка уже закончилась, что в этом хорошего ?

КурдльСоставные ключи - наиболее надежное с точки зрения целостности данных физическое воплощение отношения типа "depended".

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

КурдльSvDevЯ бы сказал, составные ключи менее надежны. Например, первичный ключ не должен меняться, при составном ключе - это правило рано или поздно нарушается.

Я так и не смог довести до благородного сообщества, что в приведенном мною примере 20160306 составной первичный ключ выполняет роль и уникального индекса (ибо нельзя быть "дважды гражданином" одной и той же страны).
В этом и есть залог надежности (поддержка целостности данных).
По-вашему мне кроме этого первичного/уникального ключа зачем-то нужен суррогатный. Зачем?!!
Писал уже, читайте выше. Уникальность предполагается и в том, и в другом варианте, никак не спасет от того, что данные потом поменяться могут и поменяются с определенного момента. Затем же, зачем нужна нормализация модели до определенной степени, чтобы избежать проблем разного рода в дальнейшем (см. выше).

КурдльИ что значит "может измениться"? Ну да - в данном примере физ.лиц может лишиться гражданства или вступить в другое. И что за проблема? Удаляется одна запись и создаётся другая.
Это вы сейчас думаете, что вам не нужна история, или что её можно просто удалить, через некоторое время окажется по-другому.
Думать лучше не о том, как нажать поменьше кнопок при составлении модели, а о том, чтобы получить лучший результат.
Почему результат получится хуже, уже достаточно всякой информации приведено, имхо.