| ← Сентябрь 2005 → | ||||||
|
1
|
2
|
4
|
||||
|---|---|---|---|---|---|---|
|
5
|
6
|
7
|
8
|
9
|
11
|
|
|
12
|
13
|
14
|
15
|
16
|
18
|
|
|
19
|
20
|
21
|
22
|
23
|
25
|
|
|
26
|
27
|
28
|
29
|
30
|
||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)
| Информационный Канал Subscribe.Ru |
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 53 (17 сентября 2005 г.)
 |
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 59-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ Этот выпуск имеет номер 53. Это означает, что рассылке уже год.
Помимо этого, сайт отмечает свое трехлетие.
Надеюсь, что наша деятельность способствовала вашему профессиональному и карьерному росту.
§ Появилась долгожданная страница сравнительной оценки плана выполнения запросов-решений задач второго этапа: http://www.sql-ex.ru/performance.php. Теперь вы сможете оценить оптимальность своих решений (первого и последнего по каждой задаче) относительно решений других участников, а также узнать, принимаются ли решения системой при текущем состоянии проверочной базы данных. Вы можете оптимизировать свое решение, чтобы уменьшить
его стоимость и, соответственно, занять более высокое место в таблице результатов.
Показатели стоимости должны послужить основой для формирования нового рейтинга, который учитывал бы эти показатели. Самого рейтинга еще нет. Здесь видится много вариантов, поэтому я жду ваших предложений, чтобы сделать его максимально объективным.
Число участников рейтинга - 4096
Число участников второго этапа - 383
Лучшие результаты (ТОР 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 | 08 Sep 2005 |
| 2 | Зверев Д.Л. (dimzv) | 137 | 137 | 20 | 312 | 643 | 2.900 | 08 Aug 2005 | 01 Sep 2005 |
| 3 | Кувалкин К.С. (Cyrilus) | 137 | 137 | 20 | 312 | 224 | 5.129 | 06 Jul 2005 | 09 Sep 2005 |
| 4 | Носков Н.В. (niko2) | 137 | 137 | 20 | 312 | 47 | 7.855 | 22 Aug 2005 | 22 Aug 2005 |
| 5 | Гонтовой В.А. (noname) | 137 | 137 | 20 | 312 | 105 | 9.808 | 29 Jun 2005 | 26 Aug 2005 |
| 6 | Леденев С.А. (Shurgenz) | 137 | 137 | 20 | 312 | 313 | 9.900 | 27 Jun 2005 | 05 Sep 2005 |
| 7 | Бураков С.Г. (burakov58) | 137 | 137 | 20 | 312 | 164 | 12.100 | 12 Jul 2005 | 09 Sep 2005 |
| 8 | Валуев Д.И. (Fiolent) | 137 | 137 | 20 | 312 | 662 | 26.627 | 27 Jun 2005 | 09 Sep 2005 |
| 9 | Галиаскаров Э.Г. (Galogen) | 137 | 137 | 20 | 312 | 221 | 61.437 | 01 Jul 2005 | 24 Aug 2005 |
| 10 | Мельникова И.А. (Iris_m) | 137 | 137 | 20 | 312 | 478 | 91.764 | 02 Sep 2005 | 02 Sep 2005 |
| 11 | Gershovich (VIG) | 136 | 136 | 20 | 308 | 895 | 13.954 | 23 Aug 2005 | 09 Sep 2005 |
| 12 | Колосов А.С. (KAS) | 134 | 137 | 20 | 306 | 25 | 3.398 | 11 Mar 2005 | 14 Jun 2005 |
| 13 | Алалыкин В.М. (BOBAH) | 135 | 135 | 20 | 305 | 101 | 28.244 | 01 Sep 2005 | 02 Sep 2005 |
| 14 | Сныткин В.Л. (Ded I) | 134 | 136 | 20 | 304 | 252 | 7.456 | 12 May 2005 | 09 Sep 2005 |
| 15 | Рахманов И.Е. (bloom) | 134 | 136 | 20 | 304 | 148 | 14.171 | 11 May 2005 | 15 Jun 2005 |
| 16 | Hakobyan H.H. (hamlet) | 134 | 136 | 20 | 304 | 220 | 37.869 | 07 May 2005 | 03 Jun 2005 |
| 17 | Шипунов И. (IAS) | 134 | 136 | 20 | 304 | 334 | 82.080 | 13 May 2005 | 26 May 2005 |
| 18 | Иткин И.Л. (joseph_itkin) | 132 | 136 | 20 | 299 | 375 | 2.849 | 07 Mar 2005 | 13 Apr 2005 |
| 19 | Spirin (spirin) | 131 | 136 | 19 | 296 | 158 | 13.461 | 21 Jan 2005 | 25 Aug 2005 |
| 20 | Михайлов В.Г. (mslava) | 132 | 136 | 17 | 293 | 648 | 10.504 | 25 Mar 2005 | 25 Mar 2005 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | >Скоблев А.Д. (Andrew S.) | 58 | 58 | 105 | 28 | 133 | 235 | 16 Sep 2005 |
| 2 | Чернышева Г.Ю. (go) | 44 | 59 | 90 | 23 | 113 | 257 | 16 Sep 2005 |
| 3 | >Огарок Д.А. (ogarok_dima) | 40 | 46 | 87 | 9 | 96 | 282 | 16 Sep 2005 |
| 4 | >Villy (transbublik) | 39 | 59 | 80 | 3 | 83 | 367 | 16 Sep 2005 |
| 5 | >Истомин А.С. (AS) | 45 | 45 | 72 | 7 | 79 | 673 | 16 Sep 2005 |
| 6 | >Касьянов О.В. (Hilge) | 36 | 65 | 66 | 9 | 75 | 276 | 16 Sep 2005 |
| 7 | >Чуйков А.А. (tchuykov) | 35 | 35 | 61 | 3 | 64 | 874 | 16 Sep 2005 |
| 8 | >Богданова М.В. (Rita) | 35 | 35 | 62 | 0 | 62 | 914 | 16 Sep 2005 |
| 9 | Когай С.А. (Sergey_205) | 29 | 29 | 52 | 7 | 59 | 961 | 10 Sep 2005 |
| 10 | >Тарасов Д.Б. (Gavrila) | 26 | 93 | 56 | 0 | 56 | 77 | 16 Sep 2005 |
| 11 | >Ahmed A.H. (Alaa) | 26 | 54 | 51 | 2 | 53 | 277 | 16 Sep 2005 |
| 12 | >Крижевич С.А. (yaff) | 23 | 82 | 51 | 0 | 51 | 108 | 16 Sep 2005 |
| 13 | >Daneykin A. (danko) | 20 | 58 | 36 | 15 | 51 | 306 | 16 Sep 2005 |
| 14 | >N1 A. (N11) | 28 | 28 | 49 | 0 | 49 | 1150 | 16 Sep 2005 |
| 15 | >Чорний О.В. (Doran) | 28 | 28 | 49 | 0 | 49 | 1152 | 16 Sep 2005 |
| 16 | >foreach (Foreach) | 28 | 28 | 43 | 5 | 48 | 1186 | 16 Sep 2005 |
| 17 | SHARMA N. (nittin) | 27 | 27 | 46 | 0 | 46 | 1212 | 15 Sep 2005 |
| 18 | >Проничева (2Inna) | 27 | 35 | 41 | 0 | 41 | 1120 | 16 Sep 2005 |
| 19 | >Volkov (ymv) | 19 | 44 | 40 | 0 | 40 | 742 | 16 Sep 2005 |
| 20 | Goryunov A. (_Faust_) | 25 | 25 | 40 | 0 | 40 | 1336 | 13 Sep 2005 |
Изучаем SQL
Худшие методы - чувствительные к регистру базы данных (или что-нибудь еще)
Andy Warren (оригинал: Worst Practices - Making Databases Case Sensitive (Or Anything Else))Перевод Моисеенко С.И.
Мы уже рассмотрели некоторые интересные идеи и получили большое число откликов читателей. На этой неделе я хотел бы обсудить тему, предложенную читателем (и ведущим колонки!) Mindy Curnutt, - случая, когда вся база данных чувствительна к регистру. Может ли кто-нибудь утверждать, что чувствительность к регистру не добавляет уровень сложности? Написание хорошего программного обеспечения, вне зависимости от используемого вами языка, достаточно сложно и без этой проблемы!
Прежде, чем мы сможем всецело отнести чувствительность к регистру в реестр плохих методов, следует рассмотреть вопрос о том, зачем нам может понадобиться использовать это. Например, у нас есть приложение, которое является чувствительным к регистру, т.е. оно различает "FL" и "Fl" как коды для Флориды в справочной таблице. Поскольку нам требуется только один код для Флориды, как бы мы смогли обеспечить его? Созданием уникального индекса! Теперь мы можем иметь либо FL, либо Fl, но не оба. Даже при том, что приложение является чувствительным к регистру, нет никакой необходимости делать столбец (или таблицу, или базу данных) чувствительным к регистру. Так ли это?
Что, если .... мы уже имеем такие значения в таблице, которые не дают нам возможности создать уникальный индекс? (Чувствуете мою боль? Это - реальный пример!) Следует ли нам теперь оставить все как есть и обратить взгляд на использование чувствительных к регистру данных? Мне действительно не нравится такой выбор, поэтому давайте рассмотрим еще одну идею - использование триггеров на вставку и обновление (INSERT, UPDATE), которые позволят нам сделать чувствительную к регистру проверку таблицы и откатят любое изменение, которое нарушало бы наше "правило" не добавления каких-либо "дубликатов". Другими словами, не делайте проблему еще хуже, чем она есть.
Другим вариантом могло бы стать удаление всех "дубликатов" с тем, чтобы можно было использовать уникальный индекс. Я считаю это правильным способом решения проблемы, однако такое решение может зависеть от большого количества факторов, специфичных для вашей ситуации.
Если Вы столкнулись с этой проблемой в SQL 7, то вам пришлось бы использовать метод триггеров или сделать всю базу данных чувствительной к регистру. То, какой способ предпочесть, будет вероятно зависеть от конкретного случая. Если бы Вы имели сто таблиц, которые потребовали бы этих триггеров, то было бы более разумным, менее трудоемким и более эффективным использовать чувствительность к регистру. Теперь, когда SQL 2000 позволяет для таблиц или даже для столбцов устанавливать чувствительность к регистру, мы можем применять намного более гибкие подходы.
Я знаю, что Вы думаете, - если это решает проблему, то почему бы это ни использовать?
На уровне столбца - не буду спорить. Мог бы, но не буду. Это достаточно хорошее решение. Возможно даже на уровне таблицы, если ваша ситуация требует этого. Но сделать всю базу данных чувствительной к регистру? Ни в коем случае! Это ведь не только данные, которые чувствительны к регистру, это - все, включая объекты. Пару статей назад я обсуждал вопрос о том, почему случай, когда не все объекты принадлежат dbo, только усложняет вашу жизнь (Вы могли иметь dbo.lookup, andy.lookup, и т.д). Сделайте вашу базу данных чувствительной к регистру, и Вы получите еще и следующее:
dbo.lookupdbo.LOOKUP
dbo.LookUP
andy.lookup
andy.LOOKUP
andy.LookUP
И еще кое-что помимо этого. Как я говорил в начале, трудно ли написать хороший код, не примешивая сюда лишние проблемы? Одним из аргументов в пользу чувствительности среды к регистру является то, что это должно быть быстрее, поскольку центральный процессор не должен выполнять это за кадром:
Select * from table where state='fl'
Вероятно, на низком уровне выполнение будет примерно таким
select * from table where upper(state)=upper('fl')Я уверен, что центральный процессор тратит на это один или два цикла, но имеет ли смысл экономить на таких незначительных издержках? Я могу представить, что как аппаратные средства, так SQL вполне прилично оптимизированы для выполнения этой операции. Даже если Вы решили сэкономить, стоит ли это дополнительной сложности кодирования? О какой сложности я говорю? Мне бы хотелось, чтобы в большинстве чувствительных к регистру сред окружения, Вы заканчивали бы так:
Select * from table where upper(state)='FL'Почему? Потому что ваша справочная таблица имеет только один правильный код для Флориды! Теперь подумайте о том, как добиться этого, если, предположим, я ставлю Вам требование сделать коды штатов уникальными в справочной таблице независимо от регистра? Значит Вы должны отказаться от регистрозависимого столбца и сделать его НЕЧУВСТВИТЕЛЬНЫМ к регистру! Не можете использовать индекс? Мы вернулись к триггеру!
Знаете ли вы, что и Access, и VB считают данные чувствительными к регистру? Проверьте сами, выполнив следующий код:
Dim sItem1 As StringDim sItem2 As String
sItem1 = "a"
sItem2 = "A"
If sItem1 = sItem2 Then
MsgBox "Matched"
Else
MsgBox "Didnt match"
End If
Если Вы измените сравнение на 'ucase$ (sItem1) =ucase$ (sItem2)', это будет всегда работать. Постойте-ка, Вы говорите, что код корректно работает в Access и без преобразования ucase$? Access 2000 (я полагаю, что и в Access 97 также) добавляет оператор "Option Compare Database" в каждый модуль. Закомментируйте его и посмотрите! VB также предлагает поддержку для выполнения регистронезависимого сравнения, посмотрите эту ссылку об использовании Option Compare Text
Интересная тема, ни так ли? Представьте, что вы используете язык, который является чувствительным к регистру - Java, Javascript, даже C#, я думаю. XML чувствителен к регистру!
Люди - не компьютеры. Мы не работаем хорошо с чувствительными к регистру данными или средами разработки. Позвольте компьютеру поднять эту тяжесть и скрыть сложность. Хорошо подумайте об имеющихся альтернативах прежде, чем Вы сделаете что-нибудь чувствительным к регистру.
Завершая, я понимаю, что не каждый согласится со мной. Так это или нет, я держу пари, что Вы имеете мнение относительно темы обсуждения. Как насчет того, чтобы поделиться этим мнением с нашими читателями - дать им возможность увидеть обе стороны вопроса? Ваши комментарии действительно станут прочитанными, и эта статья - результат одного из них!
07/08/2005
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex |
Отписаться
Вспомнить пароль |
| В избранное | ||
