ГЛАВА 1. Имена и элементы данных. 5

ГЛАВА 2. Шрифты, пунктуация и интервалы.. 17

ГЛАВА 3. Язык объявления данных. 27

ГЛАВА 4. Шкалы и измерения. 42

ГЛАВА 5. Схемы кодировки данных. 49

ГЛАВА 6. Выбор подхода к написанию кода. 57

ГЛАВА 7. Представления. 78

ГЛАВА 8. Хранимые процедуры.. 89

ГЛАВА 9. Эмпирические правила кодирования. 100

ГЛАВА 10. Думаем на SQL. 107

ПРИЛОЖЕНИЕ 1. 115

ПРИЛОЖЕНИЕ 2. 117

ВВЕДЕНИЕ В этой книге я вовсе не пытаюсь учить вас программировать на SQL. Хотите — прочитайте предыдущее предложение еще раз. Если вас интересует именно обучение, есть учебники и получше. Эта книга призвана стать вашей второй книгой по SQL, но отнюдь не первой. Я предполагаю, что вы уже обладаете некоторыми навыками программирования на SQL и теперь хотите их усовершенствовать. Чтобы познакомиться с тонкостями SQL, почитайте другую мою книгу — SQLforSmarties (3-е издание, 2005). Я стараюсь ставить в основу обучения логичность и ясность и учить читателя мыслить в декларативных терминах, а не в терминах процедурного или объектно-ориентированного программирования. Вряд ли найдется SQL-программист, не обладающий многолетним стажем работы с каким-либо процедурным или объектно-ориентированным языком. Обыкновенно предлагают освоить один конкретный SQL-продукт, выучив язык методом проб и ошибок или по книге с заголовком наподобие “SQL для идиотов”, “Учим SQL за десять легких или пять трудных уроков”, а то и похуже. Это просто абсурд! Человеку требуется не менее пяти лет, чтобы стать квалифицированным плотником или поваром. Почему же считается, что превратиться в гуру SQL он может за пару дней? За эго время реально стать лишь плохим SQL-программистом, который разговаривает на диалекте SQL из популярного в данном месте SQL-продукта, к тому же с сильным акцентом от известных ему других языков программирования. Чтобы вернуться с облаков на землю, почитайте Teach Yourself Programming in Ten YearsПитера Норвига (Peter Norvig, www.norvig.com/21-days.html) или статью No Silver Bullets Фреда Брукса (Fred Brooks), опубликованную в апреле 1987 г. журналом Computer (№ 20 (4), с. 10-19). Беда еще и в том, что жертвы подобной системы обучения часто не осознают, что являются плохими программистами. Бывает так, что весь коллектив работает по схожим правилам, так что они ничего другого просто не видели. Иные же “лезут в бутылку”, если кто-то пытается указать им на недостатки. Взгляните на сообщения в группах новостей, посвященных SQL, и вы увидите, что большинство программистов желает не расправиться с проблемой всерьез и надолго, а просто получить сиюминутное решение для конкретной ситуации. В группах новостей по изготовлению мебели их вопросы звучали бы так: “Каким камнем лучше всего забивать шурупы в красное дерево?”. Чтобы осчастливить такого программиста, ему достаточно посоветовать большую гранитную глыбу. Но попробуйте рассказать ему об отвертке — вызовете вспышку гнева в свой адрес. Цель книги Как же учились быть хорошими программистами мы, старики, когда Землей правили динозавры? В конце 1970-х, когда в нашу жизнь вошло структурированное программирование, одним из лучших наших помощников стала серия книг “[Pascal | FORTRAN | COBOL | BASIC] with Style: Programming Proverbs”, написанная Генри Ледгардом (Henry Ledgard) и несколькими его коллегами из Массачусетского технологического института. Их обложки оформлялись в духе викторианского романа: с ангелами, свитками, старомодными типографскими элементами. Каждой книге, как викторианскому роману, полагался подзаголовок типа “Основы хорошего программирования с многочисленными примерами для усовершенствования стиля и сноровки”. Эти и другие книги сыграли большую роль в жизни большинства из нас, поскольку научили думать так, как должны думать хорошие программисты. В этом же состоит цель и моей книги — усовершенствовать стиль и качество программирования на SQL Говоря точнее: 1. Помочь отдельному программисту писать программы на стандартном SQL, без акцента и диалекта.Отказаться от старых привычек трудно, но не невозможно. Лучше же всего учиться правильному образу действий с самого начала. Любитель пишет код для себя. Профессионал разрабатывает программу, которую будут использовать и обслуживать другие люди. Мой опыт говорит, что пройдет не меньше года программирования на SQL, прежде чем на вас снизойдет просветление и выувидите триединство мира: логика, модели данных и множества. 2. Предоставить коллективу программистов внутренний стандарт программирования.Каждому правилу я пытался дать продуманное обоснование, а также рассказал об исключениях там, где мне удалось их увидеть. Вы вольны не согласиться с некоторыми из моих предложений, но тогда уж извольте провести исследование и подкрепить свою позицию примерами. Вряд ли можно считать аргументом заявления типа: “Да мы в нашей конторе всегда так программируем, стало быть, такова воля Божья!”. Руководителю коллектива, опирающегося на мои правила, в случае недовольства сотрудников всегда можно будет обвинить во всем книгу (и ее автора). Благодаря ей вы сохраните согласованность действий. Даже если позже окажется, что я в чем-то ошибся, значительно проще исправлять ошибки, сделанные в единой системе. 3. Предоставить программистам необходимые инструменты для оценки решаемой проблемы с точки зрения SQL.He устаю повторять, что требуется не меньше года, чтобы “въехать” в SQL и избавиться от привычек, навязанных процедурным программированием. Благодарности Структура главы о представлениях принадлежит Крейгу Маллинсу (Craig Mullins) (см. статью для www.DBAzine.com). Стиль форматирования позаимствован из моих публикаций за последнее десятилетие в журналах СМР и других. Данные о правилах присвоения имен в реальных продуктах предоставил Питер Гулутзан (Peter Gulutzan) — также в статье для www.DBAzine.com. Правила разработки приставок к именам в главе 1 основаны на внутренних стандартах корпорации Teradata. Масштабы, величины и схемы кодирования фигурировали в нескольких моих старых колонках в журналах DBMS и Database Programming&Design, а затем были объединены в моей книге Data & Database. В тексте я всегда старался упомянуть моих помощников, но в группах новостей участников так много, что я несомненно кого-то пропустил. Разумеется, я благодарен Генри Ледгарду за серию “Programming Proverbs”, которая служила мне источником вдохновения. Особенная благодарность — новичкам-программистам, пишущим плохие программы. Это замечание кажется саркастическим, но таковым не является. Многие из них столкнулись с DBA или SQL по воле руководства, которое не обеспечило их обучением или опытным наставником. Их не в чем обвинить, конечно, если они не упорствовали в своем невежестве. Их ошибки в синтаксисе, семантике и стиле показали мне, как они думают. Правильный диагноз — первый шаг к излечению. Исправления, замечания и последующие издания Исправления и дополнения к будущим изданиям направляйте непосредственно в издательство Morgan-Kaufmann или мне по электронному адресу [email protected].

