| ← Август 2005 → | ||||||
|
1
|
2
|
3
|
4
|
5
|
7
|
|
|---|---|---|---|---|---|---|
|
8
|
9
|
10
|
11
|
13
|
14
|
|
|
15
|
16
|
17
|
18
|
19
|
21
|
|
|
22
|
23
|
24
|
25
|
26
|
28
|
|
|
29
|
30
|
31
|
||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)
| Информационный Канал Subscribe.Ru |
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 50 (27 августа 2005 г.)
 |
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 59-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ Обсуждение на форуме при активном участии Roman S. Golubin привело к принятию уточнений формулировок задач 74, 78 (в редакции Молдавского сибиряка) и 85 (в редакции Fiolent). На принятые решения это никак не повлияло.
§ Число подписчиков - 2388Число участников рейтинга - 3924
Число участников второго этапа - 362
Лучшие результаты (ТОР 20)
| No | Person | Number of Sel_ex |
Last_Sel | Number of DML_ex |
Scores | Days | Days_2 | LastSolved | LastVisit |
| 1 | Духин А. (Shark) | 137 | 137 | 20 | 312 | 30 | 2.635 | 10 Aug 2005 | 26 Aug 2005 |
| 2 | Зверев Д.Л. (dimzv) | 137 | 137 | 20 | 312 | 643 | 2.900 | 08 Aug 2005 | 12 Aug 2005 |
| 3 | Кувалкин К.С. (Cyrilus) | 137 | 112 | 20 | 312 | 224 | 5.129 | 06 Jul 2005 | 25 Aug 2005 |
| 4 | Носков Н.В. (niko2) | 137 | 137 | 20 | 312 | 47 | 7.855 | 22 Aug 2005 | 22 Aug 2005 |
| 5 | Гонтовой В.А. (noname) | 137 | 112 | 20 | 312 | 105 | 9.808 | 29 Jun 2005 | 26 Aug 2005 |
| 6 | Леденев С.А. (Shurgenz) | 137 | 112 | 20 | 312 | 313 | 9.900 | 27 Jun 2005 | 24 Aug 2005 |
| 7 | Бураков С.Г. (burakov58) | 137 | 137 | 20 | 312 | 164 | 12.100 | 12 Jul 2005 | 31 Jul 2005 |
| 8 | Валуев Д.И. (Fiolent) | 137 | 112 | 20 | 312 | 662 | 26.627 | 27 Jun 2005 | 26 Aug 2005 |
| 9 | Галиаскаров Э.Г. (Galogen) | 137 | 112 | 20 | 312 | 221 | 61.437 | 01 Jul 2005 | 24 Aug 2005 |
| 10 | Gershovich (VIG) | 136 | 136 | 20 | 308 | 895 | 13.954 | 23 Aug 2005 | 26 Aug 2005 |
| 11 | Мельникова И.А. (Iris_m) | 135 | 137 | 20 | 308 | 380 | 89.865 | 27 May 2005 | 12 Aug 2005 |
| 12 | Колосов А.С. (KAS) | 134 | 137 | 20 | 306 | 25 | 3.398 | 11 Mar 2005 | 14 Jun 2005 |
| 13 | Сныткин В.Л. (Ded I) | 134 | 136 | 20 | 304 | 252 | 7.456 | 12 May 2005 | 25 Aug 2005 |
| 14 | Рахманов И.Е. (bloom) | 134 | 136 | 20 | 304 | 148 | 14.171 | 11 May 2005 | 15 Jun 2005 |
| 15 | Hakobyan H.H. (hamlet) | 134 | 136 | 20 | 304 | 220 | 37.869 | 07 May 2005 | 03 Jun 2005 |
| 16 | Шипунов И. (IAS) | 134 | 136 | 20 | 304 | 334 | 82.080 | 13 May 2005 | 26 May 2005 |
| 17 | Иткин И.Л. (joseph_itkin) | 132 | 136 | 20 | 299 | 375 | 2.849 | 07 Mar 2005 | 13 Apr 2005 |
| 18 | Spirin (spirin) | 131 | 136 | 19 | 296 | 158 | 13.461 | 21 Jan 2005 | 25 Aug 2005 |
| 19 | Михайлов В.Г. (mslava) | 132 | 136 | 17 | 293 | 648 | 10.504 | 25 Mar 2005 | 25 Mar 2005 |
| 20 | Пятница О.А. (Robin) | 125 | 128 | 20 | 287 | 754 | 74.630 | 19 Mar 2005 | 14 Jul 2005 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | >Sevidova E.I. (~selenka~) | 63 | 68 | 120 | 15 | 135 | 132 | 26 Aug 2005 |
| 2 | >Войнов П.Е. (Войнов П.Е.) | 47 | 47 | 82 | 32 | 114 | 314 | 26 Aug 2005 |
| 3 | >Никаноров (Ionis) | 51 | 51 | 87 | 26 | 113 | 336 | 26 Aug 2005 |
| 4 | >Обросов А.И. (AlexIO) | 51 | 54 | 95 | 9 | 104 | 399 | 26 Aug 2005 |
| 5 | Буртык Р. (Bom) | 57 | 57 | 103 | 0 | 103 | 443 | 26 Aug 2005 |
| 6 | Олонцев С. (HawX) | 47 | 47 | 79 | 23 | 102 | 449 | 26 Aug 2005 |
| 7 | Голубин Р.С. (Roman S. Golubin) | 39 | 97 | 82 | 0 | 82 | 59 | 26 Aug 2005 |
| 8 | >Maximenko A. (Sc0rpio) | 43 | 43 | 73 | 9 | 82 | 610 | 26 Aug 2005 |
| 9 | Коломеец В.П. (vlad56) | 41 | 41 | 74 | 0 | 74 | 707 | 26 Aug 2005 |
| 10 | >Абашин П.И. (Dizil) | 36 | 36 | 63 | 11 | 74 | 708 | 26 Aug 2005 |
| 11 | Lavricova O.V. (Ray) | 41 | 41 | 64 | 9 | 73 | 713 | 23 Aug 2005 |
| 12 | Хайрова В.Р. (khvr) | 46 | 46 | 73 | 0 | 73 | 717 | 24 Aug 2005 |
| 13 | >Авакимян С.А. (xax) | 41 | 41 | 65 | 3 | 68 | 776 | 26 Aug 2005 |
| 14 | >Тарасов Д.Б. (Gavrila) | 36 | 36 | 64 | 0 | 64 | 825 | 26 Aug 2005 |
| 15 | >Гладков Д.А. (carbon) | 19 | 85 | 41 | 14 | 55 | 100 | 26 Aug 2005 |
| 16 | Алискин (Melkiades) | 24 | 24 | 37 | 17 | 54 | 1014 | 25 Aug 2005 |
| 17 | >Ким Е.В. (Евгений Ким) | 30 | 30 | 51 | 1 | 52 | 1037 | 26 Aug 2005 |
| 18 | Поддубная С.В. (Veta) | 28 | 28 | 49 | 0 | 49 | 1088 | 26 Aug 2005 |
| 19 | >Венгров В.В. (Виталий) | 25 | 25 | 40 | 8 | 48 | 1139 | 26 Aug 2005 |
| 20 | >Chuma O. (Plague) | 20 | 42 | 44 | 0 | 44 | 696 | 26 Aug 2005 |
| 21 | Tkachenko R.V. (Tramp_13) | 22 | 22 | 32 | 9 | 41 | 1244 | 21 Aug 2005 |
Изучаем SQL
Худшие методы - игнорирование первичных ключей и кластерных индексов
Andy Warren (оригинал: Worst Practices - Not Using Primary Keys and Clustered Indexes)Перевод Моисеенко С.И.
Это третья статья в серии статей, посвященной Худшим методам (см. "Худшие методы - часть 1 очень длинной серии!" и "Худшие методы - объекты, не принадлежащие DBO"), которые пока вызвали довольно мало откликов читателей. Не каждый пока соглашается со мной, однако, похоже, что я не единственный, кто видит много "плохих" методов повсеместно.
Итак, давайте поговорим еще об одном худшем методе - присутствии первичного ключа НЕ на КАЖДОЙ таблице и использовании кластерного ключа НЕ на КАЖДОЙ таблице.
Я думаю, что в 9-ти случаях из 10, это происходит только по ошибке. Если Вы создаете таблицы в Enterprise Manager и щелкаете по иконке первичного ключа на панели инструментов, это сразу делает столбец первичным ключом и создает на нем кластерный индекс. Это не обязательно лучшее использование кластерного индекса, но это лучше чем ничего. Если Вы создаете таблицы в Query Analyzer, Вам решать, выполнять ли код TSQL, чтобы создать первичный ключ и кластерный индекс (или переключиться в EM, чтобы там выполнить эту часть работы).
Вам решать кто, администратор базы данных или старший разработчик, должен отлавливать эти ошибки до того, как они попадут в конечный продукт. Обязательно следует удостовериться, что ваши разработчики понимают, насколько важны эти моменты; я думаю, что иногда мы падаем впросак, полагая, что каждый ЗНАЕТ, почему это важно. Не предполагайте, спрашивайте. Если они знают хорошо, но просто забыли сделать, то следует мягко напомнить о важности этих моментов. Если они не знают это хорошо, то самое время об этом узнать.
Становится интересным (во всяком случае, мне!), когда кто-то пытается убедить меня, что они не нуждаются в первичном ключе. Подождите-ка, наличие первичного ключа - одно из основных понятий, так почему он Вам не нужен? В ответ я слышу пару аргументов, давайте посмотрим, имеют ли они хоть какой-нибудь вес.
Первый аргумент, что таблица является настолько маленькой, что индекс не будет использоваться в плане выполнения запроса. Весьма возможно, что это так. Ну и что? Если Вы делаете предположение, что таблица всегда будет маленькой, что случится, когда она вырастет? Будет ли разработчик (или администратор базы данных) помнить: "Эй, я должен добавить индекс к этой таблице"? Более вероятно, что это будет установлено только тогда, когда возникнет проблема с производительностью. Что касается меня, то я люблю строить их сразу же. Зачем разрешать проблему позже, если я могу избежать ее сейчас? Сколько времени требуется, чтобы создать первичный ключ или кластерный индекс по сравнению с тем, чтобы выяснять позже, почему возникли проблемы производительности? Хотя более важным вопросом по сравнению с планом выполнения запроса является вопрос о целостности данных. Отсутствие первичного ключа может привести к фатальному отказу. Уверен, что Вы не будете добавлять дубликаты в таблицу, но что случится, если это сделает кто-то другой? Сколько времени потребуется, чтобы это выяснить?
Другой аргумент, что это временная таблица, и потому правила здесь действительно не применяются. По сравнению с первым аргументом, я полагаю, здесь есть некоторая доля истины. Не большая, но есть! Думаю, что самый большой довод в пользу этого аргумента заключается в том, что во многих случаях, когда Вы используете временную таблицу, в настоящее время Вы можете (и, вероятно, должны) использовать переменную табличного типа (доступную с версии SQL 2000), который позволяет Вам определить только структуру, но не индексы. Помните только, что никогда не будет ошибкой создание первичного ключа в таблице, временная она или нет.
Создание первичного ключа (и/или кластерного индекса) не является исключительно необходимым для многих ситуаций типа временных таблиц, справочных таблиц (lookup tables) и даже таблиц истории/ревизии. Вздор. Да, каждый индекс, каждое ограничение, каждое значение по умолчанию, каждый триггер несколько увеличивает накладные расходы. Должны ли мы стремиться минимизировать эти накладные расходы в нашем проекте? Всегда. Но никогда за счет целостности данных. Если ваша система загружена так, что Вы волнуетесь о накладных расходах из-за наличия первичного ключа в таблице, у Вас серьезные проблемы. Хорошо, что только один первичный ключ и кластерный индекс может быть создан для каждой таблицы, поэтому довольно трудно избежать их использования!
Наконец, "я не нуждаюсь в кластерном индексе". Хорошим примером этого могла бы стать справочная таблица, которая содержит название штата и его аббревиатуру. Вы собираетесь выполнять поиск единственной записи, и никогда - диапазона, когда преимущество кластерного индекса является несомненным. Вы также не собираетесь иметь много индексов, вероятно один на названии и один на аббревиатуре, где индекс обеспечит необходимые данные, при этом не требуется выполнять поиск по таблице, чтобы найти другие биты информации, связанные с найденной строкой. Справедливо ли данное утверждение для этого примера? Я думаю да. С другой стороны, каковы накладные расходы на добавление кластерного индекса? Поскольку обновление здесь не предполагается, данные представляют собой индекс, то расходы весьма незначительны.
Моя рекомендация начинающим разработчикам довольно проста. Каждая таблица получает как первичный ключ, так и кластерный индекс. Это, возможно, не "лучший" метод, но достаточно хорошая отправная точка, просто добавить столбец identity, называемый идентификатором строки (rowid), и сделать его первичным ключом и кластерным индексом. По мере роста мастерства Вы сможете рассмотреть и более передовые альтернативы.
Я хотел бы поблагодарить тех читателей, которые нашли время, чтобы добавить комментарий к моим двум первым статьям. Эти комментарии, как тех, кто соглашается, так и тех, кто не соглашается, дают ценное дополнение ко всем статьям, опубликованным SQLServerCentral.com. Увидеть, что другие люди думают о содержании, действительно полезно особенно для новых разработчиков и администраторов баз данных, т.к. имеется множество различных мнений по схожим проблемам, и трудно узнать, какое из них является правильным. Согласны Вы или нет, почему бы ни сообщить всем о своем мнении?
22.07.2005
Полезная информация
Конкурс
§ Мы выставили наш сайт на конкурс Интернить 2005. Победитель определяется числом поданых голосов. Просьба проголосовать. (рекомендуемая оценка 3 :-)).
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex |
Отписаться
Вспомнить пароль |
| В избранное | ||
