Деревья.

Ими это деревьями? Все уже реализовано (для mssql и mysql).

Не нравиться интерфейс класса БД? Не вопрос используй свой. Найти и заменить соответствующие вызовы не проблема.

Сформировать запросы, запустить их в нужном порядке, откатить транзакцию при неудаче.

Т.е. везде где мне нужен объект/массив, я должен вместо одной строчки писать две? Это ж копипаста. Проще выделить соответствующий метод. И тогда смысл внутри метода делать $object= (object)$array, когда можно сразу получить нужный результат?

 

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

В идеале - да, но в некоторых местах происходят вычисления на основе измененных данных

0)А я и не заставляю.
1)Не все методы этого интерфейса используются в деревьях.
2)Есть уже готовая реализация и, строго говоря, для базы надо реализовать лишь специфичные методы

 

Ну и что? Я же ее не продаю. =))

Адаптация библиотеки под конкретный класс работы с БД - пара часов.
Создание такой библиотеки с нуля - 20-40 часов.

 

1) Чтобы те у кого возникают вопросы по деревьям могли на конкретном примере понять как можно сделать то или иное действие;
2) Чтобы сообщество указало на ошибки и недочеты библиотеки.
3) Чтобы агрегировать в один топик ссылки на разные полезные ресурсы по деревьям;
4) Чтобы почесать свое самолюбие;

Пара часов - это чтобы другой класс DB прикрутить, а разбираться как с ней работать, в её особенностях, ограничениях, неявных соглашениях и прочей мути придется точно так же как с любой другой библиотекой.

 

1) Почему не поймут? Там вроде не так сильно все запутано. Да и я могу ответить на вопросы, если их зададут.
2) Спасибо.
3) В самом начале я даю ссылки. И я вполне использую этот топик как агрегатор. Я не говорю, что я создал хороший агрегатор, я говорю что этот топик можно так использовать.
4) Возможно.

Задача "как подстроиться под библиотеку" в данном случае мне кажется проще, чем задача "как подстроиться под реляционную бд".

 

Разница в способе хранения. По ссылкам в первом сообщении вроде все есть.

Это если надо выбрать. А если надо перенести поддерево от одного родителя к другому, вот тут все и начинается.

В Nested Sets данные извлекаются на ура. Вот изменения данных это уже задачка.
В Redundant Adjacency List извлекаются так же просто, и немного проще изменяются.
В Adjacency List легко изменить родителя, легко работать со всем деревом, а вот с поддеревьями уже не удобно.

Но т.к. в основном идет выборка, то Nested Sets оказываются удобнее Adjacency List.
Redundant Adjacency List столь же удобен, но занимает больше места для хранения дерева (и, по идее, требует больше памяти для обработки).

Понятия не имею. Использую то, что удобнее в конкретном случае.

Имея библиотеку типа той что в данном топике, можно замерить время выполнения операций и посмотреть на какой схеме хранения данных программа работает быстрее.

 

Добавил как вариант.

 

Для поддержания биогеоценоза и управления сложностью.

 

Чтоб животные и растения жили, и чтоб программы были проще и понятнее.