Как Postgres может представлять собой дерево идентификаторов строк?
Что, наконец, помогло мне очистить (не удалять!) все пакеты apt-get, связанные с mysql, за исключением libmysqlclient16, который был в состоянии де-установки (не уверен, что это такое).
Итак, просто выполните:
dpkg --get-selections | grep mysql
, а затем:
sudo apt-get purge <package_name>
Начните с общего, затем перейдите к клиенту, а затем к серверу.
1 ответ
Правильно ответить: это зависит от вашего варианта использования.
Если ваши деревья очень статичны (суб-узлы меняются не очень часто), то ltree - действительно хороший выбор. Вы можете делать очень быстрые и удобные запросы для узлов и заказов. В этом случае я сделал бы одну корневую ссылку для каждого пользователя, как вы упомянули.
С другой стороны: перемещение поддерева в ltree может заставить вас переписать структуру данных ltld. Например. если у вас есть дерево, например 1.1.1, 1.1.2 и 1.2.1, и вы хотите изменить порядок поддеревьев на первом уровне после корня, все три значения должны изменить свои данные.
Итак, если структура дерева очень динамична, я бы попробовал структуру, о которой вы говорили выше: сохранение родительского узла в списке смежности (и, возможно, индекс для упорядочения), и выполнить запрос с рекурсивными запросами CTE
https://www.postgresql.org/docs/current/static/queries-with.html
https://www.postgresql.org/docs/current/static/queries-with .html
И последнее, но не менее важное: вы можете попробовать его с помощью структуры «вложенных множеств» (https://en.wikipedia.org/wiki/Nested_set_model).
Каждый подход имеет свои собственные преимущества и недостатки. Вы должны сделать очень подробный анализ и, возможно, создать несколько прототипов, чтобы проверить, какой из них лучше для вас.
Дальнейшее чтение:
https: //en.wikipedia .org / wiki / Nested_set_model
https://explainextended.com/2009/09/24/adjacency-list-vs-nested-sets-postgresql/