Стиль программирования Джо Селко на SQL
Автор:
Джо Селко
Издательство: Питер, 2006
206 страниц
Аннотация
Содержание
Введение
Аннотация
Книга предназначена программистам, работающим с SQL и желающим повысить свою квалификацию.
В ней рассматриваются вопросы, связанные с созданием стандартизованных SQL-приложений, не
привязанных к конкретным SQL-продуктам, приводятся многочисленные практические
рекомендации по созданию наиболее эффективных и универсальных кодов. Рассматриваются
правила назначения имен элементам данных, оформления программ, разработки выражений DDL и
DML. Описано использование представлений и хранимых процедур. Отдельные главы посвящены
общим теоретическим вопросам, связанным с теорией измерений и разработкой систем
кодирования для элементов баз данных. Книга состоит из 10 глав, библиографии и приложения,
содержащего справочную информацию по различным стандартам, пригодным для использования в
различных базах данных.
Содержание
Предисловие
Введение
Глава 1 Имена и элементы данных
Имена
Следите за длиной имен
Не используйте в именах спецсимволы
По возможности не используйте идентификаторы в кавычках
Разработайте строгие правила использования прописных букв
Создавайте имена согласно стандарту ISO-11179
ISO-11179 для SQL
Уровни абстрагирования
Избегайте описательных префиксов
Разработайте стандартную систему суффиксов
Имена таблиц и представлений должны подчиняться стандартам и выражаться существительными множественного числа
Имена корреляций подчинены тем же правилам, что и другие имена. Почти всегда
Имена таблиц-отношений должны быть общепринятыми, понятными терминами
В имена объектов доступа к метаданным схемы можно включать структурную информацию
Ошибки в именовании элементов данных
Избегайте невнятных имен
Избегайте имен, которые меняются от места к месту
Не используйте нестандартные физические указатели
Глава 2 Шрифты, пунктуация и интервалы
Типографика кода
Используйте в именах только буквы, цифры и символы подчеркивания
Используйте буквы нижнего регистра в скалярах - именах столбцов, параметрах и переменных
Начинайте имена объектов схемы с прописной буквы
Записывайте прописными буквами зарезервированные слова
Не используйте прописных букв в середине слова
Пробелы
Применяйте естественные правила пунктуации
Не сокращайте зарезервированные слова
Отдавайте предпочтение стандартным ключевым словам SQL
Отдавайте предпочтение стандартным конструкциям SQL
Коридоры и вертикальное выравнивание
Отступы
Группируйте операторы с помощью пустых строк
Глава 3 Язык объявления данных
Правильно размещайте значение по умолчанию
Тип значения по умолчанию должен совпадать с типом данных столбца
Не используйте нестандартные типы данных
Размещайте объявление PRIMARY KEY в начале оператора CREATE TABLE
Располагайте столбцы в логической последовательности и объединяйте их в логические группы
Выделяйте отступами ссылочные ограничения и действия
Давайте имена ограничениям
Размещайте проверки CHECK() рядом с проверяемым элементом
Используйте ограничения диапазона численных значений
Используйте для строковых значений ограничения LIKE и SIMILAR TO
Помните, что параметрам времени присуща длительность
Старайтесь не использовать типы данных REAL и FLOAT
Ограничения, охватывающие несколько столбцов, размещайте максимально близко к этим столбцам
Размещайте ограничения CHECK() табличного уровня в конце объявления таблицы
Используйте для многотабличных ограничений выражение CREATE ASSERTION
Используйте для каждой проверки собственное ограничение CHECK()
Если у таблицы нет ключа, это не таблица
Автонумерация не может использоваться в качестве реляционного ключа
Файлы - не таблицы
Подбирайте ключи с подходящими свойствами
Не разделяйте атрибуты
Разделение по таблицам
Разделение по столбцам
Разделение по строкам
Не применяйте в реляционной БД объектно-ориентированный дизайн
Таблица не является экземпляром объекта
Не используйте в реляционных БД дизайн ''сущность-атрибут-значение''
Глава 4 Шкалы и измерения
Теория измерений
Непрерывные и дискретные величины
Диапазон
Градуировка, погрешность и точность
Виды шкал
Шкалы наименований
Шкалы категорий
Абсолютные шкалы
Порядковые шкалы
Шкалы ранга
Шкалы интервалов
Шкалы отношений
Применение шкал
Преобразование шкал
Производные единицы
Разделители и обозначения единиц
Рекомендации по использованию шкал в базах данных
Глава 5 Схемы кодировки данных
Плохие схемы кодировки
Типы схем кодировки
Перечисляющая кодировка
Кодировка единиц измерения
Кодировка аббревиатурами
Алгоритмические коды
Иерархические схемы кодировки
Векторные коды
Составные коды
Общие правила разработки кодировок
Опирайтесь на существующие стандарты кодирования
Предусматривайте возможность расширения
Явно задавайте коды для отсутствующих значений
Не показывайте коды пользователю
Храните коды в базе данных
Многосимвольные кодировки
Глава 6 Выбор подхода к написанию кода
Отдавайте предпочтение стандартным конструкциям
Используйте стандартный синтаксис OUTER JOIN
Используйте синтаксис ISO для времени
Используйте стандартные и переносимые функции
Используйте максимально компактные конструкции
Избегайте лишних скобок
Использование выражений CASE
Избегайте лишних выражений
Ищите наиболее компактную форму
Используйте комментарии
Хранимые процедуры
Комментарии к управляющим операторам
Комментарии к конструкциям
Избегайте подсказок оптимизатору
Используйте DRI-каскадирование вместо триггеров
Используйте хранимые процедуры SQL
Избегайте пользовательских функций и расширений
Проблемы с многоязыковой поддержкой
Проблемы с переносимостью
Проблемы оптимизации
Избегайте вторичных индексов
Избегайте связанных подзапросов
Избегайте предложений UNION
Тестирование SQL
Тестируйте все возможные комбинации NULL-значений
Тестируйте все ограничения CHECK()
Будьте внимательны к символьным столбцам
Проверяйте зависимость от размера
Глава 7 Представления
Имена представлений подчинены тем же правилам, что и имена таблиц
Всегда указывайте имена столбцов
Представления обеспечивают безопасность на уровне строк и столбцов
Представления обеспечивают эффективные пути доступа
Представления скрывают от пользователя сложность задачи
Представления обеспечивают корректность производных данных
Представления позволяют переименовывать столбцы и таблицы
Представления обеспечивают выполнение сложных проверок целостности
Обновляемые представления
Конструкция WITH CHECK OPTION
Триггеры INSTEAD OF
Не создавайте представления просто так
Не давайте представлениям размножаться
Синхронизируйте представления с базовыми таблицами
Неправильное использование представлений
Использование представлений для поддержки доменов
Незаменимые представления
Не подменяйте базовую таблицу представлением
Используйте материализованные представления
Глава 8 Хранимые процедуры
Большинство 4GL-языков SQL не предназначены для разработки приложений
Основы разработки программ
Связность
Сцепление
Используйте классическое структурное программирование
Цикломатическая сложность
Не создавайте себе проблем с переносимостью
Не создавайте временные таблицы
Не используйте курсоры
Конструкции для наборов данных предпочтительнее процедурного кода
Скалярные и структурированные параметры
Не пользуйтесь динамическим SQL
Быстродействие
SQL-инъекция
Глава 9 Эмпирические правила кодирования
Четко формулируйте спецификации
Представляйте все существительные наборами
Удаляйте глаголы из предложений, описывающих абстрактную модель
Вам по-прежнему доступны ''заглушки''
Не беспокойтесь об отображении данных
Первые шаги в SQL требуют специального подхода
Плохой DDL должен быть отброшен
Сохраняйте DML-наработки
Не мыслите категориями блок-схем
Рисуйте диаграммы для множеств
Изучайте свой диалект
Представьте, что предложение WHERE обладает ''многопроцессорной архитектурой''
Используйте группы новостей и Интернет
Глава 10 Думаем на SQL
Плохой стиль программирования на SQL и процедурных языках
Отождествление столбцов с полями данных
Мышление категориями процессов, а не описаний
Попытка заставить схему выглядеть как бланк
Приложение 1 Справочная информация
Военные стандарты
Стандарты метаданных
Стандарты ANSI и ISO
Коды правительства США
Розничная торговля
Оформление кода и правила назначения имен
Приложение 2 Библиография
Введение
В этой книге я вовсе не пытаюсь учить вас программировать на SQL. Хотите - прочитайте предыдущее предложение еще раз. Если вас интересует именно обучение, есть учебники и получше. Эта книга призвана стать вашей второй книгой по SQL, но отнюдь не первой.
Я предполагаю, что вы уже обладаете некоторыми навыками программирования на SQL и теперь хотите их усовершенствовать. Чтобы познакомиться с тонкостями SQL, почитайте другую мою книгу - SQL for Smarties (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. Говоря точнее:
- Помочь отдельному программисту писать программы на стандартном SQL, без акцента и диалекта Отказаться от старых привычек трудно, но не невозможно. Лучше же всего учиться правильному образу действий с самого начала. Любитель пишет код для себя. Профессионал разрабатывает программу, которую будут использовать и обслуживать другие люди. Мой опыт говорит, что пройдет не меньше года программирования на SQL, прежде чем на вас снизойдет просветление и вы увидите триединство мира: логика, модели данных и множества.
- Предоставить коллективу программистов внутренний стандарт программирования Каждому правилу я пытался дать продуманное обоснование, а также рассказал об исключениях там, где мне удалось их увидеть. Вы вольны не согласиться с некоторыми из моих предложений, но тогда уж извольте провести исследование и подкрепить свою позицию примерами. Вряд ли можно считать аргументом заявления типа: ''Да мы в нашей конторе всегда так программируем, стало быть, такова воля Божья!''.
Руководителю коллектива, опирающегося на мои правила, в случае недовольства сотрудников всегда можно будет обвинить во всем книгу (и ее автора). Благодаря ей вы сохраните согласованность действий. Даже если позже окажется, что я в чем-то ошибся, значительно проще исправлять ошибки, сделанные в единой системе.
- Предоставить программистам необходимые инструменты для оценки решаемой проблемы с точки зрения SQL Не устаю повторять, что требуется не меньше года, чтобы ''въехать'' в SQL и избавиться от привычек, навязанных процедурным программированием.
Сообщений 1 
Оценка 0
[+0/-4]
Оценить 