ГЛАВА 1.
Имена и элементы данных

Есть такой старый анекдот. — Когда я был маленьким, у нас было три кошки. — И как их звали? — Кошка, кошка и кошка. — Ерунда какая-то. Как же вы их различали? — А какая разница? Кошки все равно на имена не откликаются!

Наши данные тоже не придут к вам на зов, если вы не присвоите им четкие и понятные имена. Это важная часть любого проекта базы данных (БД). Неудачные имена для элементов данных приводят к тому, что код бывает трудно, а то и невозможно прочитать.
Невозможность чтения — не шутка. В старину компании, разрабатывавшие программное обеспечение, нарочно искажали имена и удаляли из исходного кода форматирование, чтобы скрыть от покупателей алгоритм. Эта традиция все еще жива, хотя, может быть, изначальное намерение и утрачено. В августе 2004 г. в одной из групп новостей по SQL была опубликована программа, в которой все имена состояли из одной буквы и длинной цепочки цифр.
В настоящее время существуют стандарты метаданных ISO-11179, описывающие правила именования элементов данных и регистрации стандартов. Поскольку это стандарт ISO, его надлежит применять не только в SQL, но и вообще везде.
Стандартизация, немного печатного мастерства и некоторый здравый смысл — вот слагаемые успешной работы.

