|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
miksoft, Ну для себя - решил везде где можно использовать таблицу связей... в реальности она больше таблицы узлов раза в 3 для питовых задач (из моих)... а Мускуль вполне нормально переваривает таблицы в 10 миллионов записей, особенно таких (из трех полей)... там, кстати нет серъезного ограничения на множественность родителей узла. :) Если не проходит вариант с таблицей (много сильно глубоких деревьев), то или вариант "а" с запросом через переменные или разбивка на несколько таблиц (где-то в ваших ссылках есть вполне нормальное описание про фиксированное вложение каталогов)... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2012, 18:32 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
miksoftвроде бы, MySQL вообще не имеет специализированных решений и способов для хранения и обработки иерархических структур данных. В ответвлении MariaDB есть "движок" для графов - OQGRAPH, но с готовые бинарники его включают не во все, т.к. он основан на boost довольно высокой версии. Кроме того, по отзывам пользователей, на больших масштабах (порядка млн узлов) скорость работы неудовлетворительная. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2012, 11:53 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Топик, в котором родилось решение для написания иерархических запросов. /topic/984179 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 16:23 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
miksoft, пасибки. Поисследовал этот вопрос ишо раз. Вот "тот самый" запрос о котором писал впервые тут 12858390 "поизвращавшись с переменными" (дали добро): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Фактически он не отличается от решения bochkov'а, но работает чуть медленнее. Общий недостаток обоих решений - строковый результат и сложность (я бы сказал неудобство) его использования в дальнейшем. Феноменальные "тормоза" этого решения вызываются необходимостью подселекта на каждом шаге выполнения... В ряде относительно простых случаев (ограничения на структуру таблицы), подходит вот такое "скоростное" решение: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
оно также НЕ избегает фулл-скана, но уже только индекса и НЕ содержит некешируемых подселектов... собственно никаких не содержит. Это вариант "чистого" курсора. ... 1. "поизвращавшись с переменными" ещё немного, можно во втором варианте также сделать удаление ненужных узлов из накапливаемого массива @array. ... 2. "поизвращавшись с переменными" можно слегка улучшить первый вариант, устранив подселект для конечных листьев, где он дает гарантированно пустой результат. Вообще-то их - много, и как правило больше чем рабочих веток. Общий итог: нормального (на одном статическом запросе), полностью рабочего решения для деревьев с одним полем `parent_id` -- нет. Или надо делать динамически вложенные join-ы , или надо делать фулл-скан с подселектом, что очень медленно , или надо специально готовить табличку , или надо запрещать перенос старых узлов (с малым идентом), в новые и глубже вложенные ветки (с бОльшими идентами)... Не надо ТАК делать. Для себя - как вопрос "самообразования" - задача интересна, но и только. Везде где можно, заменил на нормальную и полноценную таблицу связи. Пусть уж жрет память, чем тормозит не по-детски. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2012, 07:49 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Никаких "фул сканов", выбираются только строки потомков. Результат в строковой переменной @branch, в виде идентификаторов всех членов ветви, разделенных запятой. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2013, 19:13 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
DBConstructor Никаких "фул сканов" , выбираются только строки потомков.А разве Find_in_set умеет использовать индексы? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2013, 21:21 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
tanglirDBConstructor Никаких "фул сканов" , выбираются только строки потомков.А разве Find_in_set умеет использовать индексы? Извини, не понял вопроса. Причем тут индексы? Это один из вариантов, использующий строку в качестве хранения идентификаторов членов ветви. Но этот вариант, благодаря тому, что подзапрос с группировкой и объединением идентификаторов потомков перестает возвращать строки в случае, если идентификаторы всех членов ветви уже находятся в переменной @branch, не использует "фул скан" и выполняет ровно то количество итераций, которое необходимо для получения результата. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2013, 22:07 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
DBConstructor, я имел в виду, что, хотя этот запрос может и не добраться до конца таблицы и тем самым "снаружи" фулскана, скорее всего, не получится, но подзапрос в EXISTS будет фулсканить таблицу `Catalog`, т.к. Find_in_set-у никакие индексы тут не помогут. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2013, 06:06 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
tanglir, не вижу большой разницы между выборкой всех страниц индексов связывания двух таблиц с последующим совмещением этих индексов и последовательной проверкой значения одного поля одной таблицы с константной строкой. Мне, почему-то даже кажется, что второе будет быстрее первого. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2013, 08:22 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
DBConstructor, протестил: 1. Таблица 10 деревьев по 1 листу в уровне, всего 300 уровней (3000 записей всего!) 2. Решение Бочкова дает выборку от 0,5 до 1 сек. 3. Решение с составным индексом (моё тут последнее) дает 50-80мсек. 4. Ваше решение проработало больше (уже 705сек и ещё пашет)... сколько точно - не знаю. как-то так. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2013, 22:37 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109, а конкретно, всё банально: подселект выполняется также как и в варианте Бочкова, только там есть ещё группировка и сортировка... и применить индексы - практически некуда. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2013, 23:03 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109Arhat109, а конкретно, всё банально: подселект выполняется также как и в варианте Бочкова, только там есть ещё группировка и сортировка... и применить индексы - практически некуда. Нет, не банально! Простой пример: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
Таким образом, получаем таблицу с произвольным уровнем вложения и произвольным количеством одноуровневых потомков одного предка. Если после заполнения таблицы у потомков не менялись предки на предков с идентификатором старше, чем идентификатор потомка, то следующий запрос дает результат за один проход и очень быстро: Код: sql 1. 2. 3. 4. 5.
Как видно, на моем домашнем железе запрос отработал за 16 миллисекунд. /* 0 rows affected, 1 rows found. Duration for 1 query: 0,016 sec. */ Выводы? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2013, 16:26 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Надо только задать интересующих предков в переменной @branch. К примеру: Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2013, 16:32 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109DBConstructor, протестил: 1. Таблица 10 деревьев по 1 листу в уровне, всего 300 уровней (3000 записей всего!) 2. Решение Бочкова дает выборку от 0,5 до 1 сек. 3. Решение с составным индексом (моё тут последнее) дает 50-80мсек. 4. Ваше решение проработало больше (уже 705сек и ещё пашет)... сколько точно - не знаю. как-то так. :) У нас не получится повторить опыты друг друга, ввиду слишком разных условий их проведения. Попробуй на своей таблице, с одинаковыми для предыдущих тестов условиями, следующий вариант: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Результат будет в переменной @branch ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2013, 20:24 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Немного усложнил свой вариант, чтобы чуть-чуть сравнять условия опыта, и прогнал оба алгоритма: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
Первый алгоритм отработал в 4 раза быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2013, 21:09 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
DBConstructorArhat109DBConstructor, протестил: 1. Таблица 10 деревьев по 1 листу в уровне, всего 300 уровней (3000 записей всего!) 2. Решение Бочкова дает выборку от 0,5 до 1 сек. 3. Решение с составным индексом (моё тут последнее) дает 50-80мсек. 4. Ваше решение проработало больше (уже 705сек и ещё пашет)... сколько точно - не знаю. как-то так. :) У нас не получится повторить опыты друг друга, ввиду слишком разных условий их проведения. Попробуй на своей таблице, с одинаковыми для предыдущих тестов условиями, следующий вариант: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Результат будет в переменной @branch Только сегодня заметил. В переменной @branch оказывается только исходное значение "3" за 46мсек. Увы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2013, 23:58 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Тут приведен код тестового примера и результаты сравнений: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 00:05 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109, была слеплена такая вот процедура, в которой ненужный код (на момент проверки) просто тупо комментился. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 00:07 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109, Во втором примере очепятка, следует читать 0.021 .. 0.08 sec. Неправильно перевел 21 .. 80 миллисекунд в секунды. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 00:09 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109, последний пример запускался три раза с одним временным результатом. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 00:11 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109, Лицензионное соглашение короткое: "Пользуйтесь на здоровье!" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 00:12 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Arhat109Только сегодня заметил. В переменной @branch оказывается только исходное значение "3" за 46мсек. Увы. Я малость тупанул. Забыл написать, что после "SET @branch = ..." надо еще "SET @exists = 1;" В конечном варианте: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 00:48 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
Развитие темы Bochkov'а с небольшим увеличением производительности: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 01:00 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
И наконец, самое быстрое решение - решение "молния": Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Как говорится, ENJOY! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 02:39 |
|
FAQ: Древовидные структуры средствами MySQL или роман Стендаля "Красное и Черное"
|
|||
---|---|---|---|
#18+
DBConstructor, Потестил в той куче данных: selected = 301 items by 0.7 .. 0.93 sec. Нисколько оно не "скоростной вариант". Точно такой же. :) 1. Справедливости ради: тема - моя и работают у меня эти запросы уже больше года, Бочков самостоятельно(!) нашел решение, которое я тогда не мог выложить. И самое быстрое решение - это: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Кстати, почему вы так любите Find_in_set()? LOCATE() -- существенно быстрее. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.02.2013, 10:16 |
|
|
start [/forum/topic.php?fid=47&startmsg=37877186&tid=1830048]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 156ms |
0 / 0 |