Правильно ли составлена схема для магазина?

Question

[Семен]

Правильно ли составлена структура базы данных для учета клиентов, товара и продаж для магазина? Особенно интересует логика учета товара и заказов.

spoiler

Comments

[Akina]

Бизнес-процессы в магазине могут быть организованы по-разному. Соответственно и схемы могут быть разные.
Выкладывайте описание бизнес-процесса и выполненный анализ предметной области - будем смотреть, соответствует одно другому и составленной схеме или нет.

Навскидку могу сразу сказать, что схема косая. Денормализована таблица адреса. Лишняя связь между товаром в магазине и товаром в заказе (Вы путаете pattern и entity). Хранение цены во FLOAT, а даты и времени в отдельных полях - тоже ошибка. Это то, что видно сразу.

[Ипатьев]

для чего таблица store?

[Семен]

Akina, Логика следующая:
1. Необходимо хранить данные о клиентах:
- ФИО;
- дата рождения;
- пол;
- населённый пункт, где он находится;
- номера телефонов и адреса доставки (их может быть несколько).
2. Есть товары, параметры которых заранее определены, а также склад (таблица store), где где одни и те же товары могут иметь разную цену продажи, в зависимости от закупочной цены.
3. Клиент делает заказ, разумеется может покупать несколько товаров за один заказ.

[Семен]

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

[Семен]

Akina, какой тип данных выбрать для поля с ценой товара? Как правильно хранить адрес?)

[Akina]

какой тип данных выбрать для поля с ценой товара?

DECIMAL

Как правильно хранить адрес?

Зависит от страны. Если Россия - то достаточно кода по ФИАС.

[Василий Банников]

Akina,

Если Россия - то достаточно кода по ФИАС.

Ну закэшировать текст, чтобы каждый раз не ходить в какую-нибудь внешнюю апишку за информацией по Id

Answer 1

[Ипатьев]

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

В таблице заказов очень сильно не хватает поля status. Ну и связанной таблицы с историей статусов.
Отдельно хранить дату и время - это глупость. Есть тип datetime
discount - это ОЧЕНЬ отдельная тема. Но по крайней мере скидка должна размазываться по товарам. Если клиент при выкупе откажется от одного, то как пересчитывать цену?
В целом стоит в заказе дублировать основную инфу по товарам. Потому что её надо показывать в истории заказов, а товара может уже не быть в базе. В том числе цену до скидки и со скидкой.

Непонятно, что за таблица store.

Comments

[Семен]

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

[Ипатьев]

Одни и те же товары могут иметь разную цену продажи, в зависимости от закупочной цены - это какой-то бред. Цена товара не зависит от закупочной. И как все эти шуры-муры относятся к заказу?
"Клиент делает заказ, разумеется может покупать несколько товаров за один заказ." - и у него типа в корзине три одинаковых товара, все с раной ценой? Серьёзно?

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

[Семен]

Я исправил некоторые Ваши замечания. Убрал отдельную таблицу с адресами и таблицу с телефонами, добавил таблицу с историей статусов заказов, таблицу с оплатой и таблицу с доставкой. Изменил некоторые типы данных полей на более приемлемые (DATETIME вместо DATE и TIME, тип DECIMAL для цены).

Прошу еще оказать помощь в хранении товара на складе.

Есть таблица products_in_orders. В ней храняться код товара, его цена и количество товара, чтобы можно было посчитать сумму заказа. Эта таблица свяана составным ключом (код товара и его цена) с таблицей store (склад). Да, так получается, что один и тот же тавар может иметь разную цену (так задумано).

Дальше у меня большие сомнения, что я правильно реализовал хранение данных о таварах на скалде. Есть два типа товара (всего их будет не больше 10) для них созданы отдельные таблицы с уникальными для каждого типа товра атрибтами. Эти таблицы связаны с общей таблицей products, которая связана со скалдом (store).
Такая структруа позволит делать запросы на поиск конкретного типа товара с конкретными атрибутамми?
Какие я грубые ошибки допустил в проектиовании?

[Ипатьев]

Непонятно, зачем информация о платежах в отдельной таблице. Я видел, что это рекомендовали, но не понимаю логику.
Доставка тоже какая-то странная. непонятно, чем отличаются таблицы points_purchase и delivery
Товары должны быть в одной таблице. Специфические свойства хранить в json поле
можно добавить служебную таблицу тип товара-джейсон с набором свойств, чтобы из неё брать структуру.

[Ипатьев]

И непонятно, куда делись скидки

[Семен]

