|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
У меня есть список адресов в виде строки. Формат строки регламентирован, возможны следующие варианты: <Город>; <Улица>, <Дом>, кв. <Номер>[; Комментарии] — для многоквартирного дома <Город>; <Улица>, <Дом>, (офис|кабинет) <Место>[; Комментарии] — для коммерческих зданий <Город>; <Улица>, <Дом>[; Комментарии] — для не многоквартирного дома (секция с комментарием опциональна) Мне нужно посчитать общее количество зданий (домов), а затем определить количество многоквартирных домов и коммерческих зданий. Дом будет считаться многоквартирным, если по указанному адресу имеется хотя бы одна квартира. Если квартир нет, но есть несколько адресов с разными "местами", то здание будет считаться коммерческим. Уникальные адреса будут считаться частными домами. Эти результаты можно получить, сделав два уровня вложений запросов — на 2 уровне будет парсинг адреса с помощью regexp_replace, на 1 уровне будет классификация адреса (признаки МКД, частного дома или коммерческого здания), а на верхнем уровне будет группировка. Либо это можно сделать без подзапросов или с одним уровнем вложений, используя более сложные выражения группировки. Как лучше сделать (исключая вариант с нормализацией адреса)? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:11 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
на 2 уровне будет парсинг адреса с помощью regexp_replace, на 1 уровне будет классификация адреса Мой выбор. Предпочитаю читаемость производительности, за редкими исключениями. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:58 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Мне кажется regexp это не совсем про "парсинг" Я изначально бы брал PL/SQL, а не пытаясь все сделать одним запросом. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 13:28 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
В моем решении я бы объединил парсинг и классификацию, т.к. полный парсинг дорого для определения только типа. Эвристика сойдёт. Select * from buildings b where b.type_id=1 Если можно добавить виртуальное поле в таблицу/представление, или Select * from buildings b where GetBldgType(b.row)=1 если нельзя. Я использовал оба решения. Второе считается более медленным из-за контекстных переключений, но я этого не замечал. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 17:00 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Я изначально бы брал PL/SQL, а не пытаясь все сделать одним запросом. Я бы тоже так сделал, тем более что результат всегда можно выдать табличной функцией, еще бы добавил статус успешного/неуспешного парсинга, потому что если в записи мусор ее тоже нужно как то учитывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 18:50 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Alibek B. Либо это можно сделать без подзапросов или с одним уровнем вложений, используя более сложные выражения группировки. Как лучше сделать (исключая вариант с нормализацией адреса)? Лучше, можно, более сложные выражения группировки не нужны, пример: Код: 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.
Парсинг добавьте сами, если достаточно нахождения вхождений в строку ', кв.' или ', офис' или ', кабинет', то и регулярные выражения не нужны. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 12:56 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
graycode Парсинг добавьте сами, если достаточно нахождения вхождений в строку ', кв.' или ', офис' или ', кабинет', то и регулярные выражения не нужны. Код: 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.
Функция выполняется 3 x число строк в таблице. А так 1 x число строк в таблице: Код: 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.
А если не пользуясь недокументированным MATERIALIZE: Код: 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.
А вообще-то нужно смотреть насколько сложна логика определения типа и если не очень то чистый SQL чтобы не тратить время на context switch. А уж совсем правильно было бы просто добавить поле "Тип Здания" (либо calculated либо с BEFORE INSERT OR UPDATE триггером) плюс индекс. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 13:55 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#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.
Тут 3 Fire будет ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 14:37 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
booby Тут 3 Fire будет Ты всерьез думаешь у всех квартир, офисов, частных домов один адрес? SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 14:59 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
booby, Код: 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.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 15:03 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
SY booby Тут 3 Fire будет Ты всерьез думаешь у всех квартир, офисов, частных домов один адрес? SY. Конечно нет по всем позициям сразу. Я только в текст конкретного запроса смотрю. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 15:13 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
booby Я только в текст конкретного запроса смотрю. А надо-бы смотреть на текст конкретного запроса в контексте заданной задачи. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 16:38 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
SY, в контексте задачи, для предотвращения трехкратного выполнения функции на строке, достаточно deterministic на функции. тогда Код: plsql 1. 2. 3. 4. 5. 6. 7.
хорошо сработает. Но сама задача - "парсинг строки адреса" мне сейчас не интересна. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 16:48 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
SY, оставил на закуску)) по идее функция определения типа адреса не должна для одного и того же адреса давать разные результаты, т.е. она зависит только от входного параметра и больше ни от каких других факторов не зависит и ее можно объявить детерминированной. Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 17:28 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Если есть простое правило определения типа здания, то выдумывать вообще ничего не нужно Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
SY А вообще-то нужно смотреть насколько сложна логика определения типа и если не очень то чистый SQL чтобы не тратить время на context switch. А уж совсем правильно было бы просто добавить поле "Тип Здания" (либо calculated либо с BEFORE INSERT OR UPDATE триггером) плюс индекс. SY. А совсем совсем правильно было бы парсить на входе и раскладывать валидные данные в табличку со структурой для распрасенного адреса, включая поле тип здания, а не валидные, в виде строки в другую таблицу для дальнейшего анализа. Но поскольку постановка задачи неизвестна, не будем усложнять)) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 18:02 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Вы неправильно прочитали условие. count (и даже count distinct) не дадут правильного результата. Как минимум нужна оконная функция count по "адрес дом", потому что в МКД на первом этаже могут быть коммерческие помещения, в адресе которых не будет номера квартиры. У меня, собственно, вопрос можно свести к такому - стоит ли серьезное усложнение запроса и снижение читаемости (если не использовать подзапросы) выгоды в производительности и эффективности. Завтра покажу первый вариант, с подзапросами. На рабочих данных он выполняется за терпимое время и я как раз думаю, сколько я выгадаю, если избавлюсь от подзапросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 20:51 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
То, что оптимизатор сам умеет переписывать запросы Вы не слышали? Что SELECT * FROM dual, что SELECT * FROM (SELECT * FROM.... dual)))))))))) для Oracle будет одно и то же. AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 21:19 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Alibek B. count (и даже count distinct) не дадут правильного результата. Как минимум нужна оконная функция count по "адрес дом", потому что в МКД на первом этаже могут быть коммерческие помещения, в адресе которых не будет номера квартиры. Т.е. если по адресу есть квартира и офис то все равно многоквартирный дом и если есть адрес без квартиры и тот-же адрес с офисом то это все равно частный дом. Тогда: Код: 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.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 21:50 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
Alibek B., Процедурно в один проход по отсортированной выборке: Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 01:14 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
SY select max(...) addr_type Хорошая идея, я не сообразил, использовал оконные функции. graycode Процедурно в один проход по отсортированной выборке: Спасибо, процедурно я бы и сам осилил, но предпочитаю запросы на чистом SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 10:45 |
|
Вопрос по вложенным запросам
|
|||
---|---|---|---|
#18+
SY , спасибо за идею. Сменил оконную функцию на обычную агрегатную, избавился от одного уровня вложенности, запрос стал работать существенно быстрее. Текущий запрос: Код: 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.
Примеры исходных данных: ADDRESSГород; ***н**, 51; ч/дГород; ***ябрьск**, 346, кв. 80; п. 2, эт. 10Город; ***о**, 23, каб. 241; г-ца ***Город; ***о**, 23, каб. 249; г-ца ***Город; ***ахоно**, 39, кв. 65; п. 2, эт. 8Город; ***ахоно**, 46; эт. 2Город; ***дународн**, 117, кв. 11; п. 1, эт. 3Город; ***жданск**, 24, кв. 88; п. 3, эт. 3Город; ***сск**, 11/АГород; ***ернациональн**, 16, кв. 143; п. 4, эт. 9Город; ***ра Алие**, 20, кв. 5; п. 1, эт. 2Город; ***ла Марк**, 112, кв. 6; п. 1, эт. 2Город; ***сноармейск**, 52, кв. 16; п. 1, эт. 5Город; ***и**, 83/А, кв. 15; п. 1, эт. 4Город; ***пск**, 75, кв. 40; п. 4, эт. 5Город; ***ябрьск**, 317/А2, кв. 72; п. 2, эт. 6Город; ***сск**, 11/А; эт. цокольныйГород; ***якуло**, 36/АГород; ***сноармейск**, 52, кв. 59; п. 4, эт. 4Город; ***сомольск**, 27, кв. 31; п. 1, эт. 6Город; ***олюционн**, 30; ч/дГород; ***вропольск**, 45, кв. 28; п. 2, эт. 4Город; ***сомольск**, 27, кв. 16; п. 1, эт. 3Город; ***якуло**, 13/А, кв. 6; п. 1, эт. 1Город; ***дународн**, 176, кв. 35; п. 1, эт. 9Город; ***дународн**, 85, кв. 91; п. 4Город; ***окубанск**, 17; ч/дГород; ***казск**, 30, кв. 33; п. 2, эт. 4Город; ***ра Алие**, 20, кв. 28; п. 2, эт. 5Город; ***азинн**, 26Город; ***инн**, 32; ч/дГород; ***ахоно**, 41, кв. 111; п. 4, эт. 1Город; ***оди**, 86Город; ***оди**, 86/АГород; ***ла Марк**, 112, кв. 141; п. 4, эт. 9Город; ***ла Марк**, 112, кв. 57; п. 2, эт. 6Город; ***вомайск**, 100/4; ч/дГород; ***ернациональн**, 16/А, кв. 70; п. 2, эт. 9Город; ***и**, 63, кв. 27; п. 1, эт. 5Город; ***ябрьск**, 32, кв. 101; п. 3, эт. 6Город; ***окубанск**, 24; ч/дГород; ***ла Марк**, 101, кв. 108; п. 3, эт. 8Город; ***ябрьск**, 32, кв. 109; п. 3, эт. 8Город; ***сомольск**, 27, кв. 49; п. 1, эт. 9Город; ***жданск**, 56, кв. 17; п. 2, эт. 1Город; ***иден**, 142, кв. 45; п. 3, эт. 5Город; ***ошило**, 47, кв. 9; п. 1, эт. 3Город; ***ябрьск**, 32, кв. 73; п. 2, эт. 9Город; ***пск**, 86, кв. 56; п. 2, эт. 4Город; ***о**, 22; АдвокатыГород; ***ябрьск**, 317/А2, кв. 78; п. 2, эт. 7Город; ***и**, 54, кв. 6; п. 1, эт. 2Город; ***оди**, 45/А, кв. 24; п. 2, эт. 1Город; ***оди**, 65, кв. 36; п. 4, эт. 1Город; ***якуло**, 20, кв. 32; п. 1, эт. 8Город; ***сомольск**, 27, кв. 29; п. 1, эт. 6Город; ***монавт**, 49/В, кв. 52; п. 2, эт. 5Город; ***сск**, 14, кв. 19; п. 2, эт. 2Город; ***сноармейск**, 52, кв. 56; п. 4, эт. 3Город; ***ричн**, 107/А, кв. 8; п. 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 11:04 |
|
|
start [/forum/topic.php?fid=52&fpage=36&tid=1880857]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 145ms |
0 / 0 |