Индексное представление по сравнению с индексами на таблице
Почему реализация что-то уже реализованное? Используйте Ehcache.
Однако , если сторонние библиотеки полностью вне рассмотрения, я предполагаю, что Вы надеетесь реализовывать структуру данных, которая выглядит примерно так:
- В основном HashMap (расширяется
HashMap, если Вы будете) - , Каждое значение в Карте указывает на объект в отсортированном списке, на основе которого больше всего используется.
- Объекты, недавно используемые, добавляются к заголовку списка -
O(1) - Производящий чистку последний использованный, означает усекать конец списка -
O(1) - , Все еще дает Вам поиски Карты, но все еще сохраняет недавно используемые объекты сначала...
5 ответов
Индексированное представление вызовет те же проблемы, что и индекс для столбца, потому что для индексированных представлений требуется с привязкой схемы , которая напрямую привязывает его к таблице, не позволяя вам изменять / изменение схемы этой таблицы любым способом, формой или формой. Сюда входит изменение размера столбца (например, с varchar (50) до varchar (255) ), изменение типа данных столбца (например, с double на decimal (18,5) ) и т. Д. Я видел, как они вызывают много неожиданных головных болей из-за этого факта.
Я предлагаю настроить хранимую процедуру или пакет SSIS, который будет создавать таблица отчетов для вас, которая запускается каждый час или около того. Таким образом, вы можете проиндексировать этот вечно любящий ад и наслаждаться всеми преимуществами производительности, которые он дает. Я стесняюсь делать репортажи из действующей, незавершенной системы. На самом деле я еще не видел случая, когда это необходимо. В целях отчетности для выполнения работы обычно бывает достаточно информации за час.
Я думаю, что это все равно повлияет на производительность, поскольку индексы в материализованном представлении необходимо обновить точка - вероятно, это не обязательно должно быть синхронно с записью в таблицу.
Лично я бы сам поместил индексы в таблицу и измерил бы производительность записи. Вы можете догадываться, насколько медленнее будет запись с указанными там индексами, но пока вы на самом деле не измеряете это, вы просто размышляете. Это может вообще не иметь большого значения.
Not if your are going to be writing to if often, as you'd have the performace cost of the index on your materialised view. Materialised Views are more for data that doesn;t change often.
Я столкнулся с похожей проблемой. Решил добавить многоколоночный индекс вопреки совету администратора базы данных. На моей машине разработки и на сервере (с разрешением администратора базы данных) производительность записи увеличилась, а создание отчетов было значительно быстрее (в 17 раз), чем создание индексов для отдельных столбцов. Почему, я не знаю, так как я не администратор базы данных, но я знаю основы, и иногда это помогает вам видеть сквозь лес / деревья. Поэтому я согласен с Эриком Пертрелье, вы должны добавлять индексы и измерять производительность записи и даже измерять производительность чтения.
«В столбцах источника и описания необходимо искать подстроки».
Когда вы выполняете поиск подстрок в столбцах varchar (), SQL Server не будет использовать какие-либо индексы. (Даже если вы реплицируете таблицу и создать индексы) Индексы не используются, если в начале строки поиска используется дикий символ.
Думаю, лучше создать полнотекстовый указатель на «Источник» и «Описание», если вам нужно искать в них подстроки.
Я предлагаю создать полнотекстовый индекс для столбцов varchar () и сделать отслеживание изменений вручную и запускать его каждый час или около того, когда нет DML ... что уменьшит нагрузку на INSERT заявления