Как правило, базы данных спроектированы так, как показано ниже, чтобы разрешить несколько типов для сущности.
Имя объекта
Тип
Дополнительная информация
Имя сущности может быть чем-то вроде номера счета, а тип может быть похож на сбережения, текущие и т. Д. В базе данных банка, например.
В основном type будет некой строкой. Может быть дополнительная информация, связанная с типом объекта.
Обычно запросы ставятся так.
Найти номера счетов этого конкретного типа?
Найти номера счетов типа X с балансом больше 1 миллиона?
Чтобы ответить на эти запросы, анализатор запросов будет сканировать индекс, если индекс связан с конкретным столбцом. В противном случае он выполнит полное сканирование всех строк.
Я думаю об оптимизации ниже.
Почему бы нам не сохранить хеш или целочисленное значение данных каждого столбца в фактической таблице, чтобы свойство упорядочения сохранялось, чтобы его было легко сравнивать.
Имеет следующие преимущества.
1. Размер таблицы будет намного меньше, потому что мы будем хранить небольшие значения размера для каждого столбца данных.
2. Мы можем построить кластерный индекс дерева B + по значениям хеш-функции для каждого столбца, чтобы получить соответствующие строки, совпадающие или большие или меньшие, чем некоторые значения.
3. Соответствующие значения могут быть легко извлечены с помощью индекса дерева B + в основной памяти и извлечения соответствующих значений.
4. Редкие значения никогда не нужно будет извлекать.
У меня все еще много оптимизаций. Я опубликую их на основе отзывов на этот вопрос.
Я не уверен, что это уже реализовано в базе данных, это всего лишь мысль.
Спасибо, что прочитали это.
- Бала
Обновление:
Я не пытаюсь подражать тому, что делает база данных. Обычно индексы создаются администратором базы данных. Я пытаюсь предложить физическую схему, имея индексы для всех полей в базе данных, чтобы уменьшить размер таблицы базы данных и легко отвечать на несколько запросов.
Обновления: (ответ Джо)
Как добавление индексов в каждое поле уменьшает размер базы данных? Вам все еще нужно хранить все истинные значения в дополнение к хешу; мы не просто хотим запросить существование, но хотим вернуть фактические данные.
В типичной таблице будут храниться все физические данные. Но теперь, генерируя хеш-значение для каждого столбца, я сохраняю только хеш-значение в фактической таблице. Я согласен, что это не уменьшает размер базы данных, но уменьшает размер таблицы. Это будет полезно, когда вам не нужно возвращать все значения столбца.
Большинство РСУБД теперь эффективно отвечают на большинство запросов (особенно при наличии ключевых индексов). Мне трудно формулировать сценарии, в которых ваша база данных будет более эффективной и сэкономит место.
В таблице может быть только один кластеризованный индекс, а все остальные индексы относятся к некластеризованным индексам. При моем подходе у меня будет кластеризованный индекс для всех значений базы данных. Это улучшит производительность запросов.
Размещение индексов в физических данных - это не имеет смысла. Ключом к эффективности индексов является то, что каждый индекс хранится в отсортированном порядке. Как вы предлагаете делать это через любое возможное поле, если они хранятся только один раз в своей физической структуре? В конечном итоге фактические строки должны быть отсортированы по чему-либо (например, в SQL Server это кластеризованный индекс)?
Основная идея состоит в том, что вместо создания отдельной таблицы для каждого столбца для эффективного доступа мы делаем это на физическом уровне.
Теперь таблица будет выглядеть так.
Row1 - OrderedHash (Column1), OrderedHash (Column2), OrderedHash (Column3)