Главная » Microsoft SQL Server, Базы данных » Создание таблиц

0

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

в Management Studio

Если вам нравится работать в графической среде, то воспользуйтесь утилитой Management Studio, которая предлагает две рабочие области для создания и модификации таблиц.

?               Конструктор таблиц (Table Designer) (рис. 17.4) перечисляет столбцы по вертикали, размещая свойства столбцов в нижней части окна.

?               Конструктор баз данных (Database Designer) (рис. 17.5) — более гибкий инструмент, чем конструктор таблиц. В нем могут отображаться ограничения внешних ключей как связи с другими таблицами.

Дополнительная О работе с этими инструментами см. в главе 6.

«информация -

Puc. 17.4. ы Contact учебной базы данных OBXKites с помощью конструктора таблиц утилиты Management Studio

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

Puc. 17.5. ы Customer в учебной базе данных СНА2 с помощью конструктора баз данных утилиты Management Studio

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

Каждый из типов данных мы рассмотрим отдельно далее в этой главе. Для одних типов нужно явно указывать длину, другие имеют фиксированную длину. Вопросы пустых (неопределенных) значений мы рассмотрим позже, в разделе “Создание пользовательских столбцов”.

Как только редактирование структуры таблицы будет выполнено, активизируется кнопка Save Change Script панели инструментов. Она приводит к отображению кода, который конструктор таблиц должен выполнить для фактического сохранения изменений. К тому же кнопка Save Change Script позволяет сохранить сценарий в файле . sql, чтобы его можно было повторить на другом сервере.

Дополнительная Подробно об использовании конструкторов таблиц и баз данных см. в главе 6.

информаций

Работа со сценариями SQL

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

?               Код сценария находится в одном месте. Работа со сценариями SQL аналогична работе с языками VB.NET и С#.

?               Сценарии могут храниться в узлах решений и проектов в Solution Explorer, а также в Microsoft SourceSafe или в другой системе управления изменениями.

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

?               Установка, которая освежает новую базу данных, в противоположность резервной копии имеет то преимущество, что не содержит каких-либо устаревших данных.

В то же время работа со сценариями имеет и свои недостатки.

?               Инструкции Т-SQL могут оказаться незнакомыми, а размер сценария может быть запредельно большим.

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

?               Диаграммы базы данных Management Studio не являются частью сценария.

Для работы с объектами (в том числе и с таблицами) предназначены следующие инструкции T-SQL: CREATE. ALTER и DROP. Следующая инструкция из учебной базы данных Outer Banks Kite Store создает таблицу ProductCategory. В ней представлено имя таблицы (вместе с именем ее владельца— dbo), за которым следуют ее столбцы. Заключительная строка указывает серверу создать таблицу в первичной файловой группе:

CREATE TABLE dbo.ProductCategory (

ProductCategorylD UNIQUEIDENTIFIER NOT NULL

ROWGUIDCOL DEFAULT (NEWID()) PRIMARY KEY NONCLUSTERED,

ProductCategoryName NVARCHAR(50) NOT NULL,

ProductCategoryDescription NVARCHAR(100) NULL

)

ON [Primary];

Для получения списка таблиц текущей базы данных выполните запрос к представлению каталога sysobjecu, задав условие фильтра type_desc=’USER_table ’.

С расширенными примерами создания баз данных и таблиц с помощью сценариев можно ознакомиться на сайте книги по адресу www. SQLServerBible. com.

Схемы

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

Обычно (и по умолчанию) объекты принадлежат схеме dbo. Имя схемы является третьей частью четырехкомпонентного имени:

Сервер.база_данных.схема.объект

В предыдущих версиях SQL Server объекты принадлежали пользователям. Также объекты могли принадлежать объектам схемы, что в принципе то же самое, что принадлежность пользователям, однако называется по-другому. В SQL Server 2005 концепции пользователей и схемы были разделены. Теперь пользователи больше не могут владеть объектами.

Если вы используете пользовательские схемы, отличные от dbo, то в каждом запросе должны указывать их в явном виде. Хотя следует заметить, что двухкомпонентное имя повышает производительность, к тому же вряд ли кому приносит особое удовольствие постоянный ввод имени схемы.

