Створення таблиць

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

в Management Studio

Якщо вам подобається працювати в графічному середовищі, то скористайтеся утилітою Management Studio, яка пропонує дві робочі області для створення і модифікації таблиць

■ Конструктор таблиць (Table Designer) (рис 174) перераховує стовпці по вертикалі, розміщуючи властивості стовпців в нижній частині вікна

■ Конструктор баз даних (Database Designer) (рис 175) – більш гнучкий інструмент, ніж конструктор таблиць У ньому можуть відображатися обмеження зовнішніх ключів як звязки з іншими таблицями

Додаткова Про роботу з цими інструментами см в главі 6

«Інформація –

Puc 174 Створення таблиці Contact навчальної бази даних OBXKites за допомогою конструктора таблиць утиліти Management Studio

У кожному з цих інструментів графічно представлена ​​структура таблиці Як тільки проектування таблиці буде завершено, Management Studio генерує сценарій, який застосовує зміни до бази даних Якщо ви вносите існуючу таблицю, то часто дані спочатку зберігаються в тимчасовій таблиці, потім видаляються деякі елементи, після чого створюється нова таблиця, в яку вставляються дані

Puc 175 Створення таблиці Customer в навчальній базі даних СНА2 за допомогою конструктора баз даних утиліти Management Studio

Конструктор таблиць відображає тільки імена стовпців і їх тип даних (разом з довжиною), а також допустимість порожніх значень Незважаючи на те що саме це і є основною властивістю стовпців, мене дратує процес вибору кожного шпальти тільки для того, щоб переглянути або змінити його інші властивості

Кожен з типів даних ми розглянемо окремо далі в цьому розділі Для одних типів потрібно явно вказувати довжину, інші мають фіксовану довжину Питання порожніх (невизначених) значень ми розглянемо пізніше, в розділі Створення користувальницьких стовпців.

Як тільки редагування структури таблиці буде виконано, активізується кнопка Save Change Script панелі інструментів Вона призводить до відображення коду, який конструктор таблиць повинен виконати для фактичного збереження змін До того ж кнопка Save Change Script дозволяє зберегти сценарій у файлі sql, щоб його можна було повторити на іншому сервері

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

інформацій

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

Якщо ви створюєте базу даних для масового тиражування, то перевага реалізації схеми в сценаріях стає очевидним

■ Код сценарію знаходиться в одному місці Робота зі сценаріями SQL аналогічна роботі з мовами VBNET і С #

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

■ Якщо базовий сценарій бази даних містить весь код, необхідний для її створення, то найсучасніша версія бази даних може бути встановлена ​​без необхідності запуску сценаріїв змін або запуску процесу відновлення з резервної копії

■ Установка, яка освіжає нову базу даних, на противагу резервної копії має ту перевагу, що не містить будь-яких застарілих даних

У той же час робота зі сценаріями має і свої недоліки

■ Інструкції Т-SQL можуть виявитися незнайомими, а розмір сценарію може бути захмарно великим

■ Якщо обмеження зовнішнього ключа впроваджені в таблицю, то порядок операцій при створенні таблиці може виявитися критичним Якщо обмеження застосовуються вже після створення таблиць, то цей порядок може бути несуттєвим, однак при цьому створення зовнішніх ключів буде в програмі дистанційно віддалене від створення таблиць

■ Діаграми бази даних Management Studio не є частиною сценарію

Для роботи з обєктами (у тому числі і з таблицями) призначені наступні інструкції T-SQL: CREATE ALTER і DROP Наступна інструкція з навчальної бази даних Outer Banks Kite Store створює таблицю ProductCategory У ній представлено імя таблиці (разом з імям її власника-dbo), за яким слідують її стовпці Заключна рядок вказує серверу створити таблицю в первинній файлової групі:

CREATE TABLE dboProductCategory (

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, а в базі даних списку матеріалів на один первинний ключ рекурсивно посилається декілька зовнішніх (BillofMaterialsMateriallD і BillofMaterialsSourceMateriallD посилаються на первинний ключ 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 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*