Как структурировать таблицу для быстрого поиска по большому количеству столбцов - PullRequest
2 голосов
/ 22 сентября 2011

У меня есть таблица с большим количеством столбцов (~ 60), которая в конечном итоге будет иметь большое количество строк (~ 10 000), и мне понадобится возможность эффективно выполнять поиск по нескольким значениям столбцоводнажды.Я не уверен, будут ли результаты поиска с точным соответствием (LIKE 'value', а не LIKE '%value%'), хотя LIKE 'value%' может быть приемлемым компромиссом.

Было предложено несколько решений.Я не очень знаком с принципами проектирования баз данных, поэтому для меня не очевидно, какой из них лучший:

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

  2. Создайте еще одну таблицу для поиска, которая выглядит следующим образом:

    obj_id  col_num  col_name  col_value
    -------------------------------------    
    1       1        'name'    'joe'    
    1       2        'job'     'engineer'    
    2       1        'name'    'bill'
    

    и т. Д.Я думаю, что столбцы col_num и col_name являются избыточными, но, вероятно, один лучше другого.Я понятия не имею, как это называется, хотя это звучит как модель Entity-Attribute-Value (см. Также этот вопрос ).Из того, что я могу сказать, основное отличие от модели EAV состоит в том, что эта таблица не будет разреженной;все объекты будут иметь большинство или все атрибуты.

  3. Создайте другую таблицу для инвертированного индекса в первой таблице.Я знаю, как это сделать в теории, но это будет огромный объем работы.Кроме того, мы, вероятно, потеряем информацию о том, из какого столбца получен каждый элемент данных, что не очень хорошо.Кроме того, кажется, что это будет избыточно с решением 1, но я на самом деле не знаю, как создаются табличные индексы.

Это решения, которые мы придумали такдалеко.Если это уместно, мы используем базу данных Oracle, которая на самом деле не является обязательной, но у меня есть разрешения для рефакторинга базы данных любым необходимым способом.Итак, что является лучшим решением здесь?«Ничего из вышеперечисленного», конечно, не является полностью приемлемым ответом.Ни одна из этих таблиц на самом деле еще не существует, так что нечего стереть и переделать.

Спасибо!

Ответы [ 2 ]

3 голосов
/ 22 сентября 2011

Упомянутые вами примеры действительно лучше подходят для полнотекстового поиска (как предлагает Билл Карвин).Без просмотра (чернового) определения таблицы трудно понять, так ли это на самом деле.

Хорошей новостью является то, что 10K записей - это тривиальная сумма для хорошо настроенного сервера Oracle.Если эта таблица будет самой большой, я бы избежал любых экзотических решений в пользу ремонтопригодности.

EAV в основном превращает логические операторы в огромную боль в задней части и делает поддержку определенных типов данных (текст, даты, числа и т. Д.) Такой же большой болью.

Я бы собрал образец вашей таблицы с вашим лучшим предположением о схеме индексации, заполнил бы ее репрезентативными фиктивными данными и выполнял запросы в соответствии с теми, которые вы ожидаете получить.Измерьте производительность и посмотрите, есть ли у вас проблемы;оптимизируйте свои индексы и запросы и переходите к рефакторингу только в том случае, если это действительно необходимо.

3 голосов
/ 22 сентября 2011

Как насчет использования функций полнотекстового поиска Oracle? Кажется, ваши потребности соответствуют цели для CTXCAT .

См. Индексация с помощью Oracle Text для обзора различных вариантов полнотекстовой индексации в Oracle.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...