База даних інтернет-додатка

Інтернет-додаток|застосування| використовує бази даних для зберігання інформації. Інформація може оброблятися, зберігатися і витягуватися з|із| бази даних. У базі даних можна зберігати добре структуровану інформацію. Таку, як: список користувачів, список замовлень, прайси. Проте|однак|, цим вид інформації, що зберігається, не обмежується. У сучасних інформаційних системах в базах даних зберігаються і тексти, і зображення, і навіть виконувані програми або скрипти. Якщо буде потрібно, то в своєму застосуванні ви можете зберігати в базі даних інструкції і опису товарів.

Ви можете використовувати MS| SQL| Server| або сховище у вигляді MDB-файлу| Access|. Надалі ми орієнтуватимемося на MS| SQL| Server|. Для MDB-файлів| можливі відмінності|відзнаки| не принципові і полягають в незначних відмінностях|відзнаках| в синтаксисі SQL-запитів| і параметрах підключення до бази даних.

У цій статті ми визначимо мінімально необхідну структуру бази даних для нашого інтернет-магазину. Структура бази даних залежить від тих функціональних завдань|задач|, які повинен виконувати Інтернет-додаток|застосування|.

Давайте спробуємо визначити функціональні завдання|задачі|, що вирішуються|рішають| нашим застосуванням.

Спочатку визначимо категорії користувачів, що працюють з|із| магазином. Це можуть бути:

· анонімні відвідувачі|візитери| (користувачі, які не реєструвалися при вході в магазин);

· покупці (користувачі, зареєстровані в магазині);

· менеджери (користувачі з|із| розширеними правами).

Анонімні відвідувачі можуть "ходити" по магазину і "дивитися" товари.

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

Разовий покупець може оформити разове замовлення.

Зареєстрований покупець може не лише оформляти замовлення, але і проглядати історію і стан своїх замовлень. Більш того, для постійного покупця заголовні реквізити замовлення заповнюються додатком автоматично (ім'я покупця, контактні реквізити).

Менеджери магазина повинні мати можливість додавання товарів в каталог (виставити товар на вітрину), редагувати назви і ціни товарів, проглядати списки замовлень і список зареєстрованих покупців.

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

Всі покупки в магазині оформляються за допомогою замовлень. Замовлення - це електронний документ, в якому є дві частки: заголовок (дата замовлення, реквізити покупця) і вміст замовлення (перелік замовлених товарів і їх ціни).

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

Ми рекомендуємо в кожній таблиці використовувати спеціальні службові поля:

· Id - ідентифікатор запису (використовується в первинних ключах для адресації записів);

· Actual - ознака актуальності запису (використовується для розділення актуальних і неактуальних даних);

· UpdateDate - дата зміни запису (може використовуватися для сортування записів в хронологічному порядку);

· UpdateUser - ідентифікатор користувача, що створив або змінив запис (використовується для авторизації факту зміни запису).

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

Призначення поля, в загальному випадку, має бути зрозуміле з його назви. Наприклад, Users - таблиця користувачів, Wares – каталог товарів.

Хорошою|доброю| практикою є|з'являється| використання спеціальних префіксів в назвах або використання назв, що складаються з декількох слів. При цьому перше слово повинне означати суть|єство| інформаційного об'єкту, а друге слово (або решта слів) - уточнення.

Наприклад, якщо Ware – товар, а Cost – ціна, то полю «ціна товару» можна привласнити ідентифікатор WareCost.

Звичайно, використання цих нехитрих правил, не є|з'являється| обов'язковим, але|та| дозволяє значно полегшити вам життя при подальшій|дальшій| розробці і супроводі програмного|програмового| продукту.