Вопрос о значимости порядка поле в индексной ноде.

[mazzy]

Цитата:

Сообщение от Skvorcal

А как лучше поступить в следующей ситуации...

Есть таблица, в таблице куча полей, но 99% запросов фильтруют данные по двум полям.
При этом 33% запросов фильтруют данные по одному полю, 33% запросов фильтруют данные по другому полю, а оставшиеся 33% запросов фильтруют данные по двум полям одновременно.

В такой ситуации лучше построить два отдельных индекса по каждому полю, или один индекс по двум полям?

Если у вас MS SQL...
и если в нем включено автосоздание индексов...
то ничего не делайте.

подождите немножко, а потом посмотрите что MS SQL насоздавал.
потом примете решение.

[Skvorcal]

Цитата:

Сообщение от _scorp_

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

Что-то типа того...

Цитата:

Сообщение от _scorp_

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

OLAP не подходит по двум причинам:
1. Слишком дорого и муторно разворачивать OLAP ради одного-двух отчетов.
2. Отчет является оперативным. Его формируют по нескольку раз в день и отслеживают тем самым исполнение операций. Плюс некоторое планирование...

Цитата:

Сообщение от _scorp_

P.S. И вообще, конечно, отчеты лучше строить по проводкам.

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

Цитата:

Сообщение от mazzy

Если у вас MS SQL...
и если в нем включено автосоздание индексов...
то ничего не делайте.

подождите немножко, а потом посмотрите что MS SQL насоздавал.
потом примете решение.

А разве при очередном обновлении приложения (обновляем слоем, а не проектами) и последующей синхронизации словаря Аксапта не удалит все неаксаптовые индексы?

[AraraT®]

Цитата:

Сообщение от Skvorcal

...
А разве при очередном обновлении приложения (обновляем слоем, а не проектами) и последующей синхронизации словаря Аксапта не удалит все неаксаптовые индексы?

Может имелось ввиду:
http://msmvps.com/blogs/gladchenko/a...3/1311293.aspx

тогда можно на основе рекомендаций сделать индексы в АОТе.

Или есть еще какой-нибудь другой механизм?

[_scorp_]

Цитата:

Сообщение от Skvorcal

1. Слишком дорого и муторно разворачивать OLAP ради одного-двух отчетов.

Если у вас есть SQL Server у вас есть и AS. Ничего докупать не нужно. По поводу пары отчетов - если пользователи "распробуют" эти отчеты, они потом только такие и будут просить

Цитата:

Сообщение от Skvorcal

2. Отчет является оперативным. Его формируют по нескольку раз в день и отслеживают тем самым исполнение операций. Плюс некоторое планирование...

Ну если отчет оперативный, то тут уже конечно ничего не сделаешь...

Цитата:

Сообщение от Skvorcal

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

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

Цитата:

Сообщение от Skvorcal

А разве при очередном обновлении приложения (обновляем слоем, а не проектами) и последующей синхронизации словаря Аксапта не удалит все неаксаптовые индексы?

Я думаю, что Сергей имел ввиду стандартный инструмент SQL Server Database Engine Tuning Adviser. Нужно сначала с помощью SQL Server Profiler собрать рабочую нагрузку для базы в файл или в таблицу. При этом работа рабочей базы замедлится, т.к. можно сказать что все запросы (ну или те которые вы выберете для сбора) будут логироваться. Потом на тестовой базе данных, идентичной рабочей, нужно запустить Tuning Adviser, указав в качестве нагрузки собранный лог. Какое-то время он будет "колбаситься", а потом выдаст свои советы по модификации статистик и индексов на таблицах. Его советы нужно хорошо взвешивать, т.к. если насоздавать все индексы которые он предлагает создать, например, на InventTrans, то как бы от его советов не стало худо. Если же вы согласны с его советом, то индекс нужно вручную создавать средствами AX.