Имена таблиц и столбцов

Вообще говоря, для именования таблиц и столбцов применяются такие же правила, какие относятся ко всем другим объектам базы данных. В документации СУБД SQL Server они именуются правилами выбора идентификаторов, о которых шла речь в конце главы I. Эти правила именования объектов довольно просты, но в данном разделе основное внимание уделено не описанию принципов, используемых в СУБД SQL Server для определения того, кахсие имена являются допустимыми и недопустимыми, а вопросам такого выбора имен таблиц и столбцов, чтобы они были удобными и имели смысл.

На практике разработано бесчисленное количество различных стандартов , касающихся того, как следует именовать объекты базы данных, особенно таблицы и столбцы. Ниже приведены довольно простые правила, рекомендуемые автором.

В каждом слове, которое входит в состав имени, перевести в верхний регистр первую букву и использовать нижний регистр для написания остальных букв.

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

Ограничить использование аббревиатур. Единственный приемлемый способ использования аббревиатур состоит в том, чтобы выбранные аббревиатуры мог распознать любой пользователь. В качестве примеров аббревиатур, используемых автором, достаточно привести ID (сокращение от identification - идентификация или идентификатор), No (сокращение от number- количество) и Org (сокращение от organization- организация). Иногда в связи с необходимостью лимитирования длины имен приходится широко пользоваться аббревиатурами, но следует всегда учитывать, что первым и наиболее важным требованием к любым именам всегда остается то, что онрх должны быть понятными и запоминающимися.

При создании таблиц, предназначенных для обеспечения связи между др)ти-ми таблицами (и обычно называемых соединительными, или ассоциативными, таблицами), необходимо включить в имя новой таблицы имена всех родительских таблиц. Например, предположим, что имеется база кинематографических данных, в которой хранятся данные о звездах кинематографа и фильмах, в которых они снимались. Между фамилиями звезд и названиями фильмов имеется связь многие ко многим . Поэтому для оформления связи между таблицами Movies и Stars применяется отдельная таблица, которая должна иметь имя MovieStars.

Если имя объекта базы данных должно состоять из двух и более слов, не следует вводить между словами какие-либо разделители (все слова должны записываться слитно). Для распознавания границ между словами достаточно воспользоваться тем фактом, что первая буква каждого слова является прописной, а остальные буквы - строчными.

Если бы автор глубже коснулся этой темы, то ему припигось бы спорить с другими специалистами в области баз данных по поводу проблем именования и он не смог бы вообще закончить эту книгу. Например, очень многие специалисты считают, что следует разделять слова, из которых состоит имя объекта, символами подчеркивания ( ). Но я не являюсь сторонником этого подхода. Главным образом все это связано с тем, что имена с символами подчеркивания являются менее удобными в использовании. В связи с применением символов подчеркивания возникает несколько проблем, описанных нр1же.

Прежде всего, чтобы ввести символ подчеркивания, необходимо снять пальцы с правильной позиции на клавиатуре. Многие люди испытывают при этом затруднения, в связи с чем появляются многочисленные опечатки.

Далее, в документации нередко приходится проводить линию под именем таблицы или столбца (применять стиль подчеркивания). Тем не менее некоторые шрифты не позволяют обнаружить символы подчеркивания на фоне линии, которой подчеркнут текст, поскольку эти символы сливаются с линией подчеркивания; это приводит к путанице и дополнительным ошибкам.

Наконец, из-за применения символов подчеркивания объем вводимого кода увеличивается (автор согласен с тем, что это замечание-удар ниже пояса).

В версии SQL Server 7.0 появилась также возможность разделять слова в имени с использованием обычного пробела. Но этого не следует делать! Применение пробелов в именах объектов базы данных представляет собой чрезвычайно плохую практику программирования и приводит к появлению невероятного количества ошибок. В действительности использование пробелов в именах было разрешено в целях стимулирования дальнейшего распространения СУБД Access, но автор еще раз предостерегает тех пользователей, которые решили клюнуть на эту приманку, - можно не сомневаться, что возможность применения пробелов была предоставлена с самыми лучшими намерениями, но практика показывает, что появление подобных имен стало причиной многочисленных нарушений в работе баз данных.

