softwarer
Да, и реализации ссылочной целостности на триггерах в приведенных мной примерах выше это тоже не поможет.

softwarer
Вы наверное не поняли мою мысль. Попытаюсь ее донести более подробно. Ибо в приведенном примере Вы могли с тем же успехом оставить только Edit. Это бы все равно ничего не поменяло.

Предположим, у меня есть секвенсор, который умеет генерить уникальные идентификаторы (неважно какого типа), и я привязал его ко всем суррогатным PK своих таблиц (опять же неважно какого типа). Теперь у меня возникает, например, такая задача. Для любой записи в любом справочнике уметь задавать произвольные атрибуты и их значения, настраиваемые пользователями (это не внутренняя разработка, потому что там наворотят юзера - мне не интересно, пример - технические параметры номенклатуры и миграция их в картотеку ОС, где они могут меняться со временем и в зависимости от узла ОС). При удалении записи из справочника необходимо каскадно удалять все записи о таких атрибутах (дискутировать насчет целесообразности удаления записей из справочников не собираюсь, это здесь не принципиально, можно заменить "справочник" на "документ" или "проводку", если хочется). Также необходимо обеспечить возможность поиска (в конкретном справочнике и вообще в БД) по таким атрибутам и их значениям (то есть, один и тот же атрибут может использоваться в нескольких справочниках), копирование атрибутов и их значений при копировании сущностей. Так как справочников, документов и прочих сущностей в БД немеряно, создавать на каждую сущность отдельную табличку с атрибутами слишком дорого. Поэтому о DRI забываем.
Итак, проблема первая - insert в таблицу attrib_values. В таблице со значениями атрибутов необходимо иметь ссылку на элемент справочника. Предположим, у меня идентификатор записи в справочнике уникален в пределах БД и равен 1. Как проверить в триггере на insert на таблицу attrib_values, что запись с идентификатором 1 вообще есть в БД (в каком-либо справочнике)? Отказаться от контроля ссылочной целостности при вставке? Себе дороже потом разгребать.
Проблема вторая - поиск сущностей по атрибуту (или его конкретному значению). Найти все записи об использовании атрибута безотносительно сущности несложно (в attrib_values ищем записи по значению идентификатора атрибута). А вот потом начинается беда. Ну, пусть знаю я, что атрибут используется в сущности с идентификаторами 1, 2 и 150, что это такое, дальше-то куда? Как проверить, хотя бы, корректно ли он используется для этой сущности?
И т.п. для каждой задачи в преамбуле моего сообщения.

Собственно, проблема здесь одна. Имея набор записей в attrib_values, невозможно только по значению одного поля id_entity, в котором лежит уникальный в пределах БД идентификатор, определить, что это за entity такая, которая идентифицируется этим значением.

Вы, видимо, знаете волшебную функцию FindObjectById, которая по значению идентификатора вернет, в какой таблице лежит сущность, которую он идентифицирует. Может, для oracle такая штука для sequence-а действительно есть, таких тонкостей не знаю (но исходя из здравого смысла думаю, что нет такой возможности, ибо пришлось бы хранить всю историю значений, куда они отлетели), но все же тэг src delphi в Вашем сообщении мне подсказывает, что Вы меня неверно поняли.

Простой пример:
[контрагенты]
id info
1 "Иванов"
2 "Петров"
3 "Сидоров"

[номенклатура]
id info
4 "Ручка"
5 "Ножка"
6 "Таз"

attrib_values
id_entity id_attrib
4 8
3 8
4 9
5 7
1 8
2 7 (*)
1 9

Как понять, что строка (*) используется для контрагента "Иванов"? Откуда сделать вывод, что сущность надо искать именно в контрагентах?

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

Опечатка. В предпоследнем абзаце не Иванов, а Петров.

Сахават ЮсифовА зачем делить на "контрагенты", "номенклатура",..?
То есть, развивая Вашу мысль, все таблицы в БД "наследуются" от одной таблицы? Ну-ну.

Сахават ЮсифовНу а зачем тогда уникальный на всю БД идентфикатор?
Это не моя идея. Моя идея - для идентификации любой сущности, которую потребуется идентифицировать, достаточно знать ее идентификатор, уникальный в рамках таблицы (например, identity или sequence), где лежит ее (сущности) заголовок, и имя таблицы (ну или аналог имени таблицы, который навсегда связан с таблицей и исходя из значения которого можно построить требуемые операторы SQL). Глобально уникальный идентификатор (в рамках даже целой БД) мне не нужен.

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

softwarerВ Вашем "не поняли мысль.... более подробно" об этом вообще нет ни слова, Вы целиком ушли от темы.
Вот что у меня было написано: "Также необходимо обеспечить возможность поиска (в конкретном справочнике и вообще в БД) по таким атрибутам и их значениям (то есть, один и тот же атрибут может использоваться в нескольких справочниках)". Поиск выполняет человек, он хочет по атрибуту понять "где это", посмотреть на это. Ответ "в сущностях с номерами X,Y,Z" вряд ли устроит кого-то. Если же с формальной точки зрения точно известно, что хочется отобразить, отобразить это труда не представляет, это просто техническая задача. Так что с точки зрения идентификации сущности в БД это полностью равносильные задачи.

softwarer
2. На то, к чему Вы клоните, я ответил в http://www.sql.ru/forum/actualthread.aspx?tid=402005&pg=6#3867730 и как мне представляется, довольно окончательно.
Это Вам почему так представляется, если я даже не понял суть Вашего ответа, как он относится к тому, что я написал?

softwarer
3. Я не думал, что собеседнику на этом форуме потребуется объяснять, что такое "виртуальный метод" и чем он влияет на "ничего бы не поменяло".
Пожалуйста, обясните, что-такое "виртуальный метод", например, в рамках триггера или хранимой процедуры. Ибо мне это надо на SQL на уровне сервера. И при чем тут ORM, Вы сами решили, что это именно то, что я имею в виду, или я дал Вам какие-то основания для этого, и даже если Вы правы, что из этого следут?

softwarer
Все ясно. Спасибо за внимание.