|
|
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
Хочу посоветоваться в решении прикладной задачи. Свой вариант написал, работает точно и быстро, но есть ощущение, что можно сделать "красивее". Есть абстрактная система CRM, в ней список служб (продуктов) в иерархической форме. Код: 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. Есть список комбинаций продуктов. У меня ключом для комбинаций используются полные пути, так обеспечивается точность иерархии. Мой вариант происходит из excel-таблицы, составленной архитекторами и BA, возможно это повлияло на способ решения задачи. В принципе, список комбинаций может быть в любой форме, главное чтобы сохранились коды (имена) продуктов, их расположение в иерархии отосительно друг друга, была возможность добавлять дополнительные ключи (напр.: параметр продукта из другой таблицы, его состояние, и т.п.). Максимальное количество продуктов в комбинации ограничено и точно известно. В примере их четыре (далее будет понятно, почему это важно), но в реальности - их всего десять. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Комбинации могут частично пересекаться - MAP_1 и MAP_2 похожи, в MAP_2 на один продукт больше. В таких случаях при выборе используются параметры map_group и map_depth, выбирается максимальная "глубина" для совпадающей группы. Задача - найти в списке продуктов в рамках одного дерева точные комбинации в соответствии со списком, а также продукты, для которых комбинаций не нашлись. Прикладное применение - миграция из одной системы в другую, комбинации продуктов из старой системы превращаются в другие комбинации в новой, на основании таблиц, составленных бизнесом и архитекторами. Моё решение - совпадения проверять по строке пути и точному количеству строк. Делаю вспомогательную табличку: Код: plsql 1. 2. 3. Главный select. Немного громоздкий, но достаточно быстрый. Найденные комбинации разворачиваются в одну строку пивотом (отдельные столбцы для каждого продукта), и полученный результат фильтруется по map_group и map_depth. Код: 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. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. Если на вход подать сразу несколько миллионов строк, то он будет или тормозить или переполнит temp_segment. Как самостоятельный селект он используется только для проверки единичных вариантов. В боевом исполнении он встроен в parallel pipelined функцию, на вход получает от одного до сотни клиентов. С таким количеством справляется влёт. Но я продолжаю ломать голову - нет ли другого, более элегантного решения поиска заданных комбинаций в таблице? Может кто-то решал что-то подобное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2017, 12:13 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
Никто? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 11:13 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, multiset? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 12:19 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovЗадача - найти в списке продуктов в рамках одного дерева точные комбинации в соответствии со списком, а также продукты, для которых комбинаций не нашлись. Код: plsql 1. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 13:49 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop Код: plsql 1. ? Так получается список вообще всего, полного совпадения и неполного. Нужно только полное совпадение комбинации, например для root_id = 1 не подходит MAP_2, так как отсуствует один из четырёх продуктов этой комбинации - '|ROOT1|PROD13'. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 15:21 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, Цель найти root_id для каждого map, при этом root_id считается подходящим если его дети содержат все пути для конкретного map? Если для одного map подходит более одного root_id - какой берем? rpovarovУ меня ключом для комбинаций используются полные пути, так обеспечивается точность иерархии.Пути (составленные из prod_name) в твоей иерархии неуникальные, о каком ключе может быть речь? rpovarovПрикладное применение - миграция из одной системы в другую, комбинации продуктов из старой системы превращаются в другие комбинации в новой, на основании таблиц, составленных бизнесом и архитекторами.Так меняется иерархия или связи родитель-потомок остаются как есть, а меняются атрибуты сущности (пусть даже все атрибуты, включая имя)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 19:15 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopЦель найти root_id для каждого map, при этом root_id считается подходящим если его дети содержат все пути для конкретного map? Если для одного map подходит более одного root_id - какой берем? В обратном направлении - цель найти все map_id для дерева под одним root_id. В системе одна бизнес-служба (как её видит бизнес-аналитик) состоит из нескольких "технических" продуктов. К примеру, комбинация MAP_1 из трёх продуктов (ROOT1, PROD11 и PROD12) может быть интернет-тарифом, пусть будет INTERNET_STANDARD. А то же самое, но с ещё одним дополнительным PROD13, даёт комбинацию MAP_2, которая для бизнес-аналитика - интернет с телевидением, пусть будет INTERNET_IPTV. Бизнес придумал обновить CRM и всё это перенести в новую систему. Там всё по другому, миграции один к одному не получится. Поэтому миграция будет проходить на уровне бизнес-служб, которые в новой системе уже сами развернутся как надо, по своим правилам. И вот бизнес-аналитики с другими специалистами по продуктам составляют огромную Excel таблицу, в которой перечислены все существующие в старой системе комбинации продуктов и как они складываются в службы. Из такой таблицы после обработки в результате получится prod_map. Задача - получить список MAP_1, MAP_2, ... MAP_N для каждого отдельного подписчика (будем считать, что один клиент имеет всего одно дерево продуктов, тогда root_id - это ключ, который однозначно идентифицирует клиента). Должно быть полное совпадение списка продуктов из конфигурации MAP_x, например, если есть |ROOT1 и |ROOT1|PROD12, но нет |ROOT1|PROD11, то нет и совпадения. Продукты, для которых не нашлась комбинация, надо найти и показать бизнес-аналитикам, чтобы они решили, что с ними делать. Как вариант, чтобы выпустили новую обновлённую версию prod_map. Т.е. на входе у нас prods, а на выходе получаем список MAP_x и информацию о тех продуктах, для которых MAP_x не нашлись. Не должно остаться ни одного забытого продукта. dbms_photoshopПути (составленные из prod_name) в твоей иерархии неуникальные, о каком ключе может быть речь? Ключ, наверное, не совсем правильное слово. Путь - это идентификатор, показывающий однозначное иерархическое подчинение продукта. Потому что один и тот же продукт с кодом PROD11 может находится как под ROOT1, и тогда это будет одна служба, так и под ROOT2 или ROOT3, и тогда это будет совсем другая служба и другой тариф. А вот комбинация путей (набор строчек под единым MAP_x) должна быть уникальная. dbms_photoshopТак меняется иерархия или связи родитель-потомок остаются как есть, а меняются атрибуты сущности (пусть даже все атрибуты, включая имя)? Меняется вообще всё. Из старой системы надо вытащить данные и поднять их на бизнес-уровень, как список служб (т.е. map_id). Который на следующем шаге превратится в исходные данные для создания этих служб в новой системе. Или в репорт качества данных, или ещё во что-нибудь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 21:32 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovВ обратном направлении - цель найти все map_id для дерева под одним root_id.+ отсутствующие продукты из маппинга. Код: 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.05.2017, 05:31 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarov, Учись формулировать проще и без лишней шелухи. В твоем сообщении 8 раз встречается слово "бизнес". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 05:34 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshoprpovarov, Учись формулировать проще и без лишней шелухи. В твоем сообщении 8 раз встречается слово "бизнес". :) Это локальный сленг, мы так называем внешнюю стихийную силу, раздающую нам указания ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 06:43 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop+ отсутствующие продукты из маппинга. Код: plsql 1. 2. 3. 4. 5. 6. В этом варианте отсутствующие продукты относительно одной конкретной комбинации, а нужно относительно всех найденных. В варианте root_id = 10 бесхозным остался только продукт 42, потому что 31 используется в MAP_2, 41 в MAP_3 и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 10:21 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovdbms_photoshop+ отсутствующие продукты из маппинга. Код: plsql 1. 2. 3. 4. 5. 6. В этом варианте отсутствующие продукты относительно одной конкретной комбинации, а нужно относительно всех найденных. В варианте root_id = 10 бесхозным остался только продукт 42, потому что 31 используется в MAP_2, 41 в MAP_3 и т.д. Объяснять это явно не твой конек. Если бы в голове была ясная картина, то и объяснить было бы просто и запрос написать. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 11:53 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopОбъяснять это явно не твой конек. Если бы в голове была ясная картина, то и объяснить было бы просто и запрос написать. Может и так. Мне казалось, что в самом первом сообщении написал понятно, плюс ещё исходники. Комбинации могут частично пересекаться - MAP_1 и MAP_2 похожи, в MAP_2 на один продукт больше. В таких случаях при выборе используются параметры map_group и map_depth, выбирается максимальная "глубина" для совпадающей группы. Задача - найти в списке продуктов в рамках одного дерева точные комбинации в соответствии со списком, а также продукты, для которых комбинаций не нашлись. В любом случае твой вариант интереснее и чище. Спасибо! Вот он же с пивотом и фильтрацией по map_depth. Код: 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. Я его ещё проверю на боевой конфигурации, потом поделюсь впечатлениями. И за "outer join partition by" отдельное спасибо, этот вариант джойна вообще прошёл мимо меня, пойду читать документацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2017, 14:46 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
Усложняем. Вылез вариант, когда может быть параллельно несколько одинаковых ветвей под одним корнем. Код: 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. На выходе, соответственно, должны получиться три ветви с map_id = MAP4 (и продукты 8 и 9 как unmapped). Уже всю голову сломал, как от себя отделить эти ветви. Если получится размножить корневой продукт отдельно к каждой ветви, повесить на всю ветвь какой-нибудь id, то потом этот id можно прописать в "... over(partition by..." рядом с root_id, и всё должно сработать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 18:20 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovУже всю голову сломал, как от себя отделить эти ветви. Если получится размножить корневой продукт отдельно к каждой ветви, повесить на всю ветвь какой-нибудь id, то потом этот id можно прописать в "... over(partition by..." рядом с root_id, и всё должно сработать.Ну ты был близок. А в чем проблема размножить? Либо self join по like (как в примере ниже) либо строить дерево сначала от корня, а потом к корню. Идея та же, только использовано размноженное дерево вместо оригинального (super_tree instead of product_tree) и добавлен leaf_id в логику. Код: 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. 71. 72. 73. 74. 75. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 20:17 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopНу ты был близок. А в чем проблема размножить? Либо self join по like (как в примере ниже) либо строить дерево сначала от корня, а потом к корню. Проблема, как всегда, в ДНК :) Я раньше подобные задачи решал нахрапом черед PL/SQL, но практика показала, что чем больше запихнуть в SQL (в разумных пределах), тем лучше и быстрее в результате всё работает. Но мозги перестраивать силком надо... Спасибо за пример! Завтра погоняю на работе, может ещё что найду интересного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 20:30 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovdbms_photoshopНу ты был близок. А в чем проблема размножить? Либо self join по like (как в примере ниже) либо строить дерево сначала от корня, а потом к корню. Проблема, как всегда, в ДНК :) Я раньше подобные задачи решал нахрапом черед PL/SQL, но практика показала, что чем больше запихнуть в SQL (в разумных пределах), тем лучше и быстрее в результате всё работает. Но мозги перестраивать силком надо... Спасибо за пример! Завтра погоняю на работе, может ещё что найду интересного.Это хорошо, что ты перестал заниматься глупостями. Я закончил свое исследование разумных пределов SQL vs PL/SQL, надеюсь до конца недели выложить. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 20:38 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopЭто хорошо, что ты перестал заниматься глупостями. Я закончил свое исследование разумных пределов SQL vs PL/SQL, надеюсь до конца недели выложить. :) Была одна задачка, которая чистым SQL не решалась совсем или решалась с огромным геморроем и ограничениями. Тоже обход дерева, но нет прямой иерархии, она строится на ходу в зависимости от того, что нашлось в каждой ветке. Конфигурация была написана для Java-кода в бэкенде, и он там успешно работает. Потребовалось его повторить, но прямо над базой данных. Обход дерева рекурсией в PL/SQL, но там, где ситуация позволяет, скармливаю таблицы в SQL. В результате довольно быстро работает (если распараллелить), и побочным эффектом вывод в логи или на экран всего построенного дерева с комментариями :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 20:53 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovБыла одна задачка, которая чистым SQL не решалась совсем или решалась с огромным геморроем и ограничениями. Тоже обход дерева, но нет прямой иерархии, она строится на ходу в зависимости от того, что нашлось в каждой ветке. Конфигурация была написана для Java-кода в бэкенде, и он там успешно работает. Потребовалось его повторить, но прямо над базой данных. Обход дерева рекурсией в PL/SQL, но там, где ситуация позволяет, скармливаю таблицы в SQL. В результате довольно быстро работает (если распараллелить), и побочным эффектом вывод в логи или на экран всего построенного дерева с комментариями :)Описывая свой "любимый говнокод" своими же ощущениями наивно полагать встретить понимание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 21:06 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovнет прямой иерархии, она строится на ходу в зависимости от того, что нашлось в каждой веткеЭто наводит на мысль, что на SQL было бы уместнее решать с помощью rec with чем connect by. А я имею в виду, что есть случаи, когда PL/SQL предпочтительнее базового SQL без ухищрений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2017, 22:40 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopИдея та же, только использовано размноженное дерево вместо оригинального (super_tree instead of product_tree) и добавлен leaf_id в логику. Если в дереве и prod_map попадается комбинация, где несколько последних в цепочке продуктов на одном уровне Код: plaintext 1. 2. 3. но при этом нет параллельных ветвей, то получается интересно :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. Два "хвоста" образовали каждый свою ветку по leaf_id. При этом, если присутствуют параллельные ветки, то всё в порядке Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Немного поправил product_tree и super_tree, размножаю только множественные случаи Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Результат Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Весь код Код: 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. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 15:00 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovДва "хвоста" образовали каждый свою ветку по leaf_id. При этом, если присутствуют параллельные ветки, то всё в порядке Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Откуда тут взялось 8 строк вместо шести?? Выше в примере два листа грубины три. 3*2=6. rpovarovНемного поправил product_tree и super_tree, размножаю только множественные случаиКакое отношение этот фикс имеет к реальной жизни? Или, говоря твоим сленгом, какое бизнес правило говорит, что надо "размножать только множественные"? Больше похоже либо на костыль либо для кривых данных либо от недопонимания принципа работы. Это как некоторые разработчики которые не хотят вникать до конца почему запрос возвращает дубли просто засовывают в него distinct и не парятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 15:24 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, Этих строчек не было в исходном примере. Я проверял скрипт на боевых таблицах, и нашёл комбинацию, при которой вылезает косяк. Оформил это в виде нового примера и запостил вместе со своим костылём. То, что в старой системе было в одном экземпляре, в новой тоже будет в одном. Например, тариф. Если было несколько одинаковых веток, то и в новой тоже будет столько же. Например, несколько сим-карт к одному тарифу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 16:23 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
rpovarovdbms_photoshop, Этих строчек не было в исходном примере. Я проверял скрипт на боевых таблицах, и нашёл комбинацию, при которой вылезает косяк. Оформил это в виде нового примера и запостил вместе со своим костылём. То, что в старой системе было в одном экземпляре, в новой тоже будет в одном. Например, тариф. Если было несколько одинаковых веток, то и в новой тоже будет столько же. Например, несколько сим-карт к одному тарифу.Я не говорил про исходный пример. Я ссылался на последнее сообщение. Еще раз, откуда у тебя взялось 8 вместо 6. Код: 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. Касательно костылей, нормальный подход как раз отличается от костыля тем, что данные приводятся в нужную форму до применения логики. А говнокод - это когда начинает что-то вылазить неожиданное и не учтенное во входных данных, а разработчик пытается от этого избавиться в процессе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 16:39 |
|
||
|
Поиск комбинаций строк в таблице
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, В сообщении 20521106 , где начали решать проблему одинаковых ветвей, пример был упрощённый, из трёх продуктов. Моя ошибка. Если бы взял конфигурацию для четырёх продуктов из самого первого сообщения - было бы правильнее. "Хорошая мысля приходит опосля..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 16:52 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39461829&tid=1885749]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
156ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 251ms |
| total: | 530ms |

| 0 / 0 |
