[Delirium]

Можно ли создавать индексы в ежедневно обновляемые таблицы или лучше воспользоваться индексированным представлением »

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

Нужно ли делать первичным ключом автоинкремент »

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

Почитать можно на oszone.net - Статьи по MS SQL (http://oszone.net/4482/Microsoft_SQL_Server)

[zvezda_t]

Вот ведь везде пишут, что:

Индексы повышают производительность операций выборки, но ухудшают производительность при вы- полнении таких операций, как добавление данных, их модификация и удаление. Вызвано это тем, что при выполнении подобных операций СУБД должна еще и динамически обновлять индекс.

А у меня в таблицу в равной степени, и добавляются записи и осуществляется выборка.
Провела анализ запросов с помощью "Помощника по настройке ядра СУБД"
(используя SQL Server Profiler, создала XML-файл трассировки (test.xml), в которую вошли команды Select, Insert и Update. А потом с помощью "Помощника по настройке ядра СУБД" провела анализ, указав в качестве файла рабочей нагрузки test.xml. (кстати это не может изменить мою БД? Команды Insert и Update, при анализе не будут же реально выполняться? )
В итоге рекомендаций по созданию индексов не было.
А вот когда анализировала только команды Select, мне вышел в отчете список некластерных индексов, которые желательно создать.
Как же быть?

[zvezda_t]

И еще позвольте вопрос.
В свойствах индекса, смотрю раздел - Фрагментация.
Заполненность страниц(средний процент полных страниц): 88.11%
Общая фрагментация(процент логической фрагментации, для индекса Heap =0%): 66.67%

Эти параметры плохие? (мне на курсах говорили что процент фрагментации дб<30% так ли это? )

[Busla]

У меня в БД есть таблицы где 20 000 записей »

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

[Delirium]

Согласен с Busla, 20 000 - это мизер для современного железа. Я думаю, что индексация, что представления в данном случае будут работать одинаково. Единственно, можно составить пропорцию соотношения Select и Update/Insert. Если больше выборок, выбираем одно, больше вставок/обновлений - другое.
В любом случае, прироста(да и падения) производительности не будет при таких объемах.

[zvezda_t]

Еще вопрос появился

Уважаемые программисты, как по вашему что правильнее:
в таблице Users
id
series
number
lastname
name
...


1) Сделать первичным ключом автоинкремент(id) и
написать уникальный индекс по полям series,number (паспорт)
2) Написать составной первичный ключ по полям: series,number
?

(у меня Microsoft SQL Server 2005)

[Delirium]

1. Делешь ID первичным ключем с автоинкрементом
2. Делаешь уникальный индекс по полям паспорта.
Таким образом, ты сможешь по ID всегда найти нужную запись + избавишься от проверки внесения дублированных записей по паспорту.

[zvezda_t]

А если у меня совсем нет выборки по id, а всегда поиск по полям series+number. В этом случае нужен первичный ключ по id? сортировка по id увеличит быстродействие в любом случае? или будет лучше сделать только уникальный индекс для series+number?

[zvezda_t]

Уважаемые программисты, разрешите пожалуйста еще вопрос:

итак у меня Microsoft SQL Server 2005.
В таблице dbo.kladr (кладр) для поля code создала уникальный, некластеризованный индекс.

измеряю время выполнения запросов:
1) [sql]SELECT * FROM dbo.kladr WHERE (CODE LIKE '__00000000000') ORDER BY name[/sql]
t=0,2626

2) [sql]SELECT * FROM dbo.kladr WHERE right(CODE, 11) = '00000000000' ORDER BY name[/sql]
t=0,1286

Почему второй запрос быстрее? ведь когда CODE вычисляемое значение, индекс не работает, а значит и запрос дб медленнее, разве нет?