В SQL: поиск ключевых слов в несколько столбцов таблицы


Я хочу выполнить поиск по нескольким столбцам таблицы. Я использую следующий запрос:

select *
from Tabela t
inner join "TabelaPai" tp on tp."ID" = t."RefTabelaPai" and tp."RefProject" = 'projectid'
where not t."Deleted" 
 and (t.Col1 ~ '.*__param1__.*' or t.Col2 ~ '.*__param1__.*' or t.Col3 ~ '.*__param1__.*'
   or t.Col4 ~ '.*__param1__.*' or t.Col5 ~ '.*__param1__.*' or t.Col6 ~ '.*__param1__.*' 
   or t.Col7 ~ '.*__param1__.*' or t.Col8 ~ '.*__param1__.*' or t.Col9 ~ '.*__param1__.*');

Это поиск по ключевому слову __параметр1__ в любом из столбцов, и это хорошо работает.

Но мне не нравится, как этот запрос выглядит. Любые предложения о том, как изменить запрос так это может выглядеть 'красивше' (без этих ~ '.*__параметр1__.*' повторений, например)?

Редактировать: немного контекста о запросе:

Что приводит к этому использования заключается в том, что я могу параметризовать данные в таблице. Например, у меня есть столбец в таблице, где скрипты сохраняются. Мое приложение позволяет пользователям параметризовать скрипт, используя что-то вроде __параметр1__. Если пользователь хочет переименовать параметр, мне придется искать использование параметра в каждый столбец, параметрируемые, и это запрос, который находит где параметр используется.



9462
8
задан 11 мая 2011 в 11:05 Источник Поделиться
Комментарии
3 ответа

Я должен признать, я действительно не понимаю, что случилось с повторением, если он является то, что вы желаете делать (и столбцы не собственно имени Т.Colx!). Если бы я наткнулся на этот запрос в виде проекта, Я знаю, довольно быстро, что он делает, я думаю: ищете кучей столбцов для одного заданное значение (например поиск ФИО, адрес, телефон и т. д. с одной поле поиска, может быть).

Что касается вопроса хранения скриптов и их параметров в базе данных: я, наверное, пойду за второй ключ-значение в таблице, что-то вроде:

scripts { id, name, body }
script_parameters { id, script_id, name, value }

И вы бы принести сценарий и параметров и заменить последнего в первое приложение.

Но тогда, я, наверное, совсем уловили смысл того, что ты пытаешься сделать! :-)

4
ответ дан 27 мая 2011 в 07:05 Источник Поделиться

Что-то "красивше"? И так много повторений вызова для обобщения?

SELECT *
FROM tabela <b>AS t</b>
JOIN "TabelaPai" tp ON tp."ID" = t."RefTabelaPai"
WHERE NOT t."Deleted"
AND tp."RefProject" = 'projectid'
AND <b>t::text</b> LIKE E'%\\_\\_param1\\_\\_%';

Основные моменты:


  • Вы можете ссылаться на составной тип никакого отношения в выберите список. Цитирую инструкцию:


    Всякий раз, когда вы создаете таблицу, составной тип тоже автоматически
    создал с таким же именем, как и таблицы, представлять тип строки таблицы.

    Вы можете бросить весь ряд (составного типа) в его текстовое представление одним махом, который является очень удобный краткий синтаксис. Результирующий фильтр на мой запрос гарантированно найти каждое вхождение во всем подряд.


  • То , как оператор, как правило, быстрее, чем регулярное выражение сопоставления с образцом (~). Регулярные выражения гораздо более сильные, но всякий раз, когда как можно выполнить задание использовать его. Его синтаксис проще, слишком.

  • Подчеркивания (_), имеют особое значение для как оператора, так что вам нужно бежать буквальное _. По умолчанию побег символ \, который также имеет особое значение в побег строковые константы, так что у вас есть, чтобы удвоить выигрыш при использовании е" префикс: е'\\_'.

    Начиная с версии 9.1, установка standard_conforming_strings это по по умолчанию. С помощью этого параметра \ не имеет особого значения в строковые литералы (без электронной приставки) и вам не нужно удвоить их: '\_'.


  • Есть незначительный недостаток / случай: если разделитель в текстовое представление (, по умолчанию, и какие значения заключены в двойные кавычки "), может быть частью поиска образец, там могут быть ложные срабатывания.

Мелкие подчистки / упрощение:


  • Присоединяйтесь стенография для внутреннего соединения.

  • Она чище, писать и тп."RefProject" = 'параметр projectid' а где пункт, так как он не имеет никакого отношения к таблице предложений. Еще можно положить не т."Удален" в условие соединения, а также. В любом случае, вы получите тот же результат.

  • Нет смысла для смешанного дело в бирж (без двойных кавычек). По умолчанию (и без двойных кавычек), все идентификаторы сложены в нижний регистр автоматически. Мой постоянный совет-использовать правовые. нижний регистр идентификаторов исключительно в PostgreSQL и избегать двойного котирования и возможной путаницы.

9
ответ дан 28 декабря 2011 в 09:12 Источник Поделиться

http://www.postgresql.org/docs/current/interactive/textsearch-tables.html#TEXTSEARCH-TABLES-SEARCH

SELECT *
FROM "TAble"
WHERE to_tsvector("QUARTER1"||' '||"QUARTER2") @@ to_tsquery('abc');

выбирает любую строку, которая содержит азбука в столбце КВАРТАЛ1 или КВАРТАЛЕ2

1
ответ дан 25 октября 2013 в 02:10 Источник Поделиться