|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Глава из книги “Стиль программирования Джо Селко на SQL”
Время создания: 18.09.2019 21:59
Текстовые метки: SQL, стиль программирования
Раздел: Компьютер - C# - Стиль кода
Запись: Kozlov-AE/Tetra/master/base/1565372674f6x2n3zgli/text.html на raw.githubusercontent.com
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Имена и элементы данных Глава из книги “Стиль программирования Джо Селко на SQL” Автор: Джо Селко Опубликовано: 09.04.2006
— Когда я был маленьким, у нас было три кошки. — И как их звали? — Кошка, кошка и кошка. — Ерунда какая-то. Как же вы их различали? — А какая разница? Кошки все равно на имена не откликаются! Ваши данные тоже не придут к вам на зов, если вы не присвоите им четкие и понятные имена. Это важная часть любого проекта базы данных (БД). Неудачные имена для элементов данных приводят к тому, что код бывает трудно, а то и невозможно прочитать. Невозможность чтения — не шутка. В старину компании, разрабатывавшие программное обеспечение, нарочно искажали имена и удаляли из исходного кода форматирование, чтобы скрыть от покупателей алгоритм. Эта традиция все еще жива, хотя, может быть, изначальное намерение и утрачено. В августе 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. Длины идентификаторов Числа в таблице выражены в байтах или символах. Максимальная длина в символах может быть меньше максимальной длины в байтах, если вы используете многобайтовый набор символов. Не увлекайтесь сверхдлинными именами. Людям предстоит их читать, набирать и распечатывать. Им также придется разбираться в их смысле, искать в словаре данных и т. п. Наконец, имена могут использоваться в хост-программах, у которых будут собственные ограничения на их длину. Но и в другую крайность ударяться тоже не надо. Во времена, когда длина столбца была ограничена 18 байтами, в Bachman — старом средстве разработки баз данных DB2 — иногда логическое имя атрибута преобразовывалось в физическое имя столбца путем удаления из него всех гласных. Вряд ли можно назвать этот подход удачным. В таких «конденсированных» именах можно разобраться только после многодневного исследования. Исключения Исключения будут встречаться лишь от случая к случаю, вероятно, в результате столкновения со старыми системами, в которых на имена накладываются другие ограничения. Не используйте в именах спецсимволы Обоснование Если в имя включены специальные символы, становится трудно или даже невозможно использовать это имя в БД или в программе на хост-языке, а также переместить схему в другой SQL-продукт. В табл. 1.2 приведены символы, которые могут быть частью имени в стандартном SQL и в популярных SQL-продуктах.
Табл. 1.2. Символы, допустимые в именах Как правило, первым символом имени должна быть буква, а остальные символы могут быть буквами, цифрами и символом подчеркивания «_». В различных СУБД допускается применение также символов $, # или @, но ни в одной СУБД не допускается применение всех трех сразу. Вообще, нет ни одного спецсимвола, который можно было бы спокойно использовать в любом продукте. В ПО Microsoft, например, имена, начинающиеся символами @ или #, имеют особое значение. В Oracle нельзя использовать спецсимволы в именах некоторых объектов. Да и с буквами все ли ясно? В оригинальном SQL разрешалось использовать только латинские буквы верхнего регистра, что означает 26 вариантов. В наши дни репертуар несколько расширился, но не злоупотребляйте буквами, не входящими в набор символов Latin-1, и вот почему.
В стандарте SQL-92 не разрешается заканчивать идентификатор символом подчеркивания. Не стоит также вставлять в имя несколько подчеркиваний подряд. При современном лазерном качестве печати пересчитать их будет сложновато. Исключения Нет. По возможности не используйте идентификаторы в кавычках Обоснование Идентификаторы в кавычках (quoted identifiers) впервые появились в стандарте SQL-92. Предполагалось, что они будут использоваться для создания псевдонимов столбцов, улучшая читаемость распечаток. В реальности же они противоречат принципам многоуровневой архитектуры, ставят под вопрос переносимость кода и провоцируют программиста на создание неуклюжих систем имен. Основные характеристики идентификаторов с ограничителями (delimited identifiers) суммируются в табл. 1.3.
Табл. 1.3. Символы, допустимые в идентификаторах с ограничителями Если правила использования символов в именах кажутся вам слишком жесткими, вы вольны обойти их, поместив идентификатор в двойные кавычки. В результате получится так называемый идентификатор с ограничителями (или идентификатор в кавычках, в терминологии Oracle). Идентификатор с ограничителями может начинаться с любого символа и вообще содержать любой символ. Конечно, возникает неясность с использованием внутри идентификатора самого символа ". Стандартный способ — записать его дважды («Работ""ники»), но в документации он явно описан не всегда. Поддержка имен с ограничителями практически универсальна, с двумя важными исключениями: 1) продукты IBM допускают использование только букв и цифр для меток и имен переменных в хранимых процедурах; 2) в продуктах Microsoft не разрешается использовать идентификаторы в кавычках при сброшенном флаге QUOTED_IDENTIFIER. Первое исключение связано, вероятно, с тем, что в продуктах IBM процедуры SQL перед компиляцией «переводятся» на другой компьютерный язык. Рассмотрим в качестве примера создание таблицы с делимитированным идентификатором в качестве имени: Теперь обратимся к таблице так, словно ее имя является обычным идентификатором: Сработает? Согласно стандарту SQL, не должно, но может сработать в продукте Microsoft. Причины обсуждаются в разделе «Разработайте строгие правила использования прописных букв». Идентификаторы в кавычках не особенно хорошо стыкуются с хост-языками, особенно когда в идентификаторе имеются пробелы или спецсимволы. Вот, например, вполне корректное выражение для вставки данных: Объект ADO сгенерирует следующий код: что является синтаксической ошибкой. Исключения Иногда нужно поделиться результатом с кем-то, кто не может прочитать или понять имена столбцов с использованием символов из набора Latin-1. В этом случае для форматирования выводимых данных можно применить псевдонимы в кавычках. Мне приходилось делать так для поляков и китайцев. Я также применял имена в кавычках в документации, чтобы они безошибочно воспринимались как имена объектов схемы, а не как обычные слова в предложениях. Обычная причина этой ошибки в том, что программист путает имя элемента данных с отображаемым заголовком. В традиционных процедурных языках файл с данными и программа находятся на одном уровне. В SQL база данных полностью отделена от интерфейса, в котором эти данные отображаются. Разработайте строгие правила использования прописных букв Обоснование Правила работы с регистрами различны в разных продуктах. В стандартном SQL, а также продуктах IBM и Oracle обычные идентификаторы переводятся в верхний регистр, а регистр идентификаторов в кавычках остается неизменным. В продуктах Microsoft правила использования регистров определяются не типом идентификатора, а заданным умолчанием. По умолчанию регистры не различаются, то есть «t» равно «T». С распознаванием регистров связаны две проблемы. Во-первых, согласно стандарту SQL, идентификатор в кавычках "t" и обычный идентификатор t различаются. Во-вторых, Microsoft не следует стандарту SQL. Поэтому трудно придумать правило построения имен, которое подошло бы всем. Исключения Я предложу вам простой набор правил, основанный на принципах читаемости и эстетичности, вовсе не претендуя на его единственность.
Создавайте имена согласно стандарту ISO-11179 Это относительно новый стандарт ISO для метаданных, и понятен он пока далеко не всем. К счастью, те его правила, которые нужны программисту SQL, просты и очевидны. Настоящая проблема в том, что многие люди нарушают эти правила. В сокращенном виде правила для элементов данных, разработанные комитетом стандартов метаданных NCITS L8, опубликованы на следующих сайтах:
PDF-файл:
Черновик:
Стандарт ISO-11179 разбит на шесть разделов: ISO-11179 для SQL Обоснование Формальные стандарты хороши, но слишком общи. Удобно превратить их в набор правил, написанных на языке, понятном разработчику SQL. Некоторые из данных здесь формулировок являются результатом консенсуса экспертов и взяты из групп новостей и частной переписки. Согласно правилам стандарта ISO-11179-4 скалярный элемент данных должен удовлетворять следующим требованиям.
В теории все это звучит прекрасно, но в реальном мире на имена накладываются дополнительные практические ограничения, например ограничение длины или допустимые символы. Другая проблема состоит в том, что у элемента данных в зависимости от контекста его использования могут быть разные имена. В отчете он назван так, в файле электронного обмена данными (electronic data interchange, EDI) по-другому, причем оба имени могут отличаться от имени в БД. Но в пределах одной БД использовать разные имена для одного элемента не стоит, да и в разных БД одного предприятия этим не стоит злоупотреблять. К сожалению, найти подобные разногласия без хорошего словаря очень трудно. Словарь данных должен включать внешние имена и их контекст. Исключения Над всеми нами довлеет проклятие старых БД, старых файловых систем и прочих традиций. Если у элемента имеется устоявшееся и понятное имя, его можно использовать даже вопреки стандарту. Например, для столбца с почтовым индексом формально правильным будет имя «us_postal_code», но вместо него можно поставить более привычное «zip_code» или даже просто «zip». Уровни абстрагирования Разработка имени начинается на концептуальном уровне. Класс объекта представляет идею, абстракцию или предмет реального мира, например дерево или страну. Свойство, например, высота или идентификатор, описывает все объекты класса. Это позволяет создавать словосочетания типа «высота дерева» или «идентификатор страны», комбинируя класс и свойство. Этот уровень — логический. Полное логическое имя элемента данных должно включать способ представления значений из его области определения (набора допустимых значений). Так мы получаем в качестве возможных элементов данных «меру высоты дерева», «имя идентификатора страны» и «код идентификатора страны». Между именем идентификатора и кодом идентификатора имеется различие, правда, столь тонкое, что мы можем не захотеть его моделировать. В этом случае необходимо правило, в соответствии с которым название свойства исключается из имени элемента данных. При этом в структуре элемента свойство сохранится, лишь перестав быть частью его имени. Некоторые логические элементы данных могут считаться общепринятыми, если они четко определены и применяются многими организациями. Например, названия и коды стран описаны в стандарте ISO 3166 «Codes for the Representation of Names of Countries», который можно использовать в качестве справочника. Заметьте, что, по правилам стандарта ISO-11179, это самый высокий уровень, на котором появляются истинные элементы данных: у них есть класс, свойство и способ представления. Далее идет прикладной уровень. Он обычно реализуется при помощи неких конкретных уточнений, соответствующих поставленной задаче: выделения подмножества из области значений данных, добавления ограничений, гарантирующих, что мы будем иметь дело лишь с допустимыми значениями. Например, мы используем коды стран ISO-3166, но реально работаем только с европейскими государствами. Это означает, что нас интересует подмножество стандарта, которое временным изменениям практически не подвержено. С другой стороны, набор стран, в которых в текущем году выпало больше всего осадков, может на протяжении года меняться неоднократно. Эти уточнения включаются в имя посредством добавления к логическому имени конкретного квалификатора. Например, если нужно составить список стран, с которыми у некой организации есть торговые соглашения, элемент данных запроса можно назвать «trading_partner_country_name» (название страны-торгового партнера), подчеркнув тем самым его роль. Область значений будет представлять собой подмножество стран из стандарта ISO-3166. Ниже всего располагается физический уровень. На нем находятся имена, которые фигурируют в заголовках столбцов таблицы, описаниях файлов, разметке EDI-файлов и т. д. Эти имена могут быть, с одной стороны, сокращенными из-за различных ограничений на длину или набор символов, с другой стороны, могут содержать информацию о формате и источнике. В реестре все имена элементов данных и компоненты имен всегда будут указываться в паре со своим контекстом, чтобы мы легко могли установить их источник и назначение. Цель заключается в возможности проследить за каждым элементом данных от его создания до любого применения, под каким бы именем он ни фигурировал. Избегайте описательных префиксов Обоснование Среди новичков бытует странный обычай описывать какие-то черты элемента данных в текущей таблице с помощью приставок. Он, вероятно, также берет свое начало в доисторических временах последовательных файловых систем, когда на физическое расположение файла действительно приходилось обращать внимание. Особенно глупо выглядит приставка «tbl-». Прежде чем возражать, что эта приставка отражает природу того, к чему относится идентификатор, вспомните, что в SQL имеется только одна структура данных. Что еще это может быть? Вы же не ставите приставку «сущ-» перед каждым написанным вами существительным! Вряд ли она облегчит чтение. Это похоже на то, как маленькие дети называют что ни попадя «штучкой». Быть чем-то значит быть чем-то конкретным. Не быть чем-то конкретным или быть чем-то вообще значит быть ничем (Аристотель). Следующая по глупости приставка — имя таблицы. Неужели один и тот же элемент данных полностью меняет свою природу от таблицы к таблице? Скажем, в столбцах «orders_upc» и «inventory_upc» явно содержатся коды UPC, но, присвоив им разные имена, вы тем самым подразумеваете, что в вашей модели данных коды UPC для заказов и для описи представляют собой «две большие разницы». Полный кошмар начинается, когда в ссылках на внешний ключ имя переменной составляется из имени базовой таблицы в качестве приставки и названия столбца «id». Запросы полны операторов типа «Orders.ID = OrderID», и работа с ними быстро превращается в игру «Разгляди точку», сопряженную с мучительным разгадыванием смысла тысяч различных столбцов «ID» в словаре данных. Префиксы наподобие «vw» для представлений говорят о том, как в схеме реализована виртуальная таблица, но к модели данных это не имеет никакого отношения. Если позже я решу заменить представление обычной таблицей, мне придется менять имя. А что, если в схеме уже есть таблица с той же основой имени? В равной степени странны и опасны имена столбцов, начинающиеся с обозначения типа данных. Тип описывает физическое представление данных, а не их смысл в используемой модели. Словарь данных можно выбрасывать, если вы всякий раз должны гадать, как называется столбец с номером заказа — «intorder_nbr», «strorder_nbr» или даже «forder_nbr», хотя он мог бы называться просто «order_nbr». Если пользователь не помнит тип данных столбца, он всегда может заглянуть в его DDL-определение. Наконец, последняя проблема с приставками — добавление символов «PK_» к первичному ключу или «FK_» к внешнему ключу. Использование столбца в качестве ключа — это всего лишь один из способов его применения, не имеющий отношения к фундаментальной природе данных. Ключи всегда можно отождествить с помощью слов «PRIMARY KEY» или «FOREIGN KEY… REFERENCES…» в описании столбцов. Самый странный вариант этого правила попался мне на Web-узле компании, специализирующейся на программировании для Oracle. Согласно ему, ограничения CHECK() должны были называться так: «<имя таблицы>_CK_<имя столбца>». Такое имя, во-первых, не несет никакой информации о природе ошибки, во-вторых, ограничивает возможное количество ограничений: по одному на столбец в данной таблице. К тому же, непонятно, как быть с ограничениями, в которых проверяются значения двух и более столбцов. Те же правила и рекомендации применимы к именам любых объектов схемы. Вам встретятся приставка «usp_» для пользовательских хранимых процедур, «trig_» для триггеров и т. п. В MS SQL Server это может привести к серьезным проблемам, поскольку префикс «sp_» используется для системных процедур и имеет в архитектуре особое значение. Если объект схемы выполняет какое-то действие (триггер, процедура), используйте формат имени <глагол_объект>. Подробнее об этом — в главе 8. Исключения Другие мнения вы найдете по адресу: http://www.craigsmullins.com/dbt_0999.htm . Посмотрите также серию статей:
Разработайте стандартную систему суффиксов Приведенный ниже примерный список суффиксов основан на внутренних стандартах компании Teradata.
Различие между типом, классом и категорией кроется в строгости соответствующих критериев. Категория четко определена: вам чаще всего не нужно напряженно размышлять, чтобы отнести данную сущность к животным, овощам или минералам. Класс объединяет сущности, связанные общим признаком: животное может быть классифицировано как млекопитающее или как рептилия. В некоторых случаях правила разделения на классы оказываются неочевидными, как, например, в случае с утконосом — яйцекладущим млекопитающим, обитающим в Австралии. Часто такие исключения ведут к появлению новых классов, в случае с утконосом — к появлению отряда однопроходных. Тип — наименее конкретный и субъективный способ разделения сущностей. Например, в одних штатах мотоцикл на трех колесах юридически считается мотоциклом, в других штатах — автомобилем, в третьих он считается автомобилем только при наличии заднего хода. На практике категорию, класс и тип часто смешивают. Если приведенные выше правила противоречат промышленному стандарту, отдавайте предпочтение последнему.
Иногда могут также понадобиться суффиксы для обозначения единицы измерения. Всегда проверяйте, нет ли для элемента данных готового стандарта ISO. Имена таблиц и представлений должны подчиняться стандартам и выражаться существительными множественного числа Обоснование Во всех возможных случаях предпочтение следует отдавать промышленным стандартам. Основанные на них имена будут понятны людям, а определения стандартов — поддерживаться квалифицированными специалистами. Например, в США старая Стандартная промышленная классификация SIC (Standard Industrial Classification) была заменена Североамериканской системой промышленной классификации NAICS (North American Industry Classification System). Этот новый код был разработан совместно США, Канадой и Мексикой, чтобы обеспечить сопоставимость статистической информации по всей Северной Америке. Сокращения NAICS и «naics_code» вполне понятны специалистам по экономической статистике, хотя для большинства из нас они, вероятно, выглядят необычно. Если к вашей ситуации промышленный стандарт в чистом виде не применим, постарайтесь придумать его модификацию. Скажем, если я имею дело только с мексиканскими автомобилями, я могу отразить это ограничение в имени таблицы «VIN_Mexico». Если подходящего стандартного имени нет, подбирайте обобщающее имя или существительное во множественном числе. Обобщающие имена таблиц предпочтительнее простых существительных единственного числа, поскольку таблица — это не одно значение, а их набор. Когда я говорю «сотрудник», в голове у меня рисуется образ одиноко стоящего сотрудника. Я говорю «сотрудники», и образов становится много. Но стоит произнести «персонал», и мысленный образ внезапно становится более абстрактным — общее понятие лишено конкретных лиц. В SQL допускается использовать одно и то же имя и для таблицы, и для столбца в ней, но делать этого не следует. Во-первых, такое наименование столбца противоречит правилам, которые мы только что обсудили, поскольку в нем отсутствует квалификатор. Во-вторых, оно означает, что либо таблица не названа как набор, либо столбец не назван как скаляр. Исключения Называйте таблицу существительным в единственном числе, если в ней будет всего одна строка. Вот единственное, что мне приходит в голову:
Оператор INSERT создает единственную строку, поэтому единственное число в имени таблицы вполне уместно. Столбец «lock» гарантирует, что строка будет только одна. Другой способ выполнить то же самое — создать представление VIEW:
Достоинство этого способа в том, что представление нельзя изменить. Недостаток — в том же. Имена корреляций подчинены тем же правилам, что и другие имена. Почти всегда Обоснование Имена корреляций — это те же имена. Они основаны на имени базовой таблицы, представления, столбца или на выражении, с помощью которого созданы. Удобно, что в этом случае у читателя всегда перед глазами контекст, поэтому имя корреляции может быть более кратким. Имя корреляции гораздо чаще называют псевдонимом (alias), но мне пока хотелось бы сохранить формальный подход. В SQL-92 псевдонимы создаются необязательным оператором AS, но его обязательно нужно вставлять, чтобы присвоение альтернативного имени было очевидным. Ни в коем случае не прибегайте к порочной практике присвоения бессмысленных корреляционных имен, основанных на алфавитной последовательности. Такое, к сожалению, случается очень часто и существенно затрудняет обслуживание кода. Представьте себе программу, в которой для таблицы «Personnel» в одном выражении создан псевдоним A, в другом — D, в третьем — Q: исключительно на основании положения таблицы в конструкции FROM. Корреляционные имена столбцов для вычисляемых элементов данных должны следовать тем же правилам, что и имена обычных столбцов. Скажем, читателю не составит труда разобраться в выражении «salary + COALESCE(commission, 0.00)) AS total_pay». Корреляционное имя таблицы или представления должно основываться на имени базовой таблицы и отражать роль, которую копия таблицы играет в выражении (например, «SELECT … FROM Personnel AS Management, Personnel AS Workers», если таблица в запросе используется дважды). Теперь поясню, почему я написал в заголовке слова «почти всегда». В случае, если вы создаете несколько имен корреляции для одной и той же таблицы, удобно добавлять к ним номер в виде суффикса (например, «SELECT … FROM Personnel AS P1, Personnel AS P2»). По номеру читатель узнает, сколько псевдонимов для данной таблицы создается в выражении. По сути, имена корреляции представляют собой местоимения и играют ту же роль, что и местоимения в обычной речи: делают предложения более короткими и удобными для чтения. Псевдоним табличного выражения должен быть простым, коротким и основанным на логическом смысле табличного выражения:
Хотя это и не обязательно, за корреляционным именем табличного выражения может стоять список новых имен столбцов в скобках. Если этого списка нет, имя корреляции наследует имена из базовых таблиц или представлений в табличном выражении. В случае простого табличного корреляционного имени такой список, вероятно, излишен, поскольку обычно нас вполне устраивают исходные имена столбцов. В случае корреляционного имени табличного выражения подобный список лучше вставить, так как он позволит избежать неоднозначных имен столбцов. Он также вынуждает программиста удалить из выражения лишние столбцы, которые не нужны в запросе. Исключения Однобуквенные корреляционные имена таблиц можно использовать, если очевидное, ясное и простое имя действительно не удается подобрать. Это относится и к именам вычисляемых элементов. Имена таблиц-отношений должны быть общепринятыми, понятными терминами Обоснование Таблицы и представления часто применяются для моделирования отношений «один ко многим» или «многие ко многим». Если у отношения есть общеупотребительное имя, понятное в данном контексте, используйте его. Для новичков типично создавать имена для таблиц-отношений, комбинируя имена исходных таблиц. Например, таблицу, для которой уместно было бы имя «Семьи», они называют «МужчинаЖенщина», «МужьяЖены» или еще более странно. Аналогично, имя таблицы «Распределение» выглядит более осмысленным, чем «Студенты_Курсы». Стоит только задуматься над этим вопросом, и выбор имени не составит труда. Конечно же, конкатенация имен оказывается бессильной, когда в отношении участвует более трех сторон, как, например, в покупке недвижимости участвуют продавец, покупатель и банк. Исключения Если у отношения нет общеупотребительного названия, что же делать, используйте конкатенацию. В имена объектов доступа к метаданным схемы можно включать структурную информацию Это правило неприменимо к информационным таблицам схемы, имена которых стандартизованы. Речь идет лишь об индексах и прочих элементах, непосредственно связанных с хранением и доступом к данным. Вполне приемлем суффикс «_idx». Обоснование Здесь мы следуем все тому же принципу: имя должно объяснять, что им обозначено. В случае индексов и других элементов, непосредственно связанных с хранением и доступом к данным, важно подчеркнуть, что они не имеют отношения к модели данных. Исключения Это правило неприменимо к объектам схемы, которые видны пользователю. Ошибки в именовании элементов данных Мы достаточно поговорили о том, как нужно называть элементы данных. Теперь давайте посмотрим, как предложенные правила чаще всего нарушаются. Избегайте невнятных имен Обоснование В этом есть какая-то скрытая непристойность, а я не выношу скрытости! Гручо Маркс Крайний вид невнятности — настолько общее имя, что оно не говорит вообще ничего, например «Дата», «Количество»… Представьте себе столбец «Дата». Сразу возникает вопрос: дата чего? Приема на работу? Рождения? Встречи? Увольнения? Смерти? Другая крайность — строка квалификаторов, противоречащих друг другу. Вот типичный для новичка пример: «type_code_id». Если это идентификатор (id), то он должен быть уникальным для каждой обозначаемой им сущности, как идентификационный номер автомобиля (vehicle identification number, VIN). Если это код (code), то он берется из надежного источника и не должен быть уникальным. Если это тип (type), какой систематике он принадлежит? Чего уж мелочиться — можно и еще один квалификатор добавить: «type_code_id_value»! А ведь гораздо понятнее было бы написать просто «customer_type»… Исключения Нет. Некорректные имена элементов данных имеют своим источником невежество и объектно-ориентированное программирование (ООП). В частности, объектно-ориентированные программисты обязательно добавляют суффикс «_id» к любому первичному ключу любой таблицы, не понимая, что SQL — сильно типизированный язык, и в нем сущности в ходе выполнения программы своего типа не меняют. Иногда имена бывают просто абсурдными. Взгляните на таблицу цветов:
Что означает суффикс «_value_id»? Сразу ясно, что создатель не сильно задумывался над именем. Теперь представьте, что мы решили использовать в БД цветовую систему Pantone: у нас есть надежный источник и точное описание, потому что мы все продумали! Выражение будет выглядеть так:
Избегайте имен, которые меняются от места к месту Обоснование Хуже всего, когда имя атрибута меняется от таблицы к таблице. Рассмотрим в качестве примера слегка подчищенный фрагмент кода из группы новостей, посвященной SQL: Полные имена таблиц трудно читать, но новичок, написавший код, считал, что имя таблицы обязательно должно быть частью имени столбца. Ведь в старых программах на Коболе все было именно так! Это означает, что если у вас есть сотня таблиц, в каждой из них один и тот же атрибут будет иметь новое имя, поэтому о нормальном словаре данных вам остается только мечтать. Кстати, обратили внимание, как рябит в глазах от множества точек? Теперь взгляните на исправленную версию, которая четко центрирована на таблице IPC (схема-«звезда»). Я понятия не имею, что такое URN, но в данном случае понятно, что речь идет о каком-то стандартном для этой задачи идентификаторе. А теперь взгляните на разнообразные URN в оригинальном запросе — URN, IPCURN, OffenseURN… Чувствуешь себя, как в сувенирной лавке при крематории. Вы меняете свое имя, переходя из комнаты в комнату? Конечно, нет! Вот так и корректное имя элемента данных зависит от его смысла, а не расположения. Исключения В запросе элементу данных можно дать временное новое имя (псевдоним), которое удаляется после выполнения выражения. Подробнее об этом — в разделе «Имена корреляций подчинены тем же правилам, что и другие имена. Почти всегда». Не используйте нестандартные физические указатели Обоснование Главный принцип современного моделирования данных — разделение логической модели и физической реализации. Это позволяет использовать одну и ту же модель на различных платформах. В старые добрые времена логическая и физическая реализации были неразделимы. Подробно я буду говорить об этом в главе 3, пока же просто правило — не применяйте нестандартные физические указатели. Они противоречат самой идее ключа в реляционной модели. Стремление новообращенных программистов SQL использовать IDENTITY, GUID, ROWID или другое нестандартное средство автонумерации в качестве ключа проистекает из привычки работать с магнитными лентами. Им хочется знать, в каком порядке строки добавлялись к БД, точно так же, как раньше им нужно было знать порядок добавления записей в конец магнитной ленты! Исключения Ну разве что вам действительно зачем-то нужно имитировать файл последовательного доступа с помощью таблицы SQL, не беспокоясь о целостности данных. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Так же в этом разделе:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
