Отправляет email-рассылки с помощью сервиса Sendsay

Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 2.594 RSS
←   Май 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://www.sql-ex.ru
Открыта: 15-09-2004

Автор
Serge I

Статистика

2.594 подписчиков
0 за неделю
←   Все выпуски   →

Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 88


Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 88 (20 мая 2006 г.)

http://www.sql-ex.ru

Новым посетителям сайта

Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.

Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 58-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений.

Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов.

Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий.

Новости сайта

§ Видимо, сложность задачи 35 определялась неправильным местом запятой в формулировке, на что указал Snowbear. Передвинул ее на одну позицию влево. Не знаю, угадал ли :-).

§ В сотне два новых участника с весьма приличными результатами:
nsnt (задач 96, время 1.037)
a2010 (96, 1.678)
Один из них не говорит по-русски. Скоро нам представится шанс выяснить качество английской формулировки задачи 98 :-).

§ Сохранили шансы попасть в ТОР 10:
Testo (131, 4.306)
SergeyTikh (121, 6.730)

§ Преодолел второй сертификационный порог gps (121, 179.223), проявив упорство, достойное уважения.

§ На этой неделе сертифицированы:
Fomich (A06003713) [BK] (Россия, г.Москва)
Weed (B06005317) [AR] (Россия, г.Нижний Новгород)

§ Число подписчиков - 3119

Число участников рейтинга - 5800

Число участников второго этапа - 562

Сертифицировано на сайте - 63

Лучшие результаты (ТОР 20)

No Person Number of
Sel_ex		 Last_Sel Number of
DML_ex		 Scores Days Days_2 LastSolved LastVisit
1 Кувалкин К.С. (Cyrilus) 138 138 20 320 484 5.460 23 Mar 2006 19 May 2006
2 Kamaev V.M. (Heromantor) 138 138 20 320 128 9.066 14 Mar 2006 25 Mar 2006
3 Бураков С.Г. (burakov58) 138 138 20 320 419 17.395 24 Mar 2006 07 Apr 2006
4 Тарасов Д.Б. (Gavrila) 138 138 20 320 208 19.424 22 Mar 2006 19 May 2006
5 Голубин Р.С. (Roman S. Golubin) 138 138 20 320 210 20.835 16 Mar 2006 19 May 2006
6 Валуев Д.И. (Fiolent) 138 113 20 320 971 48.000 02 May 2006 19 May 2006
7 Войнов П.Е. (pаparome) 137 137 20 316 203 1.769 15 Mar 2006 12 May 2006
8 Зверев Д.Л. (dimzv) 137 137 20 316 869 3.278 22 Mar 2006 04 Apr 2006
9 Юлдашев М.Р. (Snowbear) 137 137 20 316 239 3.448 14 Mar 2006 19 May 2006
10 Абашин П.И. (Dizil) 137 137 20 316 203 3.776 15 Mar 2006 17 May 2006
11 Самохвалов В. (ValdemarES) 137 137 20 316 117 7.788 14 Mar 2006 16 May 2006
12 Мурашкин И.В. (lepton) 137 137 20 316 25 7.943 17 Apr 2006 08 May 2006
13 Носков Н.В. (niko2) 137 137 20 316 274 8.472 06 Apr 2006 16 May 2006
14 Крижевич С.А. (yaff) 137 137 20 316 259 14.801 16 Mar 2006 05 May 2006
15 Иванов А.Н. (Goapsy) 137 137 20 316 128 16.076 18 Mar 2006 10 May 2006
16 Держальцев В.А. (MadVet) 137 137 20 316 357 18.639 08 Apr 2006 15 Apr 2006
17 Зырин В.Е. (Vezyr) 137 137 20 316 63 20.618 17 Mar 2006 16 May 2006
18 Страшников А.С. (EffEct) 137 137 20 316 305 59.972 16 Mar 2006 02 May 2006
19 Матвеева Ю.Б. (Julia_M) 137 137 20 316 137 68.931 24 Mar 2006 11 May 2006
20 Галиаскаров Э.Г. (Galogen) 136 138 20 315 522 100.285 28 Apr 2006 28 Apr 2006

Лучшие результаты за неделю

No surname n_sel sel_all sel_scores dml_scores scores rating last_visit
1 >Зубов А. (alesha_z) 45 45 79 0 79 1043 19 May 2006
2 >Михайлов К.А. (Gryph) 44 44 74 0 74 1141 19 May 2006
3 Кепещук Д.Б. (Dezz) 40 47 73 0 73 1026 17 May 2006
4 Ржеутский А.В. (GRAD) 25 48 50 19 69 701 17 May 2006
5 >Ilinykh V. (Justvit) 39 39 69 0 69 1252 19 May 2006
6 Bartashevich P.A. (Pavel B) 36 36 65 0 65 1324 17 May 2006
7 >Качанов Н.А. (nickk) 15 59 32 29 61 288 19 May 2006
8 >komarov T.T. (regina) 31 37 60 0 60 1309 19 May 2006
9 >Федоров Ю. (jack777) 34 34 60 0 60 1467 19 May 2006
10 >Ганопольский Р.М. (Родион1976) 27 95 59 0 59 105 19 May 2006
11 Kvitko E. (Fire Of Scorpion) 33 33 59 0 59 1494 18 May 2006
12 Утёнков М.Н. (=Maxim=) 12 71 27 27 54 193 19 May 2006
13 Агниашвили М.Г. (Vart) 28 28 45 9 54 1656 18 May 2006
14 >Петрелевич С.Ю. (zalivnoy) 24 39 53 0 53 1235 19 May 2006
15 Чумбаева Е. (rina) 33 33 44 9 53 1676 16 May 2006
16 >Z (Geralt) 29 29 52 0 52 1712 19 May 2006
17 >Boltrushko D.V. (Misty) 29 29 52 0 52 1713 19 May 2006
18 cunluer (cevdet) 32 32 48 0 48 1881 19 May 2006
19 Зибаров З.Р. (zzzzzzz) 24 24 37 9 46 1918 14 May 2006
20 Дубровский А.А. (Дубровский) 24 24 37 9 46 1919 17 May 2006
21 Григорьев А.В. (AG) 27 27 46 0 46 1923 18 May 2006
22 >Yarullov T.H. (_Tim) 22 29 45 0 45 1719 19 May 2006
23 Раманоўскі М.П. (KotBegemot) 33 33 44 0 44 1977 14 May 2006
24 Smorodin D.V. (mh81) 19 19 44 0 44 1984 19 May 2006
25 >Рожнов (welcome) 25 25 42 0 42 2045 19 May 2006
26 >frenkental (a2010) 19 96 40 0 40 100 19 May 2006
27 Нгуен П.З. (LedWorm) 31 31 40 0 40 2123 17 May 2006

Изучаем SQL

Архитектура суррогатных ключей для затратных операций с базами данных

Brian Walker (оригинал: A surrogate key architecture to perform powerful database operations)
Перевод Моисеенко С.И.

05 января 2006

Введение
Часть 1: Зачем нужно использовать суррогатные ключи
Часть 2: Архитектура суррогатных ключей
Часть 3: Хранимые процедуры: создание и удаление ограничений и индексов
Часть 4: Хранимая процедура: проверка наличия подчиненных строк
Часть 5: Хранимая процедура: проверка связанных данных

Я написал предыдущие статьи в поддержку суррогатных ключей, но они служили, главным образом, опровержениями смешных комментариев оппонентов. Эта техническая работа выходит за пределы риторики и описывает предлагаемую архитектуру суррогатных ключей. Она также предлагает несколько инструментов T-SQL для поддержки такой архитектуры. Оглавление подскажет вам порядок чтения. Или перейдите непосредственно к особенностям структуры для поддержки архитектуры суррогатных ключей.

Часть 1. Зачем нужно использовать суррогатные ключи

Альтернативой суррогатным ключам являются ключи естественных данных. Чтобы осознать многочисленные преимущества суррогатных ключей, необходимо обсудить подоплеку проблемы.

Иногда говорят, что система ключей естественных данных имеет предпочтение в реализации ссылочной целостности. Утверждается, что просто невозможно вставить дочернюю запись, для которой нет соответствующей родительской записи. Так ли это? Также утверждают, что система суррогатных ключей сводит на нет обеспечение ссылочной целостности. Например, допускается вставка дочерней записи, которая не соответствует ни одной родительской записи. Правда ли это?

Представим приложение с сеткой родительских строк. Щелкаем на родительской строке, чтобы ввести новую дочернюю строку. Форма ввода отображает соответствующие данные родительской строки и принимает вход данных дочерней строки. Щелчок на "Save (сохранить)", и все в порядке, правильно? Ё! Разработчик допустил ошибку в коде. Приложение готовится сохранить дочернюю строку и случайно захватывает данные родительской строки непосредственно выше правильной строки в сетке. Новая дочерняя строка содержит внешний ключ, соединяющий ее с неправильной родительской строкой! Есть ли вообще какая-нибудь разница в том, что захваченные неправильно данные представляют собой естественный 4-столбцовый ключ, а не одностолбцовый суррогатный ключ?

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

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

