Осуществить ссылочную целостность на осуществленном пути?

В модели материализованного пути вы можете использовать произвольные строки (возможно, строки Unicode, чтобы разрешить более 256 дочерних элементов) вместо специальных строк формы «xyz». Идентификатор родительского элемента тогда является идентификатором прямых потомков с удаленным последним символом . Вы можете легко обеспечить это с помощью ограничения проверки, например (мой пример работает в PostgreSQL)

check(parent_id = substring(id from 1 for char_length(id)-1)),

в вашей команде создания таблицы. Если вы настаиваете на строках формы «xyz», вам придется поиграться с регулярными выражениями, но я думаю, что можно найти соответствующее ограничение проверки.

«Материализованный путь», представленный Вадимом Тропашко в этой статье, вводит понятие порядка в отношение («Джонс - второй член».).

«Материализованный путь» - это ничего, кроме «некоторой формы материализованного представления» о транзитивном замыкании, и поэтому страдает от всех и в точности тех же проблем, что и любое другое «материализованное представление», за исключением того, что с точки зрения алгоритмов дела обстоят хуже именно из-за участия замыкания.

SQL почти полностью бессилен, когда действуют ограничения на закрытие. (Имеется в виду: да, SQL требует, чтобы вы все делали самостоятельно.) Это одна из тех областей, где RM демонстрирует максимум своей почти неограниченной мощности, но SQL ужасно терпит неудачу, и где так жаль, что большинство людей ошибочно принимают SQL. для отношения.

Да, мы можем «обеспечить ссылочную целостность в поле [путь]». Я сделал это пару лет назад, как описано здесь:

Сохраните настройки конфигурации в виде иерархии в базе данных