Для получения списков схем текущей базы данных выполните запрос к представлению каталога sysschemas.

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

SQL Server допускает использование в именах таблиц и столбцов до 128 символов Unicode, включая пробелы, а также символы верхнего и нижнего регистров. Естественно, все прелести такой свободы перекрываются впоследствии необходимостью ввода бесконечных имен столбцов и заключения их в квадратные скобки при наличии пробелов. Еще более опасно обсуждать соглашения об именах с программистами — это все равно что болеть за свою команду в секторе фанатов другой команды. В то же время разрешите и здесь, как говорится, вставить свои пять копеек.

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

Лагерь сторонников многословных имен верит, что таблица содержит набор строк и потому должна именоваться описательным именем во множественном числе. Обоснование этой позиции звучит следующим образом: “Таблица заказчиков представляет собой их множество. Множества состоят из массы элементов, поэтому и имя таблицы должно отражать этот факт. Если бы таблица содержала данные всего об одном заказчике, то в ней бы просто не было смысла”.

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

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

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

Лично мне кажется, что программисты используют соглашения об именах, чтобы оградить себя от хаотичных конструкций, с которыми приходилось работать в прошлом. Достаточно проработав с “плоскими” файлами и их именами во множественном числе, я склоняюсь к использованию единственного числа.

Если база данных достаточно велика и таблицы в ней логически сгруппированы, я добавляю к их именам двух- или трехбуквенную аббревиатуру, облегчающую работу с ней. Мне приходилось встречать и системы нумерации модулей и таблиц, и я не рекомендую их использовать. К примеру, для таблицы складских запасов отлично подходит имя Invltem; в то же время имя 0207_Item похоже на шифровку.

Еще один вопрос связан с использованием символов подчеркивания при формировании имен. Например, некоторые магазины компьютерной техники для таблицы строк заказов используют имя ORDER_DETAIL. Я избегаю использования символов подчеркивания, используя их только для связывающих таблиц, разрешающих отношения “многие ко многим”. Исследования показали, что комбинированные слова типа OrderDetail легче читать, чем комбинированные слова, набранные исключительно в верхнем или нижнем регистре.

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

?               В именах таблиц используется единственное число без чисел, но с префиксом.

?               В связывающих таблицах, разрешающих отношения “многие ко многим”, используются имена типа та блица_шгс[_ та блица.

?               В именах для разделения слов используется смешанный регистр символов без подчеркиваний и пробелов (например, MixedCase).

?               Для первичных ключей используется имя таблицы, дополненное символами ID. Например, для первичного ключа таблицы Customer уместно использовать имя CustomerlD.

Внешние ключи имеют те же имена, что и первичные, с которыми они связаны, за исключением рекурсивных отношений. Например, в учебной базе данных Family внешний ключ MotherlD ссылается на первичный ключ PersonID, а в базе данных списка материалов на один первичный ключ рекурсивно ссылается несколько внешних (BillofMaterials.MateriallD и BillofMaterials.SourceMateriallD ссылаются на первичный ключ Material .MateriallD).

?               Избегайте неуместных аббревиатур.

?               Будьте последовательны при именовании объектов всех баз данных. Например, для полей имени и фамилии всегда используйте названия FirstName и LastName.

Файловые группы

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

В организационных целях база данных OBXKites использует две файловые группы. Все данные, которые изменяются на регулярной основе, вынесены в файловую группу primary. Эта файловая группа часто резервируется. Данные, которые изменяются достаточно редко (например, классификатор приоритетов заказов), вынесены в файловую группу static:

CREATE TABLE OrderPriority (

OrderPrioritylD UNIQUEIDENTIFIER NOT NULL

ROWGUIDCOL DEFAULT (NEWIDO) PRIMARY KEY NONCLUSTERED,

OrderPriorityName NVARCHAR (15) NOT NULL,

OrderPriorityCode NVARCHAR (15) NOT NULL,

Priority INT NOT NULL

)

ON [Static];

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии