Базы данных в реальном мире

Что будет если студенту дать спроектировать базу данных интернет-магазина ? Пусть студент будет сферический в вакууме, дабы никого не обидеть, но пример абсолютно жизненный.

Студент будучи хорошим учеником, спроектирует что-то вроде такой схемы:

products (id, name, price, quantity) -- для хранения товаров и остатков
users (id, name) -- для хранения пользователей
orders (id, date, sum) -- для хранения заказов

Потом студент свяжет эти таблицы, и будет прав, теория на его стороне:

users_orders (id_user, id_order)
orders_products (id_order, id_product)

Если студент был не просто хорош, а очень хорош, он навесит индексы, и foreign-keys.

Магазин начал работу, товары вносятся в базу, появились клиенты, пошл продажи. Все хорошо, убрали позиции старого ассортимента, добавили новые, пара клиентов забыли свои пароли и создали новые аккаунты. Тут начались чудеса – звонит клиент и просит найти старый заказ, а его нет. А если есть заказ, он оказывается пуст… В чем же ошибка ?

Ошибка в том что в эту сферически-вакуумную базу не были внесены некоторые неидеальности, чтобы учесть неидеальность реальности.

Заказ в интернет-магазине – это не просто список, это факт. Это – снимок реальности в каком то моменте времени. Поэтому таблица должна была выглядеть так:
orders_products (id_order, product_name, product_price, quantity, sum)

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

С foreign keys и каскадным удалением тоже шутить не надо – удаление плохого пользователя из таблицы users не должно удалять его заказы. Заказ – это факт свершенный, отрицать его или выкинуть ради красоты теории будет неверным.

Leave a Reply

You must be logged in to post a comment.