Оплату храню в отдельной таблице, чтобы в ней содержалась информация (наличный или безналичный расчет) можно еще время платежа добавить. Думаете это лишне?)

points_purchase - информация о заказах в самом магазине, а не онлайн. Если будет несколько точек, информацию хочу в этой таблице держать.

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

Если я буду хранить свойтва товаров в json я смогу делать запросы для фильтрации по одному выбранному свойству?

[Ипатьев]

Я не понимаю. Это какая-то белиберда. "храню в отдельной таблице, чтобы в ней содержалась информация". Что это? Как это объясняет необходимость отдельной таблицы? В той же таблице нельзя хранить, чтобы содержалась информация? Почему только оплаты? Почему бы тогда и для цены не сделать отдельную таблицу? "Чтобы в ней содержалась информация".

Если points_purchase - это заказы в магазинах, то ПОЧЕМУ там АДРЕС?
И чем принципиально отличается магазин от доставки?

Что такое order_price в таблице delivery? Стоимость доставки? И называется она order_price, серьёзно?

[Семен]

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

В points_purchase находится адрес магазина в котором совершена покупка (в будущем их будт несколько).

С order_price в delivery мой косяк, согласен.)

[Ипатьев]

И каждый раз в таблицу points_purchase будет писаться один и тот же адрес, серьёзно? Вот прям серьёзно?

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

[Ипатьев]

Суть нормализации в том, чтобы не было идиотизма записью одного и того же адреса 100500 раз.
А не в том, чтобы произвольно разбивать таблицу пополам на две.

Answer 2

[Василий Банников]

1. Хранение адреса в виде записей в базе.
Думаю, вполне можно было бы обойтись текстовым полем и id по кладр/фиас/гар (если россия).
Всё равно все возможные форматы адресов ты нормально не покроешь (а если покроешь - это будет свой фиас)
2. Использование float для хранение цены товара
3. Скидка чисто в виде числа в заказе - вполне возможно, что ты захочешь ввести какую-нибудь более гибкую систему скидок.
В текущей ситуации такое невозможно.
Например скидку в виде абсолютного количества денег, полностью бесплатный/подарочный товар.
Скидку только на отдельную категорию товара, или систему баллов.
Так что я бы сделал бы отдельную таблицу со скидкой на заказ, которую бы мог потом расширять.
(в принципе, можно оставить пока так, а потом миграцией всё исправить)
4. (комментарий про хранение цены убран, тк я изначально не заметил поле store_price)
5. Хотелось бы, чтобы была функция оформления заказа без регистрации.
6. А, ну и да. В заказе должен быть указан адрес. У пользователя их может быть несколько, и должен быть способ определить, на какой именно доставлять. (а с учётом п5 - адрес должен быть самостоятельной вещью)
+ Должна быть система как и с ценой - адрес у уже завершённого заказа не должен меняться.
7. А где статусы заказа? Типа новый/оплачен/доставка/доставлен/завершён?

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

PPS: Применять такую схему я бы осмелился только в рамках курсовой работы в колледже. Даже на диплом это врядли тянет, не говоря о реальном мире.

Comments

[Ипатьев]

4. про фиксировать цену ещё где-то непонятно. где и зачем? Почему недостаточно текущей фиксации в заказе?
5 - это какие-то фантазии. По современным законам покупатель должен поставить галочку на согласии, и дальше уже возмущаться в своё удовольствие. Убрать таблицу пользователей - это смелый ход. Вы его, конечно же, применяли его не раз в своих проектах?

[Василий Банников]

Ипатьев,
4 - пардон, не заметил
5 - как раз вчера закон вышел, что интернет магазин не имеет права отказать в оказании услуги, если пользователь не соглашается указывать какие-то ПД, которые для оформления заказа не нужны.
Штраф 50к, емнип.
В частности, в такой ситуации нельзя обязывать пользователя регистрироваться в магазине, перед оформлением заказа.

Не будем же мы заводить миллион одноразовых аккаунтов в базу?

[Ипатьев]

Требовать персональные данные для заключения договора можно будет в двух случаях:

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

В общем, чухня какая-то. Выделенный фрагмент относится к 99% магазинов.

[d-stream]

Ипатьев, во многих инет-магазинах фигурирует нечто типа "быстрая покупка"/"купить в один клик" - без регистрации и т.п.
Конечно все хотят накопить базу под спам и т.п., но вот бывает и такое. Притом в маркетологических кругах под это есть миллионы научных работ и прочих "как увеличить продажи"...

[Ипатьев]

