|
|
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Добрый день. Возникла необходимость транскрибировать часть поля при запросе, а с какой стороны подойти к этому вопросу, чтобы было как можно менее затратно - ума не приложу. Поясню на примере: есть текстовое поле Name в таблице names, значения которого такого вида: 15нл, 123жд, 900ф... До вчерашнего дня использовался такой запрос: Select n.name from names n where.... Результатом было, естественно, значение поля без изменений. А вчера возникла необходимость кроме простого выдёргивания получать ещё и транскрибированные значения этого поля, т.е. чтобы вместо озвученных значений были вот такие: 15nl, 123zhd, 900f. Как этого достичь малой кровью? Была мысль создать таблицу транскрибирования (a=а, б=b, ... я=ya) - но как внутри запроса побуквенно выдёргивать это всё? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2013, 10:33:38 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
andrew_jr20но как внутри запроса побуквенно выдёргивать это всё?Написать свою функцию транскрибирования, потом andrew_jr20Select n.name, transcribe(n.name) as name_t from names n where.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2013, 10:48:51 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
tanglirandrew_jr20но как внутри запроса побуквенно выдёргивать это всё?Написать свою функцию транскрибирования, потом andrew_jr20Select n.name, transcribe(n.name) as name_t from names n where.... Спасибо - получается, что я ошибся немного в формулировке, поискал примеры функции "транслитерирования", и нашёл как раз то, что нужно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2013, 13:51:33 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
andrew_jr20, Интересно: нашли транслитерацию силами Мускуля или на клиенте? А то я как раз вчера сделал запросом с разбором строки на символы и свертку обратной группировкой. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2013, 14:50:31 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Arhat109сделал запросом с разбором строки на символы и свертку обратной группировкой В соответствии с ГОСТ 7.79-2001? так выложил бы код - на FAQ тянет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2013, 15:26:53 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Arhat109andrew_jr20, Интересно: нашли транслитерацию силами Мускуля или на клиенте? А то я как раз вчера сделал запросом с разбором строки на символы и свертку обратной группировкой. :) Мускулем, вот тут взял пример (2 способ), и напильничком прошёлся, чтобы под мои нужды подошло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2013, 16:59:13 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Akina, пока не могу... через полгода не раньше. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 07:14:46 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Akina, да, и не знаю насчет "в соответствии"... у нас была транслитерация на клиенте... а мне понадобилось доливать данные запросом в табличку... ну вот и "воспроизвел" ту, которая была... за полчасика. :) Похоливарить: Решения на циклах в SQL - мне вообще не нравятся... это как костыль в Реляционной Алгебре для "хромоногих" (спецов от ЯП). Причем, в ЯП - это нормально и приветсвуется, как ни странно. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 07:25:06 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Arhat109Решения на циклах в SQL - мне вообще не нравятсяТак и задача не скл-ная, в общем-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 08:05:24 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
tanglir, Ну не совсем скульная, конечно... да, в общем-то извращение это всё. Такие задачи надо решать на клиенте. Проще, дещевле и быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 08:13:35 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Ну в рамках мускуля можно и UDF нарисовать. Задача-то - почти чистый XLAT... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 09:04:50 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Arhat109Akina, Похоливарить: Решения на циклах в SQL - мне вообще не нравятся... это как костыль в Реляционной Алгебре для "хромоногих" (спецов от ЯП). Причем, в ЯП - это нормально и приветсвуется, как ни странно. :) :) Оно и понятно, что почти все варианты только костылями и получится воспроизвести, и цикл - один из таких костылей, который по быстродействию да по накладным расходам, я так думаю, будет всё-таки быстрее, чем по каждому чиху по таблицам лазить - тут на входе строка, внутри эта строка гоняется в цикле (больше нигде не нашёл варианта, чтобы без цикла можно было обойтись), на выходе строка, "при съёмках фильма ни одна таблица не пострадала" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 10:06:34 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
andrew_jr20, а похоливарим (три дня убил на пустую задачу, блин). :) дело в том, что tanglir - прав. Эта задача не совсем для Скуля и РА. По-хорошему, она должна решаться на клиенте силами ЯП... но иногда надо, да и лепить разовую обработку на ЯП для уже имеющейся БД иногда просто "лениво"... :) В РА - любые решения на явных циклах - свисток в сторону "косяк". По одной простой причине: РА - это набор операций над множеством данных. То есть "по определению" - циклическая обработка, которая прошита непосредственно в базовых операциях. В частности, при реализациях на каких-нибудь не Фон Неймановских архитектурах, понятие "цикл" может совсем отсутствовать. И это - нормально для реляционной алгебры в целом. Все решения циклами (и ХП в т.ч.) в этом случае - отдыхают. Как пример, давайте пофантазируем на предмет "голографической" памяти, где поиск по ассоциативному ключу выдает сразу "весь набор записей" без каких-либо циклов... и? "цена реализации" имитирования циклических алгоритмов будет просто фантастической. :) ... в то же самое время, скульные решения - будут работать и офигительно просто: "дай мне то, что имеет такой ключик, добавь к нему по этой части выборке как ключики и оставь только такие, где..." как итог: ЯП и Скуль - это два совершенно разных подхода к обработке данных. "То что русскому хорошо, немцу - смерть" - как нельзя применимо. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 12:10:07 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Akina, по-хорошему, да. Неплохо бы иметь расширенный набор встроенных функций обработки текстовых строк, в т.ч. и XLAT(). Тут много чего не хватает... увы. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 12:13:05 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
Arhat109andrew_jr20, а похоливарим (три дня убил на пустую задачу, блин). :) дело в том, что tanglir - прав. Эта задача не совсем для Скуля и РА. По-хорошему, она должна решаться на клиенте силами ЯП... но иногда надо, да и лепить разовую обработку на ЯП для уже имеющейся БД иногда просто "лениво"... :) В РА - любые решения на явных циклах - свисток в сторону "косяк". По одной простой причине: РА - это набор операций над множеством данных. То есть "по определению" - циклическая обработка, которая прошита непосредственно в базовых операциях. В частности, при реализациях на каких-нибудь не Фон Неймановских архитектурах, понятие "цикл" может совсем отсутствовать. И это - нормально для реляционной алгебры в целом. Все решения циклами (и ХП в т.ч.) в этом случае - отдыхают. Как пример, давайте пофантазируем на предмет "голографической" памяти, где поиск по ассоциативному ключу выдает сразу "весь набор записей" без каких-либо циклов... и? "цена реализации" имитирования циклических алгоритмов будет просто фантастической. :) ... в то же самое время, скульные решения - будут работать и офигительно просто: "дай мне то, что имеет такой ключик, добавь к нему по этой части выборке как ключики и оставь только такие, где..." как итог: ЯП и Скуль - это два совершенно разных подхода к обработке данных. "То что русскому хорошо, немцу - смерть" - как нельзя применимо. :) Ну про смерть-то уж загнули! :) Не настолько же там всё "плохо". Тем более всегда всё зависит от конкретной ситуации: например, в моём случае есть 2 нюанса: 1 - циклы будут в 2-4 шага (очень короткие входные строки - никогда не будет на входе 50-100-символьных параметров, которые заставят по каждому запросу колотить эту цикличность), 2 - клиент, который будет это всё запрашивать, мне неизвестен - может там php, может perl,а может что-то настолько низкоуровневое, что может только отсылать запросы, получать набор данных и пересылать их дальше - я без понятия, но перекладывать то, о чём меня попросил заказчик, на него обратно, я просто не могу - поэтому пришлось взвалить всё именно на сервер, и уже на нём выбирать - какой способ предпочтительнее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 13:04:21 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#18+
andrew_jr20, 1. выбирать "как есть" и отдавать на клиента. Там сами разберутся. 2. вот и меня "Заказчик попросил"... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 14:02:38 |
|
||
|
транскрипция в SELECT
|
|||
|---|---|---|---|
|
#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. 44. 45. 46. 47. 48. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2014, 14:18:51 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38211334&tid=1834956]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 195ms |
| total: | 330ms |

| 0 / 0 |
