softwarer,

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

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

Весьма повеселило обсуждение GUID :)
Технари увидев слово GUID понеслись обсуждать его, забыв про исходную задачу - зачем требуется обеспечение уникальности в нескольких таблицах с использованием одного сиквенса?
Уникальность записи в БД чаще всего определяется названием таблицы и содержанием суррогатного ключа определенного по ней (без разницы сиквенс или идентити)

softwarerОдин сиквенс на несколько таблиц удобен во всех случаях, когда по нескольким сущностям разложено "что-то, обладающее общими чертами". Например, когда несколько наследников одного базового класса разложены каждый по своей таблице в БД - ну хотя бы те же самые классические физики-юрики.
Я думаю мне не нужно объяснять как проектируется в этом случае модель? И как связи между этими таблицами организуются, при этом с констрэинтами FK.

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

softwarerКогда человек в ходе разговора прыгает от позиции к позиции, мне приходится сделать вывод, что собственной позиции у него нет - вернее, что она сугубо неконструктивна, стиля "не соглашусь и всё тут".Г-н, softwarer, я попросил Вас сформулировать задачи для которых требуется то, что я озвучивал в постах выше.
Для меня это основная цель. Обсуждение GUID - это то, что возникло в ходе обсуждения этих задач и разговор ушел в сторону. Поэтому я и вернулся к интересующей меня теме.
Позицию я свою высказал, о чем также написал, ожидая от Вас обоснований либо более детальных описаний требований пресловутых задач.
softwarer Продолжать беседу в этом случае я смысла не вижу - ну опровергну я вторую-третью-четвёртую позицию, он просто перепрыгнет на пятую и "эта музыка будет вечной".
Ну что тут сказать - в рамках форума невозможно человека призвать к ответу. Но не исключаю мысль о простом желании избежать неудобной темы.

softwarerЭти задачи сто раз озвучивались в куче флеймов "identity vs sequence" у нас на форуме. Вы попросили, я не стал посылать Вас в поиск, а в очередной раз озвучил. Был неправ?
Как говорится "для тех кто в танке", еще раз задача: что это за задачи такие, в которых требуется один сиквенс на несколько таблиц
Ваши варианты ответа:
- Эти задачи сто раз озвучивались в куче флеймов "identity vs sequence" у нас на форуме. При этом непонятно причем здесь identity
- Нет ни одной задачи, для которой вообще требовался бы сиквенс. А вот удобен - вполне.
- Один сиквенс на несколько таблиц удобен во всех случаях, когда по нескольким сущностям разложено "что-то, обладающее общими чертами". Например, когда несколько наследников одного базового класса разложены каждый по своей таблице в БД - ну хотя бы те же самые классические физики-юрики. Аналогично, это удобно, например, когда требуется организовать "журнал операций", "журнал аудита" или что-то подобное - в общем, по идентификатору ссылаться на "произвольную запись в БД".

Последний вариант похож на ответ :)
Только вот решается он без одного сиквенса на несколько таблиц и GUID.
Чем не устраивает GUID - в принципе понятно.
Чем вариант использования для идентификации произвольной записи в БД связки название таблицы и суррогатного ключа по сравнению с сиквенсом на несколько таблиц?

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

softwarerГромоздко и неудобно. Такой вариант резонен тогда, когда основной операцией будет "видя запись в журнале, найти, с какими данными делались эти изменения" - чтобы не искать, в какой таблице есть такой ID. На практике задача чаще обратная - "видя данные, посмотреть, что с ними происходило", и тут описанный Вами подход в лучшем случае не даёт никакой выгоды, а в худшем - мешает в варианте проектирования, когда сущность размазана по нескольким таблицам.
Может я не понимаю, но задач "видя данные, посмотреть что с ними происходило" решается достаточно просто и с озвученым подходом Тип сущности+идентифкатор:
- исходя из того что мы видим объект, который мы анализируем - мы знаем его тип и идентификатор
- есть некая таблица аудита для разнотипных объектов, пусть хранящимся в разных таблицах и в ней хранится тип сущности и идентификатор объекта
- запросом по типу сущности и идентификатору получаем все операции

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

softwarerГромоздко и неудобно.
Ну и это конечно интересно. Потому как на практике я сталкивался с подобными решениями (идентификатор, который надо искать по всей базе) и с ними всегда было больше геммороя, потому как громоздко и неудобно :)