Извините, это общие слова.
PL/SQL он одинаковый, что в триггере что в функции.

Например, я реализую constraint двуникальности.

Допустим я готов сделать таблицу недоступной, тем самым поломав парадигму SQL.
Я умею написать пакет с функциями, но я не умею:

- запретить прямой доступ не требуя переключения контекста
- легко "инкапсулировать логику двуникальности" в пакете без сериализации доступа ко всей таблице

Constraint по колонке - это непростая в целом задача для многопользовательского режима.

Первичный ключ не даст мне вставить второе значение, или я чего-то не понял.

> что такое парадигма SQL?
Я имел в виду, когда к данным применимы табличные операции.

Если я правильно понял ваше решение, оно полагается на составной PK из двух колонок - одно для значения, второе для счетчика (1-2).

Хорошо. Я спрятал таблицу, но чтобы к ней можно было писАть через SQL, сделал представление.
Теперь мне снова нужен триггер, только теперь на вьюхе, чтобы мой "особый" constraint исполнить.

Так что ли? И как мне "прятать" исходную таблицу, чтобы руками не лезли, а только через представление?

С удовольствием почитал 15-летнюю тему, где все еще были молодые, решали задачки и не боялись ошибаться :)
Да, там было много решений, но ни одно так и не оказалось полным.
Решение с построчным dbmslock мне понравилось больше всего, т.к. у меня похоже, только я использую ITL locks, которых больше.

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

Я услышал про Mat.view Refresh on commit. Там совершенно другое поведение, запоздалое, с уникальными граблями.
https://dnikiforov.wordpress.com/2011/08/25/materialized-view-and-unique-constraints/

Кроме того, в этой теме обсуждается реализация unique constraint без использования встроенного, прикрепленного к чему-то другому.

Я думал о следующем примере:




Неоправданное блокирование второй сессии.

Это "hello world" для constraints по колонкам. Если я могу решить задачу уникальности, я могу решить общий случай, где критерий уникальности ключа является внешней функцией Distance(key1,key2) < М.

Например: на период пандемии натуральным id не разрешается соприкасаться (разница должна быть > 1) :)
Реализовать эффективный constraint на колонке, удовлетворяющий это правило.

Второй пример: для таблицы регистрации торговых знаков нужно реализовать constraint, который не позволит им быть слишком похожими друг на друга. Похожесть определяется функцией расстояния DistanceTM(clob, clob) (описание торгового знака содержится в колонке типа CLOB).

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

Насколько я понимаю, в многосессионном режиме Оракл такое не умеет.

При обычной уникальности висит.

При "двуникальности" не должен, т.к. разрешено одно повторение.

При "стоникальности" подвисание 99 сессий без необходимости становится серьезным барьером для производительности.

Для меня это не ключевое различие, это свойство функции расстояния, которое может повлиять на скорость.
На логику кода реализующего constraint уникальности влияет мало. Индекс это полезная, но ортогональная оптимизация.

Если строки короткие, я могу построить индекс в пространстве Левенштейна (а не линейный) и вместо полного перебора сравнивать только 2N соседей в N измерениях.

Мое желание скопировать поведение PK связано с тем, что оно хорошо отполировано и широко известно.
Лучше для общего случая я не придумаю.

Пока я решил для insert (в пределах возможностей моих 3-сессионных тестов).
Если не найду интереснее задачек, допилю delete/update.

Почитал про Oracle RuleGen, интересно.

Учитывая количество подводных камней для multirow constraints, было бы намного лучше чтобы такие задачи решались профессионально. Еще лучше - чтобы были встроены в БД производителем, или продавались как надстройка.

Даже если окажется что я худо-бедно и в основном на ощупь один раз правильно реализовал multirow constraint в триггере,
это не значит что такой код легко сопровождаемый, или что я не сделаю ошибку в следующий раз в немного усложненной ситуации.

Свои цели в этом вопросе я достиг, обработку конфликтов в PK понимаю намного лучше чем пару дней назад, использовал select..for update почти по прямому назначению, и увидел что большинство решений тяготеют или к MV-on-commit или GTT+автономные транзакции (я использовал второе).