Стратегия хранения заказов?

Question

[Игорь]

Коллеги, давайте разведём холивар.

Не даёт мне покоя, вопрос.
Вопрос связанный со стратегией хранения заказов.
Чем раньше я его решу тем лучше, а может кому-нибудь пригодится.

Ближе к делу.

Сущности
---------------
Product
Order
Customer
---------------

Здесь всё максимально просто.


Но мы ведь понимаем, что после того как человек заказал что-либо, всегда может поменяться цена.

Основной посыл вопроса, как хранить историю?
Нужно создавать ещё одну таблицу с товарами, где они будут фиксироваться?
Или достаточно сохранить название и цену, где-нибудь в History Products Orders.

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

Спасибо!

Comments

[Антон Р.]

после того как человек заказал что-либо, всегда может поменяться цена.

- очень странный магазин, у вас там раз в неделю манагер заказы обрабатывает или цены меняются раз в минуту?

[Игорь]

Антон Р., Не утрируйте, я всё прекрасно понимаю.
В жизни всякое бывает, мы стремимся к идеалу.

[Игорь]

В интернете много статей на эту тему.
Но во всех статьях, как всегда, заканчивалось всё на трёх таблицах.

Не, ну я посмотрел структуру OpenCart, там нет не чего сложного.
Там тоже ордера ссылаются на таблицу продуктов.
Но при этом там реализованно следующим образом

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

При этом таблица order_product ссылается на product.
В таблице product этого товара может уже не быть.

Answer 1

[Дмитрий]

Тут вряд ли можно развести холливар. У заказа должен быть таймстемп и у записи изменения цены должен быть таймстемп, соответственно цена для заказа должна быть равна самой поздней записи установки цены со временем меньшим чем время заказа.

То есть price должен быть не в product (хотя там можно оставить, чтобы получить актуальную цену на текущий момент), а в таблице prices (timestamp, product_id, price) индексированной по двум первым колонкам.

Answer 2

[ThunderCat]

ИМХО(во всяком случае я делаю так):
есть таблица orders, с которой связана ordered_items, которая в свою очередь суть дубль таблицы товаров, кроме поля qty - количество. И в админке можно открыть заказ, посмотреть товары, поудалять если отказались етц...

Comments

[Игорь]

Да, это уже ближе.
Получается, что имя сущности должно быть OrderItem ?

[ThunderCat]

Игорь, больше подходит OrderItem(s), так как они "принадлежат" заказам

[Игорь]

ThunderCat, Я имею в виду с точки зрения сущности
Сущность как одна единица. (Класс)

[Игорь]

Например вот так

/**
 * @ORM\Entity(repositoryClass="App\Repository\OrderItemRepository")
 * @ORM\Table(name="order_items")
 */
class OrderItem
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     */
    private $id;


    /**
     * @var string
     * @ORM\Column(type="string", length=255)
     */
    private $name;

    /**
     * @var float
     * @ORM\Column(name="price", type="decimal", precision=15, scale=2)
     */
    private $price = 0.0;

    /**
     * @var int
     * @ORM\Column(name="count", type="integer")
     */
    private $count = 1;
}

Почему класс в единственном числе?
Ну потому что, когда мы делаем выборку нескольких записей.
ORM создаёт множество копий классов OrderItem

В базе во множественном числе
Сущность в единственном числе, я придерживаюсь этой концепции

[ThunderCat]

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

[ThunderCat]

Игорь,

Я имею в виду с точки зрения сущности
Сущность как одна единица. (Класс)

В Yii принято называть от таблицы, и принято называть таблицы во множественном числе. В зенде / симфони в единственном. Я лично за сущности в единственном числе, но указал оба варианта.

[Игорь]

Раз мы тут уже развели холивар.
Правильно я понимаю, что репозиторий у сущностей Order, OrderItem может быть один OrderRepository.

[Игорь]

На этапе тестирования.
Сейчас получаю следующую структуру

{
    "data": {
        "id": 1,
        "amount": 1650,
        "products": [
            {
                "id": 1,
                "price": 150,
                "count": 5,
                "name": "Кофе"
            },
            {
                "id": 2,
                "price": 180,
                "count": 5,
                "name": "Бургер"
            }
        ],
        "status": 1,
        "order_sn": "DS12345",
        "create_at": "2019-10-01T21:37:21+00:00"
    },
    "code": 0
}

[Игорь]

code -> непонятно что это и почему вне data находится.

Это код ошибки, 0 ошибок нет
Сервер при любом раскладе событий возвращает валидный json

[Игорь]

xzdshr, Спасибо большое.
Да, формат уже определён.

[Игорь]

Заморочился до того что даже если back-end полностью отвалился и не работает, существует прокладка виде дополнительного сервера nginx который проксирует на бэкенд. proxy_pass

A backend где-то там в докере.

[Игорь]

В общем в итоге всё получилось.
Получилось так как я и предполагал.

Спасибо участникам холивара.

Чуть позже сформирую полный ответ возможно кому пригодится.

Продукты добавляются, удаляются, а хронология заказов и их деталей такие как названия товара, цена, обязаны хранится в базе данных.

В любой момент всегда можно отмотать клубок.

[Игорь]

xzdshr, Я тут с вами не соглашусь, Объясню почему.

В случае успешного ответа сервера на клиенте, Я всегда проверяю параметр, code. Даже если ответ правильный.

А теперь про сценарий неудачного ответа сервера.

В случае неудачного ответа сервера, или даже возникновение логической ошибки, например пользователь не существует или пользователь уже зарегистрирован, параметр code имеет положительное значение + дополнительное описание

Данную концепцию я подсмотрел у китайских коллег, изучив их документацию API

[Игорь]

xzdshr,

REST API сервисов

Все верно.

Ту модель которую я использую, так же похоже на API в vk.com
например:

{
"error": {
"error_code": 100,
"error_msg": "One of the parameters specified was missing or invalid: new_password should be at least 6 letters length",
"request_params": [{
"key": "oauth",
"value": "1"
}, {
"key": "method",
"value": "account.changePassword"
}, {
"key": "v",
"value": "5.101"
}]
}
}

Просто схемы разные, вот и всё.

От ошибок протокола я абстрагировался.
HTTP всегда должен быть 200, даже при землетрясении.

[Игорь]

В общем, эта тема для отдельной беседы, совершенно точно.

[Игорь]

xzdshr, Спасибо.

Ну не только китайцы.
Я же указал, vk.com
Очень грамотно API реализовано.
Я конечно не в силах оценить в полной мере, правильность архитектуры API VK

Вот например API у Яндекса отвратное.
Так у них если я не ошибаюсь, как раз на ошибках протокола всё базируется.

[Игорь]

xzdshr, Да, спасибо.

Я считаю, что не грех исключить сразу все неправильные варианты (ответы).

Исходя из этого тезиса.

Я имею некий профит, а именно.

1. Решив задачу неправильно, я исключаю её, тем самым приближаюсь ближе к истине.
2. Если попадаю в 10, то пожинаю плоды, иду дальше.

[Игорь]

Решив задачу неправильно

Правда, могут пострадать другие люди.