d-stream, да при чем здесь это? Как возможность сделать быструю покупку для 10% покупателей оправдывает полное удаление таблицы пользователей, личного кабинета, истории заказов, накопительных скидок?
Как вообще этот 1 клик связан с вопросом? При чем здесь накопить базу? Ну что за детский сад?

[Василий Банников]

Ипатьев,

полное удаление таблицы пользователей

Кто говорит про полное удаление? Просто сделать связь опциональной. И добавить адрес (ссылку на адрес) в заказ.

[d-stream]

Василий Банников, ну это ещё Чапек отметил в паттерне Imago )

[Ипатьев]

Вижу, что теперь уже никто.

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

[Семен]

Не могли бы вы взглянуть на исправленную версию.)

Прошу еще оказать помощь в хранении товара на складе.

Есть таблица products_in_orders. В ней храняться код товара, его цена и количество товара, чтобы можно было посчитать сумму заказа. Эта таблица свяана составным ключом (код товара и его цена) с таблицей store (склад). Да, так получается, что один и тот же тавар может иметь разную цену (так задумано).

Дальше у меня большие сомнения, что я правильно реализовал хранение данных о таварах на скалде. Есть два типа товара (всего их будет не больше 10) для них созданы отдельные таблицы с уникальными для каждого типа товра атрибтами. Эти таблицы связаны с общей таблицей products, которая связана со скалдом (store).
Такая структруа позволит делать запросы на поиск конкретного типа товара с конкретными атрибутамми?
Какие я грубые ошибки допустил в проектиовании?

[Василий Банников]

Семен, обсуждать схему данных без требований к системе нет никакого смысла

[Семен]

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

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

Какие еще требования к системе Вас интересуют?)

[Василий Банников]

Семен,
1. Для точек продажи существует общепринятый термин "point of sale"
2. Для фильтрации по куче разных полей у товаров, есть паттерн Entity-Attribute-Value, либо, если у тебя postgres - можешь попробовать jsonb-колонку.
Для удобства, можно ещё подумать над заведением отдельной таблицы, где будет кэшироваться, какие поля у каждого типа имеются.
Раскидывать разные типы по разным таблицам конечно можно, но это будет не удобно (по своему опыту).

Почему у тебя на схеме у одного заказа может быть несколько point of purchase?

[Семен]

1. Спасибо, исправлю.)
2. Читал по EAV, многие говорят, что жутко медленно все работает. Да и у меня до 10 групп товаров и у каждого не более 3 атрибутов.
Уменя MySQL, там есть тип json, если в таком поле размешать атрибуты товара, фильтрация будет по ним возможна?

"Почему у тебя на схеме у одного заказа может быть несколько point of purchase?"
Моя косяк, исправлю.)

[Василий Банников]

Семен,

Уменя MySQL, там есть тип json, если в таком поле размешать атрибуты товара, фильтрация будет по ним возможна?

Не знаю, как с этим в mysql. В pg можно индексы вешать - это точно.

Answer 3

[full_stack_newbie]

Если это не курсовая, то сыро.
Цены - в отдельную таблицу, добавлять период действия. Если цена меняется с завтрашнего дня, вы когда их менять будете?
Закупочные цены - тоже имеют свойство меняться. Партии товаров на складе могут иметь разную цену поступления. Не увидел, что будет двигать остатки товара на складе (на вход).
Оплаты фиксировать в отдельной таблице, там будут конкретные транзакции, типы оплаты, не стоит это все пихать в заказ.
Скидки - так же в отдельную таблицу, период действия, типы скидок, etc
Это очень кратко.

Comments

[Ипатьев]

Цена спокойно меняется с момента, когда она меняется. Какие проблемы с этим?

[full_stack_newbie]

Ипатьев, Условной тете Маше надо 4 часа что бы набить новые цены на 8 тыс SKU.
Действовать они должны начать в воскресенье в 8-00, а тетя Маша работает понедельник-пятница.
Где хранятся цены до воскресенья? Усложню вопрос, магазины работают во всех часовых поясах РФ.

[Ипатьев]

Цены - это вообще область отвественности CRM.
Нас сайт когда выгрузят - тогда и будут применяться.

[full_stack_newbie]

Ипатьев, CRM и сайт в продуктовом магазине "У Вазгена" ? Не смешите.
Еще можно долго расписывать про хранение исторических данных, и финансовой аналитике, аналитике продаж но не вижу смысла.
По вашим рекомендациям он даже маржу посчитать не сможет.

[Ипатьев]

Вот это я понимаю - гибкость мышления :)
Только что у нас были филиалы во всех часовых поясах и цены менялись по секундам - и тут же оказывается что это продуктовая лавочка "У Вазгена" :)

Маржу ему 1с посчитает.