Как оформить таблицу нужно на каждом поле? - PullRequest
0 голосов
/ 29 февраля 2012

Теперь я выполнил требование приложения для создания базы данных, которую можно запрашивать для каждого поля.Скажем, в таблице должно быть 30 полей.

|f1 |f2 |f3 |... | f30 |

Интерфейс может запрашивать запросы на основе нескольких или даже всех полей.Например, нужно запросить все строки с помощью f1 == x AND f2 z AND ... AND f30 = abc.

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

Полагаю, это распространенная проблема во многих областях применения.Есть ли какое-нибудь зрелое решение для такого случая?

Ответы [ 2 ]

2 голосов
/ 29 февраля 2012

Вы должны установить его как таблицу пар имя / значение.Одно «поле» для имени поля и одно «поле» для значения.У вас будет третье поле, которое будет «идентификатором записи», связывающим все записи вместе.Так что в вашем примере каждая «запись» будет иметь 30 записей.Тогда вам нужен только 1 индекс для имени поля + значение поля, и вы можете добавить столько «полей», сколько вам нужно, без необходимости изменять структуру таблицы.

1 голос
/ 29 февраля 2012

Индексы реализуют компромисс между пространством и временем.Индекс для каждого столбца

  • занимает больше места на диске,
  • ускоряет некоторые операторы SELECT, а
  • замедляет некоторые операторы INSERT, UPDATE и DELETE (посколькуБД должны поддерживать как индекс, так и строку).

Очень мало пользовательских запросов выберут случайный набор столбцов из вашей таблицы.Вы, вероятно, обнаружите, что два или три столбца есть почти в каждом запросе.Какой-то индекс для этих столбцов ускорит все запросы, которые их используют.Хороший обработчик запросов будет использовать индексы, чтобы изолировать подмножество всех строк, а затем выполнить последовательное сканирование на этом подмножестве для всех неиндексированных столбцов в предложении WHERE.

Зачастую это достаточно быстро для всех.(Тестируйте, не предполагайте.)

Если это не достаточно быстро для всех, вы изучаете планы выполнения запросов и шаблоны пользовательских запросов, проводите некоторые измерения производительности, добавляете еще один индекс и спрашиваете себя,может жить с результатами.Каждый дополнительный индекс будет занимать дисковое пространство, ускорять некоторые операторы SELECT и замедлять некоторые операторы INSERT и DELETE.(Пользователи не часто замечают, как операторы INSERT, UPDATE и DELETE замедляются; обычно они не сильно замедляются.)

В какой-то момент вы можете обнаружить, что SELECTers начинают жаловатьсяо вставках и наоборот.Если вы не готовы рассмотреть более агрессивные улучшения производительности

  • более быстрое оборудование,
  • настройка сервера,
  • перемещение некоторых таблиц или индексов на более быстрые диски,
  • возможно, даже переходя на другую базу данных,

теперь у вас есть политическая проблема, а не техническая.

...