| ← Май 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) 141
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 141 (26 мая 2007 г.)
Новости сайта§ Davh продолжил править английские формулировки по мере продвижения в рейтинге. На этот раз это коснулось задачи 79. § Разместил на страницах сайта кнопочку § Продвинулись в рейтинге: § На этой неделе сертифицированы: § Число подписчиков - 3543 Число участников рейтинга - 10466 Число участников второго этапа - 977 Сертифицировано на сайте - 157 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLДесять характерных ошибок в проектировании базы данных (продолжение, начало в вып.138)Louis Davidson (оригинал: Ten Common Database Design Mistakes )Перевод Моисеенко С.И. Использование столбцов identity/guid в качестве единственного ключаПервая Нормальная Форма диктует, что все строки в таблице должны однозначно идентифицироваться. Следовательно, каждая таблица должна иметь первичный ключ. SQL Server позволяет Вам определить числовой столбец как столбец IDENTITY, после чего автоматически генерируются уникальные значения для каждой добавляемой строки. Кроме того, Вы можете использовать NEWID () (или NEWSEQUENTIALID ()) для генерации случайного 16-байтового уникального значения для каждой строки. Такие типы значений, когда они используется как ключи, называются суррогатными ключами. Слово "суррогатный" означает "что-либо для замены", и в данном случае, суррогатный ключ должен стать заменой естественного ключа. Проблема состоит в том, что слишком много проектировщиков используют столбец суррогатного ключа в качестве единственного ключевого столбца на данной таблице. Значения суррогатного ключа не представляют никакого фактического значения в реальном мире; они предназначены исключительно для того, чтобы однозначно идентифицировать каждую строку. Давайте рассмотрим следующую таблицу Part, в которой PartID является столбцом IDENTITY и первичным ключом таблицы:
Сколько рядов находится в этой таблице? Ну, кажется, что три, однако не являются ли строки с PartIDs 1 и 2 фактически одной и той же строкой, т.е. дубликатами? Или же это две различных строки, которые должны быть уникальными, но были определены неправильно? Эмпирическое правило, которое я использую, звучит просто. Если человек не в состоянии выбрать, какая строка таблицы ему нужна без знания суррогатного ключа, то Вы должны пересмотреть структуру вашего проекта. Вот почему должен иметься некоторый ключ в таблице, чтобы гарантировать уникальность, в нашем случае это, вероятно, PartNumber. В качестве правила: каждая из ваших таблиц должна иметь естественный ключ, который что-то означает для пользователя и может уникально идентифицировать каждую строку в вашей таблице. В очень редких случаях, когда Вы не можете найти естественный ключ (возможно, например, для таблицы, которая обеспечивает регистрацию событий), тогда используйте искусственный/суррогатный ключ. Не использование средств SQL для поддержания целостности данныхВсе фундаментальные, неизменные бизнес-правила должны быть реализованы средствами реляционного механизма. Основные правила допустимости NULL значений, длины строки, назначения внешних ключей, и так далее, все должны быть определены в базе данных. Есть много различных способов импортировать данные в SQL Server. Если ваши основные правила определены в самой базе данных, это сможет Вам гарантировать, что они никогда не будут обойдены, а Вы сможете писать свои запросы, совершенно не беспокоясь, отвечают ли данные, которые Вы рассматриваете, основным бизнес-правилам. Правила, которые являются дополнительными, с другой стороны, являются верными кандидатами на то, чтобы переместить их в бизнес-слой приложения. Рассмотрим, например, такое правило: "В первую половину месяца никакая деталь не может быть продана с больше чем 20%-ой скидкой без одобрения менеджера". В целом, эти правило звучит не очень четко, не очень хорошо контролируется, и подвержено частым изменениям. Например, что произойдет, когда на следующей неделе максимальная скидка составит 30 %? Или когда определение "первой половины месяца" изменится на "от 15 дней до 20 дней"? Наиболее вероятно, что Вы не захотите переносить трудности реализации этих сложных временных бизнес-правил в код SQL Server; бизнес-слой - лучше место, чтобы реализовать такие правила там. Однако рассмотрите правило более внимательно. Тут есть элементы, которые, вероятно, никогда не будут изменяться. Например. Эти аспекты бизнес-правила очевидно должны предписываться базой данных и схемой. Даже если сущность правила применяется в бизнес-слое, Вам все же потребуется иметь таблицу в базе данных, в которую записывается размер скидки, дата, когда она предлагалась, идентификатор личности, который ее одобрил и так далее. На столбце Discount Вы должны иметь ограничение CHECK, которое ограничит допустимые значения интервалом между 0.00 и 0.90 (или любым другим максимумом). Мало того, что это применит ваше правило "максимальной скидки", но также будет служить средством защиты от пользователя, входящего скидку 200 % или отрицательную скидку по ошибке. На столбце ManagerID Вы должны поместить ограничение внешний ключа, который ссылаются на таблицу менеджеров (Managers), и гарантирует, что введенный идентификатор соответствует личности реального менеджера (или, как альтернативу, триггер, который выбирает только те EmployeeIds, которые соответствуют менеджерам). Теперь, по крайней мере, мы можем быть уверены, что данные удовлетворяют всем основным правилам, которым они должны подчиняться, и, таким образом, нам никогда не придется кодировать кое-что подобное, чтобы проверить, что данные хороши:
SELECT CASE WHEN discount < 0 then 0 else WHEN discount > 1 then 1… Мы можем чувствовать себя в безопасности, т.к. данные удовлетворяют основным критериям, в каждый момент времени. (окончание следует...) Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § В продаже еще имеется книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
(ниже блока для голосования), которая предоставляет возможность выбирать ресурс для сохранения закладок на сайты. Правда в списке отсутствуют ресурсы зоны RU. | В избранное | ||
