Индексы, Состовные первичные ключи, Индексация представлений

[zvezda_t]

Здравствуйте, уважаемые программисты :)

Подскажите пожалуйста, как быть в такой ситуации:

У меня в БД есть таблицы где 20 000 записей, причем ежедневно добавляются новые записи и также осуществляется выборка данных в виде отчетов.

1) Можно ли создавать индексы в ежедневно обновляемые таблицы или лучше воспользоваться индексированным представлением?
2) Нужно ли делать первичным ключом автоинкремент?
Понимаю что трудно ответить не видя БД, подскажите пожалуйста где можно почитать просто и доступно об индексации?

Заранее большое спасибо.

[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) SELECT * FROM dbo.kladr WHERE (CODE LIKE '__00000000000') ORDER BY name
t=0,2626

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

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

[Delirium]

Оператор LIKE при поиске ищет все подряд, не обращая внимания на индекс. Особенно это заметно если писать LIKE '%текст%'.
А во втором случае идет жесткое количество символов и нет необходимости просматривать все подряд, потому и работает быстрее.

[zvezda_t]

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

[Delirium]

zvezda_t, ну будет у тебя первичный ключ, и пусть себе будет, не будет он тормозить твою базу в любом случае :)
И уникальный индекс тоже не помешает в данном случае.

Вообще, у тебя какая стоит задача, оптимизировать быстродействие или создать рабочую базу?
В случае небольшого (до 100 000 записей) количества записей быстродействие будет нормальным что с ключом, что без :)

[zvezda_t]

Delirium, базу я уже создала там порядка 20000 записей, но она с большой скорость растет. Поэтому сейчас моя задача оптимизировать быстродействие Smile

[Delirium]

zvezda_t, не имея реальной загрузки сервера большими объемами, объективных данных не получить. Узкие места могут вылезти в самых неожиданных местах - начиная от индексации и заканчивая, например, неверно выбранным типом RAID массива для сервера. Так что конечный результат будет виден позднее:)