Безусловно, приведенный выше перечень рекомендаций не является исчерпывающим; его можно, скорее, назвать популярной версией правил, фактически используемых автором при именовании таблиц. Просто я обнаружил, что применение указанных правил избавляет меня от многих проблем. Надеюсь, что такую же пользу из них извлечет и читатель.

Наиболее важным требованием к выбору имен является соблюдение единообразия. Занимаясь со своими студентами, автор каждый раз предупреждает их заранее, что слово единообразие будет повторяться на лекциях снова и снова, но когда речь идет об именовании объектов, то буквально нельзя найти более важного понятия. Приняв на вооружение какое-то правР1ло, которому вы собираетесь следовать, усвойте еще одно правило, которое гласит: каковы бы ни были выбранные вами стандарты, относитесь к ним действительно как к стандартам. Например, если вы решили по какой-то причине применять определенную аббревиатуру, то неизменно используйте ее вместо развернутого термина (причем в одном и том же виде), а также проследите за тем, чтобы все сотрудники вашей организации действовали так же (подготовьте инструкцию по использованию имен объектов и следите за тем, чтобы она соблюдалась). Независимо от того, какие правила именования вы выбрали, соблюдайте единообразие, применяя эти правила ко всем объектам базы данных. Это позволит исключить невероятное количество ошибок, а также ускорить изучение пользователями предоставленной им для работы базы данных.

Типы данных

В настоящей главе этой теме не будет уделено много внимания, поскольку типы данных были подробно описаны в главе 1. Следует лишь отметить, что за именем каждого столбца должно быть сразу же приведено обозначение типа данных, поскольку не предусмотрены типы данных, применяемые по умолчанию.

Ключевое слово default

Применение ключевого слова DEFAULT будет рассматриваться более подробно в главе 5, а на данный момент достаточно отметить, что это ключевое слово определяет значение, которое должно использоваться при вставке любой строки в качестве значения определенного поля, если для этого поля не предусмотрено значение, заданное пользователем. Если в определении таблицы предусмотрено применение значений, заданных по умолчанию, то оно должно следовать сразу же за обозначением типа данных.

Ключевое слово identity

Идентификационное значение - очень важное понятие в проектировании базы данных. А в данном разделе мы рассмотрим определение понятия столбца идентификации. Если в объявлении столбца указано, что этот столбец является столбцом идентификации, то СУБД SQL Server автоматически присваивает последовательное числовое значение полю, относящемуся к этому столбцу, при вставке каждой строки. Число, с которого в СУБД SQL Server начинается отсчет значений в столбце идентификации, называется начальным значением, а величина, на которую это значение увеличивается или уменьшается после вставки каждой строки, называется шагом. По умолчанию и начальное значение, и шаг равны 1; практика показывает, что в большинстве проектов применяются именно эти значения. Тем не менее, например, можно установить начальное значение, равное 3, и применить шаг, равный 5. В таком случае отсчет начинается с 3, а после ввода каждой строки с этой величиной складывается значение 5, что приводит к получению идентификационных значений 8, 13, 18, 23 и т.д.

Столбец идентификации должен быть числовым, причем на практике такой столбец почти всегда объявляется с типом данных integer или bigint. Рекомендуется использовать int (или даже числовой тип данных с меньшим форматом представления), если он полностью обеспечивает потребности в создании уникальных идентификационных значений. Следует учитывать, что применение типов данных с более крупным форматом представления приводит к возрастанию объемов ввода и вывода.

Применение столбцов идентификации является довольно несложным - достаточно задать ключевое слово IDENTITY сразу после указания типа данных для столбца. Но возможность использования автоматически наращиваемого идентификационного значения не совместима с применением значения, предусмотренного по умолчанию. Стоит немного подумать, и становится очевидно, что такое условие действительно имеет смысл, ведь заданное по умолчанию значение является постоянным, а идентификационное значение после вставки каждой строки увеличивается или уменьшается.

Следует учитывать, что столбец идентификации функционирует последовательно. Это означает, что сразу после того, как будут определены параметры seed (начальное значение) и increment (шаг), неизменно происходит увеличение очередных формируемых значений (или их уменьшение, если в качестве шага задано отрицательное число). При этом не предусмотрено какого-либо автоматизированного механизма, позволяюще-