| ← Май 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) 139
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 139 (12 мая 2007 г.)
Новости сайта§ С помощью Davh уточнил английские формулировки задач 67 и 75. § Новые лица в сотне: § Продвинулись в рейтинге: § На этой неделе сертифицированы: § Число подписчиков - 3558 Число участников рейтинга - 10249 Число участников второго этапа - 955 Сертифицировано на сайте - 156 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLДесять характерных ошибок в проектировании базы данных (продолжение, начало в вып.138)Louis Davidson (оригинал: Ten Common Database Design Mistakes )Перевод Моисеенко С.И. Слабые стандарты именования"То, что мы называем розой, будет также сладко пахнуть и под любым другим именем." Эта цитата из Ромео и Джульетты Уильяма Шекспира звучит прекрасно и справедлива, с одной стороны. Если мы теперь согласимся назвать розу экскрементами, то ничего не изменится, и она будет пахнуть так же сладко. Проблема же состоит в том, что если, строя базу данных для цветочного бизнеса, проектировщик называет ее экскрементами, а клиент - розой, тогда Вам предстоят встречи, которые значительно больше походят на миниатюру Эббота и Костелло (комедийный дуэт), чем на серьезную беседу относительно хранении информации о продуктах садоводства. Имена, хотя они и определяются личным выбором, являются первой и самой важной чатью документации для вашего приложения. Я не буду вдаваться в детали относительно того, как лучше всего именовать объекты, - это большая и темная тема. На чем я хочу акцентироваться, - это необходимая последовательность. Имена, которые Вы выбираете, не просто позволяют Вам идентифицировать назначение объекта, они должны позволить всем будущим программистам, пользователям и так далее быстро и легко понять, как должна использоваться та или иная часть вашей базы данных, и какие данные она содержит. Ни один будущий пользователь вашего проекта не должен продираться через документ в 500 страниц, чтобы определить назначение некоего дурацкого имени. Рассмотрим, например, столбец с именем X304_DSCR. Что это может означать? Вы могли бы после некоторого умственного напряжения решить, что это означает "описание X304"(description). Возможно это и так, но DSCR может означать и дискриминатор, и дискретизатор? Если Вы не установили DSCR как корпоративное стандартное сокращение для "описания", тогда X304_DESCRIPTION - намного лучшее название, и не оставляет простора воображению. Осталось выяснить, что означает часть названия X304. На мой взгляд, X304 больше походит для данных в столбце, но не для его имени. Если бы я впоследствии обнаружил, что в организации были также X305 и X306, то я бы пришел к выводу, что имеется проблема с проектом базы данных. Максимальную гибкость дает хранение данных в столбцах, но не в именах столбцов. По этим тем же самым соображениям, противьтесь искушению использовать "метаданные" в качестве имени объекта. Имена типа tblCustomer или colVarcharAddress могут показаться полезными с точки зрения разработки, однако конечного пользователя они могут только запутать. Как разработчик, Вы должны основываться на том, что в состоянии определить, что имя таблицы - это имя таблицы по контексту кода или инструмента, и предоставить пользователям ясные, простые и информативные имена типа Customer (клиент) и Address (адрес). Практика, против которой я постоянно выступаю, - это использование пробелов и закавыченных идентификаторов в именах объектов. Вам следует избегать таких имен столбцов, как " Part Number" или - в стиле Microsoft - [Part Number], и, следовательно, требуя, чтобы Ваши пользователи также включали такие пробелы и идентификаторы в собственные коды. Это раздражает и просто не нужно. Приемлемыми альтернативами были бы part_number, partNumber или PartNumber. Опять же, ключевым здесь является последовательность. Если Вы выбираете PartNumber, это прекрасно, если столбец, содержащий номера счетов, называют InvoiceNumber, но не одним из других возможных вариантов. Отсутствие документацииЯ намекнул во введении, что в некоторых случаях я пишу в той же мере для себя, сколь и для Вас. Для данной статьи это верно в большей степени. Тщательно продуманная система именования объектов, столбцов и так далее поможет каждому понять, что моделирует ваша база данных. Однако это только первый шаг в борьбе с документацией. К сожалению, действительность такова, что этот "первый шаг" так и остается единственным. Мало того, чтобы хорошо разработанная модель данных твердо придерживалась принятого стандарта обозначения, необходимо также иметь такие определения таблиц, столбцов, связей, и даже ограничений типа CHECK и значений по умолчанию для того, чтобы каждому было ясно, как предполагается их использовать. Во многих случаях Вы можете захотеть включить типовые значения, возможные для объекта, и что-нибудь еще с тем, чтобы иметь возможность в будущем через год или два вернуться и внести изменения в код. Замечание: Ваша цель должна состоять в том, чтобы обеспечить достаточно информации, зато тогда, когда Вы передадите базу данных программисту поддержки, он может выявить ваши незначительные ошибки и устранить их (да, все мы делаем ошибки в нашем коде!). Я вспоминаю старую шутку о том, что плохо документированный код - синоним "обеспеченности работой." Хотя в этом есть доля истины, это путь к ненависти со стороны сотрудников и помеха в продвижения по службе. И никакой хороший программист из тех, кого я знаю, не захочет вернуться к переделке своих собственных кодов годы спустя. Лучше всего, если ошибки в коде сможет устранить младший программист поддержки, в то время как Вы создаете следующую новую вещь. Обеспеченность работой наряду с карьерным ростом будет достигнута, если постоянно принимать новые вызовы. (продолжение следует...) Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § В продаже еще имеется книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
