Здравствуйте.
Начинаю изучать ABAP.
Обратила внимание на то, что как в стандартных так и в пользовательских таблицах SAP используются, как правило, натуральные ключи.
Есть какие-то весомые причины для отказа от использования суррогатных ключей в пользовательских таблицах?

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

Раскройте, плз, что вы подразумеваете под натуральным и суррогатным ключем?

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

Речь идет о id записи? Такой подход типичен для многих систем. Мне его очень не хватало, когда я только перешел на SAP. Ничего, привык. Сейчас появились некоторые таблицы, в которых используются суррогатные ключи. Мне это кажется нарушением концепции.

Ну в оракле так вообще красота. С idшниками строк.

А в САПе проблема только одна: если необходимо менять первичный ключ записи - пиши пропало. Очень некрасивые решения получаются.
Или свой диапазон номеров создавать приходится. Которые в САПе тоже, кхм, не идеальны.

пожалуй, в таком контексте:
"Естественный Ключ (ЕК) - набор атрибутов описываемой записью сущности, уникально её идентифицирующий (например, номер паспорта для человека);
Суррогатный Ключ (СК) - автоматически сгенерированное поле, никак не связанное с информационным содержанием записи. Обычно в роли СК выступает автоинкрементное поле типа INTEGER." (взято из http://www.delphiworld.narod.ru/base/na ... _keys.html)

мой взгляд на вопрос совпадает с мнением автора статьи http://www.delphiworld.narod.ru/base/na ... _keys.html

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

Так что мне, в принципе, без разницы какой ключь.
Мне rowid, уникальный в рамках СУБД, нужен

У нас система ( SAP for Banking ) полностью построена на суррогатных ключах типа SYSUUID - думаю это сделано в целях улучшения производительности из-за большого числа пользователей и транзакций

SYSUUID - это домен

В CRM, например, id-шники распространены. Да и во всех современных разработках, я думаю.

Прикиньте, какой длины ключ у таблицы mseg в юникодной системе.
В то время как достаточно было бы INT4.

Понятно. Как и подозревала, видела пока слишком мало таблиц Всем спасибо!