|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
У меня есть пачка скриптов, которые работают с базой данных. Некоторые из этих скриптов используют регулярные выражения, в том числе сложные и громоздкие. Чтобы не указывать их несколько раз в коде, я обычно делаю так: Код: plsql 1. 2. 3. 4. 5. 6. 7.
Это существенно сокращает объем одного запроса, но выражение RE1 приходится повторять в разных запросах и скриптах. А есть ли смысл вложенный подзапрос RE сделать таблицей в БД? Плюсы будут в том, что объем запросов сократиться, и что редактировать шаблон регулярного выражения я буду только в одном месте (в таблице). Минусы будут в том, что очевидно в такой таблице я буду хранить не один запрос, а несколько, поэтому при их использовании нужно будет дополнительно указывать нужный запрос в WHERE. Но это очень условный минус, т.к. фильтр по индексированному полю это как раз то, что БД делает хорошо. Но может быть есть еще минусы, которые я не учитываю? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2019, 12:01 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Alibek B., наверное есть смысл твою пачку скриптов оформить как pipelined function и параметризировать ее так чтоб код не менялся никогда а менялись только входные параметры. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2019, 21:17 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Увы, генератором этой пачки является маркетинг и требования к ним очень разные, не очень логичные и слабо формализуемые. Поэтому универсальный обработчик сделать не получается, всегда появляется что-то новое. Так что обработка в скриптах получается оптимальной, часть логики на БД, часть в скрипте. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2019, 21:51 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Ничего я не понял про твой маркетинг. Приведи 2 максимально разных варианта. Попробуем генерализировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2019, 22:54 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
хранить константу в таблице с константами - нормальная практика. вопрос в том, как эту константу читать и, самое главное, передавать в запрос. cross join из вашего примера - самый простой вариант, но он может на ровном месте сломать вам план запроса. например, в случае с parallel query, при переходе с select * from t where c = 'x' на select * from (select 'x' с from dual) c join t on t.c = c.c вы из воздуха получаете PX SEND BROADCAST (пусть и дешевый), и два slave set вместо одного. альтернативные варианты навскидку: 1) scalar subquery, автоматически кэшируемый на уровне запроса - select * from t where c = (select 'x' from dual) 2) pl/sql функция с result_cache, читающая константу 3) 1+2 4) передать константу в запрос как переменную по возможности я бы остановился на последнем. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2019, 00:24 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
кит северных морей хранить константу в таблице с константами - нормальная практика. В таблицах можно хранить изменяемые параметры. А константы должны быть в коде. С геттерами, при необходимости. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 07:43 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Alibek B., ИМХО Вы уже используете (select '^\s*(\S+)...\s*$' RE1 from DUAL), не вижу огромной разницы в замене на (select r RE1 from my_regular wherу f='RE1' and ... (напр период действия/версия)) если Вам так удобнее будет ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 11:27 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Stax не вижу огромной разницы в замене на Разница будет не для сервера, я для меня. Вместо того, чтобы этот большой шаблон из почти 400 символов указывать несколько раз в разных скриптах, я его вношу один раз в таблицу, а в запросах получаю его из таблицы по PK. Ну и редактирование шаблона упрощается, если это делать в одном месте. Про разницу для сервера указал кит северных морей (возможность неудачного плана при parallel query), я в эту сторону не думал. Правда у меня parallel query не используется, но теперь буду иметь это ввиду. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 11:31 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Alibek B. Stax не вижу огромной разницы в замене на Разница будет не для сервера, я для меня. Вместо того, чтобы этот большой шаблон из почти 400 символов указывать несколько раз в разных скриптах, я его вношу один раз в таблицу, а в запросах получаю его из таблицы по PK. Ну и редактирование шаблона упрощается, если это делать в одном месте. Про разницу для сервера указал кит северных морей (возможность неудачного плана при parallel query), я в эту сторону не думал. Правда у меня parallel query не используется, но теперь буду иметь это ввиду. наскоко помню, у Вас не супер сервер с сотнями процов а вот на длину шаблона я б обратил внимание, кажись она не "безгранична" імхо удобно - то храните в таблице да и никто не мешает сравнить время выполнения с дуал и с Вашей табличкой на глазок разницу не увидете в конце-концов материализовать можно с хинтом "одной строки" cardinality(f 1) ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 11:46 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Stax а вот на длину шаблона я б обратил внимание, кажись она не "безгранична" 512 символов. Но таких больших шаблонов у меня почти нет, в основном шаблоны намного проще. Но все равно, повторять их в разных местах неудобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 12:02 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Если есть большое желание хранить выражения в таблице - это можно. Но вкорячивать выборки в запросы я бы не стал. Если счет выражений не идет на десятки тысяч, то объявите глобальный ассоциативный массив выражений, инициализируемый в секции инициализации пакета. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Использование массива в коде будет примерно таким: Код: plsql 1.
где 'RE1' - идентификатор регулярного выражения rx_table.rx_id К существенным недостаткам метода следует отнести возможность рассогласования кода с текстами выражений - впрочем, это беда всех технологических справочников подобного рода. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 14:55 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Количество выражений будет исчисляться десятками. Но если я понял, предлагается добавить в БД пакет? Я как-то опасаюсь менять в ней метаинформацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 15:10 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
andrey_anonymous, разве прямое обращение к пакетной переменной (rx.re('RE1')) прокатит в SQL? не надо создавать ф-цию? .... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 15:26 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Alibek B. Но если я понял, предлагается добавить в БД пакет? Не обязательно. Но мне показалось, что Вы планировали хранить выражения в БД... т.е. создать там таблицу, вмешавшись в метаинформацию :) Все зависит от того, что и как Вы выполняете. Если только скрипты sql*plus - то просто сделайте скрипт, объявляющий переменные sql*plus, и зовите его из рабочих скриптов. Таблица в этом случае не нужна. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 15:29 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
andrey_anonymous Но мне показалось, что Вы планировали хранить выражения в БД... т.е. создать там таблицу, вмешавшись в метаинформацию :) У меня для всех самоделок и костылей создан отдельный пользователь и в его схеме я и добавляю вспомогательные таблицы и представления, на это моей компетенции хватает. В основной схеме я стараюсь ничего не трогать. Добавление пакетов я считал системной процедурой (глобальной для БД), но оказывается это пользовательская сущность. Попробую поэкспериментировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 15:52 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Elic кит северных морей хранить константу в таблице с константами - нормальная практика. В таблицах можно хранить изменяемые параметры. А константы должны быть в коде. С геттерами, при необходимости. если я назову таблицу не "справочник констант", а "справочник регулярных выражений", где ключом будет служить наименование операции ("выделить город из адреса", и т.п.) - претензия останется? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2019, 20:01 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
кит северных морей если я назову таблицу не "справочник констант", а "справочник регулярных выражений", где ключом будет служить наименование операции ("выделить город из адреса", и т.п.) - претензия останется? А "справочник регулярных выражений" - более менее, если понятным образом заводить константы ключей для обращения к этим выражениям. А это замкнутый круг. Чтобы получить константу результата нужно использовать константу ключа. Но использование литерала в качестве ключа геттера - это неизбежное появление ошибок позднего связывания. Поэтому остаётся лишь дилемма: это константа (управляемая разработчиком) или параметр (управляемый пользователями). У каждого свои геттеры (типизированные). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2019, 08:05 |
|
Есть ли практический смысл хранить константы не в коде, а в таблице?
|
|||
---|---|---|---|
#18+
Elic кит северных морей если я назову таблицу не "справочник констант", а "справочник регулярных выражений", где ключом будет служить наименование операции ("выделить город из адреса", и т.п.) - претензия останется? А "справочник регулярных выражений" - более менее, если понятным образом заводить константы ключей для обращения к этим выражениям. А это замкнутый круг. Чтобы получить константу результата нужно использовать константу ключа. Но использование литерала в качестве ключа геттера - это неизбежное появление ошибок позднего связывания. Поэтому остаётся лишь дилемма: это константа (управляемая разработчиком) или параметр (управляемый пользователями). У каждого свои геттеры (типизированные). Alibek B. - пользователь системи напр шаблон '^\s*(\S+)...\s*$' используется в 5-ти скриптах его надо поменять, надо в каждом изменть если использовать константу 'RE1' ключа ("ФК" на шаблон), то пользователю поменять нужно в одном месте на вопрос темы авторА есть ли смысл вложенный подзапрос RE сделать таблицей в БД? я отвечаю если ето удобно пользователю , то есть імхо надо делать так как удобно пользователю (или переубедить что ето привычка, а не удобство) реализация другой вопрос ...... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2019, 10:27 |
|
|
start [/forum/topic.php?fid=52&msg=39890352&tid=1881842]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 295ms |
total: | 442ms |
0 / 0 |