How to become an author
Search
Write a publication
Pull to refresh

Comments 22

А где же вариант «использовать более подходящую бизнес требованиям субд»? в данном случае, очевидно, стоило реляционную заменить на графовую
Total votes 2: ↑1 and ↓10
Что? Использовать отдельную СУБД для комметов только? Зачем увеличивать сложность системы, если можно просто немного подумать?
Total votes 2: ↑2 and ↓0+2
Количество «древовидных» моделей будет только увеличиваться. Дерево комментариев, граф друзей, таксономия разделов и тд и тп. Зачем в этих условиях вообще связываться с реляционными субд — ума не приложу.
Total votes 2: ↑0 and ↓2-2
Вы не совсем правы.

Современные реляционные СУБД вполне позволяют хранить в реляционной форме описание иерархических структур и делать по ним выборки. Тут рекомендую почитать про рекурсивные запросы. Не уверен поддерживает ли их MySQL но если даже нет то это проблема одного продукта а не всех реляционных баз.
This comment wasn’t rated yet0
Можно пример такого рекурсивного запроса?
This comment wasn’t rated yet0
www.postgresonline.com/journal/archives/131-Using-Recursive-Common-table-expressions-to-represent-Tree-structures.html
www.postgresql.org/docs/8.4/static/queries-with.html
habrahabr.ru/post/73700

можно найти и больше инфы.

Кроме того, я видел как такие вещи довольно успешно применяются в «энтерпрайзе», то есть это не отдельная малоизвестная фитчя.
This comment wasn’t rated yet0
Вы имеете ввиду что-то типа этого?

-- PostgreSQL --
WITH RECURSIVE temp1 ( "ID","PARENT","DESCRIPTION",PATH, LEVEL ) AS (
SELECT T1."ID",T1."PARENT", T1."DESCRIPTION", CAST (T1."ID" AS VARCHAR (50)) as PATH, 1
    FROM KPO T1 WHERE T1."PARENT" IS NULL
union
select T2."ID", T2."PARENT", T2."DESCRIPTION", CAST ( temp1.PATH ||'->'|| T2."ID" AS VARCHAR(50)) ,LEVEL + 1
     FROM KPO T2 INNER JOIN temp1 ON( temp1."ID"= T2."PARENT")      )
select * from temp1 ORDER BY PATH LIMIT 100

Сколько времени вам потребуется, чтобы понять, что тут происходит и где ошибка?

-- OrientDB --
select id , parent , description , $path , $depth from (
	traverse child from (
		select from kpo where id = 'KPO'
	)
)

А тут?
This comment wasn’t rated yet0
Если честно то имея опыт работы с первым я вполне понимаю что там происходит. И симметрично — я не представляю как работает второй пример. Хотя я не берусь утверждать что разобравшись с OrientDB не переменю свое мнение.
This comment wasn’t rated yet0
А если все перечисленное выше — дай бог 10% функциональности проекта?

Зачем в данном случае связываться с нереляционными СУБД — ума не приложу.
Total votes 1: ↑1 and ↓0+1
Можно пример такого проекта?
This comment wasn’t rated yet0
Ой ли?

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

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

— последние публикации сотни пользователей с максимальным рейтингом из такого-то региона

— список тэгов проставленных публикациям, в которых такой-то пользователь хотя бы один комментарий добавил в избранное

Страшно даже представить эти SQL запросы :-)
Total votes 1: ↑0 and ↓1-1
Это элементарные запросы, и если у вас проблемы с SQL, не надо тут свое профанство выпячивать.
Total votes 3: ↑2 and ↓1+1
Для того чтобы использовать графовую базу данных в проекте, нужно иметь разработчиков, которые с ней умеют работать.
This comment wasn’t rated yet0
Вы так говорите, будто этому учиться нужно пару лет :-)
This comment wasn’t rated yet0
А где сравнение производительности?
Что-то мне подсказывает что апдейтить индексы на больших деревьях быстрее(для nested set), чем вставлять тысячи строк на каждую новую, а на небольших количествах данных (до 10 тысяч) разница мне кажется несущественна.
Total votes 1: ↑1 and ↓0+1
Интересно, что мешает добавить к полям Nested Sets еще parent и level и получить неограниченно масштабируемую структуру с преимуществами обоих моделей — и NS и AL? (Ну, кроме произвольной сортировки, ОК)
Всегда считал такой подход «золотым стандартом» для хранения древовидных структур. Я ошибаюсь?
Total votes 1: ↑1 and ↓0+1
А зачем хранить parent? Родителя можно получить по ключам left и right.
Сам использую Nested Sets для хранения дерева сайта, level нужен в моем случае, чтобы не крутить рекурсию для построения меню сайта, дерево сайта получается из одного запроса бд и одного цикла программного.
Total votes 1: ↑1 and ↓0+1
Для того, чтобы в любимой ORM можно было написать что-то вроде 

'relations' => [
  'parent' => ['type' => 'belongsTo', 'model' => self::class, 'by' => '__parent_id']
]


и затем иметь возможность 
$this->parent;
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr