| ← Май 2007 → | ||||||
|
1
|
2
|
3
|
4
|
6
|
||
|---|---|---|---|---|---|---|
|
7
|
8
|
9
|
10
|
11
|
13
|
|
|
14
|
15
|
16
|
17
|
19
|
20
|
|
|
21
|
22
|
23
|
24
|
25
|
27
|
|
|
28
|
29
|
30
|
31
|
|||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 140
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 140 (19 мая 2007 г.)
Новости сайта§ Davh предложил изменение еще двух английских формулировок для задач 52 и 78. При этом формулировка задачи 52 кардинально отличается от русскоязычного аналога. Теперь в случае проблем с пониманием задачи имеет смысл прочитать обе формулировки :-). § Лидеры решали добавленные задачи: § Новые лица в сотне: § Продвинулись в рейтинге: § Число подписчиков - 3563 Число участников рейтинга - 10361 Число участников второго этапа - 969 Сертифицировано на сайте - 156 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLДесять характерных ошибок в проектировании базы данных (продолжение, начало в вып.138)Louis Davidson (оригинал: Ten Common Database Design Mistakes )Перевод Моисеенко С.И. Одна таблица для хранения всех значений домена"Одно Кольцо, чтобы управлять ими всеми и в темноте связывать их" Это все замечательно и хорошо с точки зрения знания фантастики, но не настолько хорошо, когда речь идет о проекте базы данных в форме "управляющей" таблицы доменов. Реляционные базы данных опираются на фундаментальную идею, согласно которой каждый объект представляет одну и только одну сущность. Никогда не должно быть никакого сомнения относительно того, к какой части данных идет обращение. Отслеживание связи от имени столбца к имени таблицы, к первичному ключу, должно легким и определенно указывать, что означает та или иная часть данных. Большой миф, созданный архитекторами, которые на самом деле не понимают архитектуру реляционной базы данных (включая и меня на заре карьеры), заключается в утверждении, что чем больше имеется таблиц, тем более сложным будет проект. Как раз наоборот, разве упаковывание таблиц в единственную "всеобъемлющую" таблицу упрощает проект? Рассмотрим, например, следующую часть модели, где мне нужны доменные значения для: 
Это может показаться очень прозрачным и естественным способом проектирования таблицы со всех точек зрения, но имеется проблема в не очень естественной работе с помощью SQL. Скажем, мы хотим получить доменные значения только для таблицы Customer: SELECT * Как можно увидеть, это далеко от того, что называется естественным соединением, и сводится к проблеме смешивания яблок с апельсинами. На первый взгляд, доменные таблицы - это только абстрактное понятие контейнера, содержащего текст. С точки зрения централизованного подхода, это вполне верно, но это неправильный способ строить базу данных. В базе данных процесс нормализации, как средство декомпозиции и изоляции данных, приводит каждую таблицу к такому состоянию, когда одна строка представляет одну вещь. И каждый домен значений совершенно отличен от всех других доменов (если же это не так, тогда будет достаточно одной таблицы). В сущности, то, что Вы делаете, есть нормализация данных относительно каждого использования, растягивающая работу на длительный срок, а не разовое выполнение законченной задачи. Итак, вместо единственной таблицы для всех доменов, Вы могли бы смоделировать это так: 
Выглядит сложнее, не так ли? Но это первоначальное впечатление. Откровенно говоря, мне потребуется больше времени, чтобы описать подробно таблицы примера. Однако появились огромные преимущества: · Использование данных в запросе стало намного проще: SELECT * · Использование ограничений внешних ключей для поддержания согласованного состояния данных является очень естественным, что не всегда выполнимо для другого решения, если Вы не реализуете диапазоны ключей для каждой таблицы, - ужасно тяжело поддерживать. · Если оказывается, что Вы должны хранить больше информации о ShipViaCarrier (доставке курьером), чем только код ('UPS') и описание ( 'United Parcel Service'), то вы можете просто добавить столбец или два. Вы могли бы даже расширить таблицу, чтобы дать полную информацию о бизнесе, представленном курьерами. · Более мелкие доменные таблицы будут умещаться на единственной дисковой странице. Это гарантирует единственную операцию чтения (и вероятное нахождение этой страницы в кэше). В противном случае, ваша доменная таблица может занимать много страниц и, если не выполнить кластеризацию для этой таблицы, обращение к ней будет более дорогостоящим при использовании некластеризованного индекса в случае большого числа значений. · Вы по-прежнему можете иметь один редактор для всех строк, поскольку большинство доменных таблиц будет вероятно иметь одну и ту же базовую структуру/использование. Правда, вы теряете способность легко получить все доменные значения в одном запросе, но к чему вам это? (Запрос с объединением мог бы легко быть создан из этих таблиц, если это понадобится, но это представляется маловероятным.) Я должен, вероятно, опровергнуть мысль, которая может у вас возникнуть. "Что, если мне понадобится добавить новый столбец ко всем доменным таблицам?" Например, Вы забыли, что клиенту потребуется выполнить пользовательскую сортировку по доменным значениям и ничего не предусмотрели в таблицах, чтобы иметь возможность реализовать это. Справедливый вопрос, особенно если Вы имеете 1000 таких таблиц в очень большой базе данных. Но, во-первых, это редко случается, и когда это имеет место, то в любом случае вам придется вносить существенные изменения в вашу базу данных. Во-вторых, даже если это стало востребованной задачей, SQL имеет полный набор команд, которые Вы можете использовать, чтобы добавить столбцы в таблицы, а использование системных таблиц дает возможность довольно просто построить скрипт для добавления одного и того же столбца в сотни таблиц сразу. Это будет не столь простым изменением, но и не настолько трудным, чтобы перевесить большие выгоды. Назначение данного совета заключается в том, что лучше делать работу добросовестно, создавая стабильные и легко поддерживаемые структуры, вместо того, чтобы попытаться выполнить наименьший объем работы для скорейшего запуска проекта. Сведение таблиц к представлению одной "вещи" означает, что большинство изменений затронет только одну таблицу, из чего следует, что в будущем вас ожидает меньше переделок. (продолжение следует...) Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § В продаже еще имеется книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
