Компьютерный форум OSzone.net  

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)
-   Программирование и базы данных (http://forum.oszone.net/forumdisplay.php?f=21)
-   -   Индексы, Состовные первичные ключи, Индексация представлений (http://forum.oszone.net/showthread.php?t=200371)

zvezda_t 24-02-2011 15:39 1620782

Индексы, Состовные первичные ключи, Индексация представлений
 
Здравствуйте, уважаемые программисты :)

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

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

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

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

Delirium 25-02-2011 01:44 1621196

Цитата:

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

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

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

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

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

zvezda_t 25-02-2011 07:39 1621267

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

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

zvezda_t 25-02-2011 09:37 1621326

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

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

Busla 25-02-2011 10:42 1621391

Цитата:

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

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

Delirium 25-02-2011 13:17 1621514

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

zvezda_t 01-03-2011 12:25 1624366

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

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


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

(у меня Microsoft SQL Server 2005)

Delirium 02-03-2011 01:01 1624972

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

zvezda_t 02-03-2011 08:00 1625060

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

zvezda_t 02-03-2011 14:44 1625375

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

итак у меня 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 вычисляемое значение, индекс не работает, а значит и запрос дб медленнее, разве нет?

Delirium 03-03-2011 04:04 1625968

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

zvezda_t 03-03-2011 07:16 1626003

Delirium,спасибо Вам! А можно еще вопрос?
Цитата:

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

Delirium 03-03-2011 07:23 1626006

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

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

zvezda_t 03-03-2011 09:10 1626050

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

Delirium 05-03-2011 17:55 1628020

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


Время: 12:43.

Время: 12:43.
© OSzone.net 2001-