Це простий приклад того, як може виглядати цілком типова база даних.
У проектуванні бази даних перша справа, яку Ви повинні зробити, це обчислити послідовність дій, необхідних Вам для вирішення поставленого завдання. У SQL це може виглядати так:
Перший рядок повідомляє СУБД MySQL, що ми визначаємо таблицю по імені Widget_Table. Наступні шість рядків визначають поля, які таблиця містить, тип даних, які входять в них, і які атрибути ці поля мають.
Перш, ніж Ви зможете створити цю таблицю, Ви повинні створити порожню базу даних. В MySQL це виконано за допомогою програми mysqladmin.
Одна з безлічі основних концепцій в хорошому проекті реляційної бази даних це те, що Ви ніколи не повинні зберігати надлишкові дані. У разі Widget_Table це відображено в полях Widget_color_id і widget_size_id. Ці два поля могли б бути рядками. Натомість ми робимо їх покажчиками на інші таблиці, які будуть містити один запис для кожного можливого значення, яке може містити таке поле.
Це зроблено з двох причин:
- несуперечливість
- централізація складності
Widget_id поле - середовище (3 байт) встановлене за розміром ціле число. Це має спеціальні атрибути NOT NULL і AUTO_INCREMENT. NOT NULL є ANSI SQL стандартом і визначає що, коли хтось вводить widget інформацію в цю таблицю, вони повинні дати деяке значення для цього поля. Якщо не дали, MySQL призначить полю значення за замовчуванням. Звичайно, якщо значення за замовчуванням було визначено, то буде використовуватися воно, коли не задано ніякого значення. Якщо ж воно не визначено, то поле отримає значення, виходячи з його типу.
AUTO_INCREMENT специфічний атрибут MySQL. Якщо Ви вставляєте нуль в це поле MySQL, автоматично призначить значення, яке на одиницю вище, ніж найвища попереднє значення, призначений до цього поля в цій таблиці. Це простий метод для виробництва унікальних ідентифікаторів для нового widgets, оскільки вони введені в таблицю.
Ми також визначаємо кілька ключів. Коли Ви призначаєте полю атрибут AUTO_INCREMENT, Ви повинні також визначити це поле як первинний ключ. Ви можете мати тільки один первинний ключ на таблицю. Тільки одне поле на таблицю може мати AUTO_INCREMENT атрибут.
Ми також створюємо вторинні індекси використанням слова KEY. Індексування значно збільшує швидкодію запитів і об'єднань. Індекси можуть включати більше ніж одне поле. Якщо Ви маєте індекс, який включає більше ніж одне поле, незначна потреба в створенні іншого індексу з першим полем в складеному індексі.
Ми визначили Widget_Table. Тепер треба визначити шлях стеження за замовленнями. Для цієї мети ми визначаємо таблицю Purchase_Order.
Ще одне цікаве поле last_action_date. Це поле має тип TIMESTAMP. Поля цього типу автоматично модифікуються щоразу, коли на них виконується команда INSERT або UPDATE. Це показує, коли запис був в останній раз змінена.
Таблиця для Purchase_Order_Item:
У таблиці Purchase_Order_Item зберігається інформація про всіх елементах поля способу покупки. Тут зберігається інформація про те хто, коли, що і скільки замовляв.
Тепер давайте подумаємо. Серед замовників напевно знайдуться вільні торговці, які раді продавати Ваш товар за своїми цінами. Непогано б їх залучити до себе, наприклад, невеликий скидочку. Але для цього треба хоча б приблизно уявляти, хто купив товар для себе, а хто на продаж. Відмінно, накриємо їх ковпаком.
Потрібні ще три прості таблиці для службової інформації:
Таблиця Status дуже проста. Нам потрібен унікальний числовий ID, який пов'язаний з коротким текстовим полем, яке містить текст коду стану.
Таблиці Widget_Color і Widget_Size майже ідентичний таблиці Status. Тільки імена змінені.
Усе! Можна вводити дані.