Имена

В старые добрые времена у каждого программиста были собственные правила назначения имен. К несчастью, зачастую они оказывались весьма замысловатыми. Лично мне особенно нравился парень, который для имен в программах на Коболе выбирал специфическую тему: для одной программы — страны, для другой — цветы и т. д. Это, конечно, чересчур даже для программиста, но вообще системы имен, смысл которых понятен только автору, но не посторонним, встречаются часто.
Скажем, первый Фортран, с которым я работал, допускал имена не длиннее шести символов, поэтому я стал адептом шестибуквенных имен. Программисты, которые начинали со слабо типизированных языков или с языков без типов, испытывают привязанность к венгерской нотации. От старых привычек трудно отказываться.
Когда разработка ПО перестала быть уделом одиночек, каждая фирма создавала собственные правила именования и закрепляла их в своеобразных словарях. Вероятно, наиболее распространены были правила MIL STD 8320.1, разработанные Министерством обороны США, но вне федерального правительства популярными они так и не стали. Разработка фирменных стандартов, безусловно, представляла собой шаг вперед по сравнению с прежней бессистемностью, но в каждой фирме каноны чем-то отличались. В одних действительно создавались формальные правила назначения имен, в других за элементом данных просто закреплялось первое присвоенное ему имя.
Теперь у нас есть стандарты ISO-11179, которые распространяются все шире, стали обязательными для некоторых правительственных заказов и включаются в продукты для работы с хранилищами данных. В этот стандарт встроены инструменты и хранилища стандартизованных схем кодирования. Одним словом, будущее принадлежит ISO-11179 и XML как стандартному формату обмена данными.

Следите за длиной имен

Обоснование
В стандарте SQL-92 длина идентификатора ограничена 18 символами, как это было в старых стандартах Кобола. В современных реализациях SQL допускаются более длинные имена, но на самом деле вряд ли есть что-то, что нельзя выразить 18 символами. Максимальные длины имен наиболее важных объектов схемы SQL в стандартах ISO и некоторых популярных SQL-продуктах приводятся в табл. 1.1.

Табл. 1.1. Длины идентификаторов

	SQL-92	SQL-99	IBM	MS SQL	Oracle
Столбец
Ограничение
Таблица

Числа в таблице выражены в байтах или символах. Максимальная длина в символах может быть меньше максимальной длины в байтах, если вы используете многобайтовый набор символов.
Не увлекайтесь сверхдлинными именами. Людям предстоит их читать, набирать и распечатывать. Им также придется разбираться в их смысле, искать в словаре данных и т.п. Наконец, имена могут использоваться в хост-программах, у которых будут собственные ограничения на их длину.
Но и в другую крайность ударяться тоже не надо. Во времена, когда длина столбца была ограничена 18 байтами, в Bachman — старом средстве разработки баз данных DB2 — иногда логическое имя атрибута преобразовывалось в физическое имя столбца путем удаления из него всех гласных. Вряд ли можно назвать этот подход удачным. В таких “конденсированных” именах можно разобраться только после многодневного исследования.

Исключения
Исключения будут встречаться лишь от случая к случаю, вероятно, в результате столкновения со старыми системами, в которых на имена накладываются другие ограничения.