Это стало бы серьезной проблемой, если бы корпоративная база данных использовала естественные ключи. Но нет. Она использует суррогатные ключи, построенные на единственном столбце. Каждая таблица имеет целочисленный столбец со свойством IDENTITY, и этот столбец является первичным ключом. Каждый внешний ключ является одностолбцовым первичным ключом родительской таблицы. Каждое соединение родительской и дочерней таблиц может быть написано с помощью предиката, использующего по одному столбцу из каждой таблицы. Эта архитектура дает несомненные выгоды. Значения первичных ключей никогда не меняются, в результате чего значения внешних ключей стабильны. Все индексы на первичных и внешних ключах компактны, что очень благоприятно сказывается на производительности соединения (имеются некоторые дополнительные индексы на столбцах отбора естественных данных). SQL-представление связи между любыми двумя таблицами выражается просто и весьма последовательно.

Я полагаю, что суррогатные ключи имеют стабильность и преимущество в производительности по сравнению с естественными ключами для большинства современных систем реляционных баз данных. Однако именно последовательность в универсальности применения суррогатных ключей делает эту архитектуру столь привлекательной для меня. Некий запрос в архитектуре естественных ключей может соединять восемь таблиц со структурой соединения, являющейся радикально различной для каждой пары таблиц, в зависимости от того, как определены связи (ссылки внешних ключей). Тот же самый запрос в архитектуре суррогатных ключей мог бы соединять 10 таблиц, но структура соединения будет короткой и предсказуемой для каждой пары таблиц.

Последовательность архитектуры суррогатных ключей делает жизнь разработчиков легче. Я полагаю, что они смогут написать более быстро код извлечения данных и с меньшим количеством ошибок. При суррогатных ключах имеется только один столбец, участвующий в большинстве соединений, причем этот столбец очевиден. С естественными ключами в большинстве соединений участвует несколько столбцов каждой таблицы, и эти столбцы не столь очевидны. Конечно, в этом случае более утомительно написать структуру соединения и более трудно сделать это правильно; пропуск одного столбца в соединении может иметь бедственные последствия. Многие администраторы баз данных возмущаются принятыми разработчиками архитектурными решениями. Я не вижу никакого криминала в том, чтобы принять компромиссные решения относительно базы данных и позволить разработчикам быть более производительными.

Последовательность архитектуры суррогатных ключей делает ее более практичной для создания процедур, которые выполняют важную роль манипуляции данными в целях обслуживания. Помимо прочего, такие процедуры позволяют администраторам баз данных выполнить массовые операции (копирования/удаления/слияния) над наборами реляционных данных вызовом простых хранимых процедур. Популярные прикладные утилиты баз данных даже не делают попытку таких операций, поскольку многие из существующих баз данных не обладают достаточной последовательностью архитектуры. Последовательная архитектура облегчает также создание разнообразных средств генерации кода и административных инструментов.

Представьте себя администратором баз данных компании. Клиентами вашей компании являются другие компании. Каждый клиент имеет несколько контактов. Каждый контакт имеет несколько адресов и телефонных номеров. Каждый телефонный номер имеет журнал звонков. Каждый клиент делает много заказов. Каждый заказ включает товары. Некоторые товары имеют журнал обслуживания. Каждый элемент журнала может включать нескольких технических специалистов. Каждый специалист … Достаточно, Вы получили представление. Вообразите теперь, что есть 10 уровней каскадных таблиц, исходящих от клиентов в вашей базе данных. Далее предположим, что одна из клиентских компаний выходит из бизнеса, и Вы хотите скопировать ее данные в архивную базу данных и удалить ее из рабочей базы данных. Как вам выполнить копирование? Я задал такой вопрос нескольким профессионалам в области баз данных, и получил массу ответов. Некоторые предложили использовать DTS. Другие - написать код на SQL. Третьи используют генератор операторов INSERT. Все эти варианты достаточно болезненны. Я знаю только об одном коммерческом продукте, о котором утверждается, что он в состоянии выполнить такое копирование, и этот продукт является чрезвычайно дорогим. Вот то, что я сделал бы с нашей корпоративной базой данных:

EXECUTE CopyBranch 'Archive','Production','Customer','CustomerID',@CustomerID

Хранимая процедура CopyBranch - процедура собственного производства, которая может скопировать любую ветвь нашей корпоративной базы данных. В этом примере она стартует с единственной строки в таблице Customer и копирует все связанные с ней строки из всех нисходящих таблиц. При этом не имеет значения, сколько всего таблиц вовлечено в этот процесс или насколько глубоко простирается структура. Эта процедура представляет для нас очень мощный инструмент. Мы можем легко скопировать подмножество связанных данных в архивную базу данных, базу данных разработки или демонстрационную базу данных. Эта способность стала возможной при наличии очень последовательной архитектуры ключей.

Теперь, когда я ввел вас в курс дела, я опишу предлагаемую архитектуру суррогатных ключей. Преимущество ее использования одинаково достижимо для любых реляционных баз данных.

Прочитать всю статью.

Полезная информация

§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL.

§ Поступила в продажу книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием.

Контакты

По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
Подписка Subscribe.Ru
Новости сайта "Упражнения по SQL"
В избранное