Комментарии 9
В path нельзя положить UUID, т.к. данные в ltree не могут содержать дефис
Вообще говоря дефисы в UUID для человекочитаемости, если их убрать уникальность идентификатора не пострадает. Поэтому строго говоря утверждение неверно - положить можно, но нужно представление UUID без дефисов.
непривычно видеть первые ИД которые ссылаются на ИД которых еще не существует.
вы просто смогли запутать целостность системы из 4х записей до такого состояния, что в итоге и не поймешь, что же можно удалять или апдейтить)
Статья оставила весьма.. ммм.. скажем так - весьма разнообразное впечатление.
Есть тип данных, который хранит материализованные пути. К нему, кстати, есть куча вопросов безотносительно к статье и описанному в ней применению этого типа. В основном связанная с имеющимися ограничениями на набор символов. Какого, собственно? Всё равно используем CREATE EXTENSION - почему нельзя переопределить всю эту ерунду на старте? Самое очевидное применение материализованных путей - хранение путей в файловой системе... ага, щазз! неприменимо без плясок с бубнами...
Есть некая синтетическая задача, на которой мы покажем, что этот тип данных можно применять на практике. Ну тоже в общем без слёз не глянешь. Это сколько ж всякоразной ерунды надо навертеть поверх этого типа данных, чтобы его таки можно было использовать! причём вот всё это надо навертеть для того, чтобы этот тип данных был применим на этой самой узкой, синтетической, без практического отображения, задачи! Вы представляете, сколько ещё потребуется, если возникнет желание применить этот тип на практике?
Поневоле хочется процитировать бессмертное "Это все равно, что сделать что-нибудь, а потом придумать, для чего вы это сделали, и гордиться этим".
Или, если наконец привести все эти разнообразные оттенки впечатления в одну точку, то получится что-то вроде "Оно есть. Оно работает. Оно настолько сырое, что совершенно неприменимо на практике. Но если его не забросят, то не исключено, что когда-нибудь оно станет полезным."
поделюсь реальным кейсом когда этот тип хорошо выручил,
задача:
не меняя записи в справочнике МКБ 10, так как он может в любой момент обновится из вне,
в выборке отчета показать все записи с A00 по A09 кроме A04, объеденить в один список с болезнями Z29
select * from mkb10_tab2 d where d_ltr @ 'A0*&!A04|Z29'::ltxtquery
при этом план запроса:
Bitmap Heap Scan on mkb10_tab2 d (cost=4.30..15.86 rows=3 width=348)
Recheck Cond: (d_ltr @ 'A0* & !A04 | Z29'::ltxtquery)
-> Bitmap Index Scan on ltree_ltr_ix (cost=0.00..4.30 rows=3 width=0)
Index Cond: (d_ltr @ 'A0* & !A04 | Z29'::ltxtquery)
объяснить аналитику что такое A0*&!A04|Z29 гораздо проще чем куча AND OR в условиях WHERE без вдования в подробности в названия колонок
при этом мы как раз такие условия отбора как A0*&!A04|Z29 хранили в отдельной таблице настройке. и для каждого отчета могли быть свои условия.
На мой взгляд, ltree вполне себе unix-way штука, которая решает узкую задачу - удобная и быстрая работа с materialized path. Я с ним познакомился вот по этой серии статей: https://patshaughnessy.net/2017/12/12/installing-the-postgres-ltree-extension и использовал в несколько проектов, в том числе с приличной нагрузкой.
То, что в ней не решается вопрос целостности данных - это тоже вполне себе unix-way. Мы же не обламываемся написать `curl ... | jq` и не говорим, что разработчики curl недоделали свою работу, потому что у них нет встроенного форматирования json?
А статья в целом полезная.
Публикации
PostgreSQL ltree: обеспечение целостности данных