|
|
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, Было бы намного понятнее, если бы ты в моем последнем запросе просто подставил данные на которых он возвращает не то, что ты ожидаешь. Мне не совсем понятно что не так, хотя если твое решение тебя вполне устраивает, на этом можно и зарешить. По числу отвечающих в этой ветке ты можешь сделать определенные выводы про умение просто подавать информацию и доступно объяснять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 17:31 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopБыло бы намного понятнее, если бы ты в моем последнем запросе просто подставил данные на которых он возвращает не то, что ты ожидаешь. Мне не совсем понятно что не так, хотя если твое решение тебя вполне устраивает, на этом можно и зарешить. Прошу прощения, что не сразу отвечаю. Не успеваю иногда. Пытался разобраться, почему у меня на, казалось бы, одинаковых данных выходят разные результаты. Подготовлю входные данные, которые должны будут покрыть все спорные варианты, и вернусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 11:03 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
Возвращаюсь с новым решением. Основной проблемой было то, что при нескольких экземплярах одного и того же продукта нужно отделить эти экземпляры уникальным ключом так, чтобы в эту выделенную ветку попали также корневой продукт и остальные одиночные продукты (это важно для дальнейшего "опознания" комбинаций). Решил разделить super_tree из предыдущих попыток на два отдельных шага. В результате получается так: 1. Первый проход по дереву, строим product_path и unique_path, считаем количество повторений product_path. 2. Проход по результату из п.1 рекурсивным селектом, ищем повторяющиеся ветки. Как только наткнулись - вешаем на ветку идентификатор branch_id, и обозначаем им все остальные продукты ниже в этой ветке. Теоретически ниже может быть ещё одно разветвление с повтором (в реальных данных такого не встречается), оно игнорируется. 3. Для всех повторяющихся веток размножаем корневые и неповторяющиеся продукты. Наверняка можно совместить шаг 1 и 2 в один, но я пока не придумал как. Исходная таблица Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. После применения super_tree Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2017, 11:48 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, А какую задачу ты сейчас решаешь? Получить для каждого листа всех его родителей? Тогда можно взять мой запрос тут 20524387 и добавить в него выделенное. Код: plsql 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. Семь листьев глубины три и один глубины два итого 7*3+1*2=23 строки. Это ожидается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 01:44 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshoprpovarov, А какую задачу ты сейчас решаешь? Получить для каждого листа всех его родителей? ... Тогда можно взять мой запрос тут 20524387 и добавить в него выделенное. Семь листьев глубины три и один глубины два итого 7*3+1*2=23 строки. Это ожидается? Если идти от листьев, то каждый лист генерирует свою собственную ветку, это неправильно. В последнем примере продукты PROD121 и PROD122 оба являются листьями и находятся в одной ветке на одинаковом уровне под общим родителем PROD12. Они так и должны остаться вместе в одной ветке. Т.е. должно получиться не две: Код: plaintext 1. 2. 3. 4. 5. 6. а одна: Код: plaintext 1. 2. 3. 4. В примере три экземпляра продукта PROD12, они ближе всего к корню, значит с них и начинаем делить. В результате должно получиться три полные ветви для каждого из PROD12, и одна "дефолтная" для остальных продуктов, не попадающих в те три ветви. Вот ещё один боевой пример прямо из базы (привязок нет, NDA не нарушается), в нём куча "листьев" Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Если его подставить в твой пример, то листья сгенерируют 10+ веток, а их на самом деле всего три (две для продуктов OP0801, и одна общая). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 11:26 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovВ примереВроде мой последний запрос возвращает то же количество строк, что и твой последний. Можно, конечно, допилить с учетом новых хотелок, но есть подозрение, что ты уже пытаешься реализовать то, что делать не надо. В конце концов, тебе виднее, что за логику надо реализовать. Если будут конкретные вопросы - спрашивай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 11:53 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopВроде мой последний запрос возвращает то же количество строк, что и твой последний. Если подставить "боевой", то количество строк разное, в твоём больше (48 против 28). Но количество строк в принципе не так важно, основная проблема в том, что ветки разбиваются и потом не совпадают с map-таблицей. dbms_photoshopМожно, конечно, допилить с учетом новых хотелок, но есть подозрение, что ты уже пытаешься реализовать то, что делать не надо. В конце концов, тебе виднее, что за логику надо реализовать. Если будут конкретные вопросы - спрашивай. Последняя версия кода вроде делает всё что нужно. По крайней мере, пока ещё не наткнулся на вариант, где она лажает. Благодаря твоим вариантам и моим попыткам их доработать нашлись и были исправлены другие местные косяки в данных и map-таблицах :) Вопрос, собственно, такой - можно ли как-то совместить эти две конструкции в одну (и есть ли в этом смысл с точки зрения оптимизации)? В первой считаются пути и их количество для выявления нескольких экземпляров одного продукта, во второй на основании этого количества генерируется параметр branch. Код: plsql 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. И ещё один вопрос, который тут не обсуждался, но связан с темой. В части, выделенной красным цветом - я правильно надеюсь на short-circuit evaluation, и при выполнении условия pm.param_key is null Оракл не пойдёт дальше и не будет выполнять селект из второго условия? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 12:28 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovВопрос, собственно, такой - можно ли как-то совместить эти две конструкции в однуОтвет: rec with там вообще не нужен. rpovarovЕсли идти от листьев, то каждый лист генерирует свою собственную ветку, это неправильно. В последнем примере продукты PROD121 и PROD122 оба являются листьями и находятся в одной ветке на одинаковом уровне под общим родителем PROD12. Они так и должны остаться вместе в одной ветке.Что значит на одной "ветке"? Имеется в виду пути до листьев полностью совпадают? Ну так это поведение по умолчанию connect by выведет всех родителей по разу и каждый лист по разу и ты получаешь. rpovarov Код: plaintext 1. 2. 3. 4. Когда ты это ясно сможешь для себя сформулировать, тогда и запрос сам собой напишется. rpovarovВопрос, собственно, такой - можно ли как-то совместить эти две конструкции в однуЛюбители абсолютной строгости рекомендуют прибегать к case. 20384658 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 13:07 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
В последней цитате должен быть второй вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 13:16 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopНепонятно уже надо тебе что-то размножать или нет и если надо, то при каких условиях. Когда ты это ясно сможешь для себя сформулировать, тогда и запрос сам собой напишется. Ну я же привёл рабочий пример в 20563070 . Этот код делает сейчас именно то, что нужно. В случае нескольких экземпляров одного и того же продукта генерируются полные ветки для них и обозначаются идентификатором branch_id. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 13:22 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, Ммм... то, что делает твой запрос понятно только тебе. Хотя, подозреваю, если ты посмотришь на него через год и тебе будет вообще непонятно что это за 'x' и что курил аффтар. Код: plaintext 1. 2. Код: plaintext 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. Зачем продукт с ид 7 и 8 продублированы по 4 раза? Почему продукт с ид 1 тоже продублирован именно 4 раза? Почему ветку "идентифицируют" два айдишника независимо от глубины. и т. д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 14:12 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Если отсортировать по другому, то так понятнее. Код: plaintext Продукты 8 (PROD2) и 9 (PROD22) не принадлежали веткам с multi-instance продуктами, но они могут быть важны для идентификации службы. Например, если служба описана как комбинация продуктов ROOT1, PROD12, PROD121, PROD122, PROD2, то, не включив PROD2, я теряю всю службу. Дупликаты продуктов не мешают, они отфильтровываются на конечном этапе. Ветка идентифицируется через unique_path продукта с multi-instance, ближайшего к корню. В примере это PROD12, он на втором уровне, поэтому branch_id состоит из двух элементов. Если разветвление будет на третьем уровне, то branch_id будет из трёх элементов ("боевой" пример как раз такой). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 14:39 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopХотя, подозреваю, если ты посмотришь на него через год и тебе будет вообще непонятно что это за 'x' и что курил аффтар. Борюсь с этим явлением щедро рассыпая комментарии и пояснения в коде :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 14:42 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, У тебя логика завязана на второй уровень и не надо создавать иллюзии, что размножение будет корректным при любой ветвистости и дубликатных путях. Учитывая сказанное "размножение" опять таки достигается путем self join только условие соединения более замысловатое. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:20 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshoprpovarov, У тебя логика завязана на второй уровень и не надо создавать иллюзии, что размножение будет корректным при любой ветвистости и дубликатных путях. У меня как раз уровень вычисляется динамически, берётся первый, где нашлись дубликаты. Для этого и делался второй проход with rec. Например, вот ветвление на третьем (|PR0103|OP0807|OP0801): Код: plsql 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. Код: plaintext Можно даже оба набора исходных данных (со вторым и третьим уровнем) слить воедино, и скрипт правильно отработает: Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2017, 17:41 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39472229&tid=1885749]: |
0ms |
get settings: |
6ms |
get forum list: |
22ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
166ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 453ms |

| 0 / 0 |
