Как организовать сохранение данных между кварталами?

Question

[Anton Mashletov]

Допустим, имеется модель и таблица Product (id, name, price, ...), стандартный грид вывода списка, форма добавления / изменения.
Над гридом, есть фильтр по кварталу, где по умолчанию всегда стоит текущий квартал и год (1-ый 2018), но можно выбрать предыдущие (4-ый 2017, 3-ий 2017 и т. д.).
Все изменения, удаления и вывод должны быть строго в рамках квартала. Например, я сейчас (в 1 квартале 2018) добавлю новый продукт. При выборе 2017 года он естественно должен пропадать. Если я в следующем (2ом) квартале изменил цену или удалил продукт, то в первом должно быть как было. При этом продукты (кроме удаленных) должны переноситься из квартала в квартал.

Как лучше это организовать?

Comments

[Anton Mashletov]

Лентюююй, код не дам, ибо я его еще не написал. Разве не понятно поставил задачу?

[Anton Mashletov]

Лентюююй, Оставьте хамство при себе. Я не виноват, что вы не поняли такой простой постановки.

Answer 1

[sim3x]

Product
 SKU
...

ProductVariant
 product = ForeignKey(Product)
 name
 price = Decimal
 datetime as year_quarter
...

И запрещаешь апдейты, только добавление

Фильтрацию думаю обьяснять не требуется

Comments

[Anton Mashletov]

Цену я привек как пример. Вместо цены поле может быть любое, что есть в модели Product — название, статус, ... Делать на каждое поле по модели?

[sim3x]

Anton Mashletov, огласите ТЗ полностью

[Anton Mashletov]

sim3x, любое изменение записи в текущем квартале, не влияет на предыдущие. Всё.

[sim3x]

Anton Mashletov, в конце квартала дампить все в жсон и сделать ro

Когда будет тз, можно будет подумать решение покрасивее

[Anton Mashletov]

@sim3x, сделать ro

Что такое "ro"?

[sim3x]

Anton Mashletov, read only

[Anton Mashletov]

sim3x, Мне не нужно архивировать после каждого квартала. Объясню по-другому:

Сейчас я добавил продукт "Мой продукт", 1000 рублей. Сейчас 1кв2018.
Этот продукт отображатся в списке, все норм. Настал декабрь 2018 (это 4 кв). Я нажал на "редактировать", изменил название на "Мой продукт 111", и цену поставил поднял до 2000. Сохранил.
И теперь, переключая селект "квартал":
a) у меня в 4ом должен отображатся "Мой продукт 111" за 2000.
b) с 1 по 3 отображается "Мой продукт", 1000 рублей.

Я могу зайти, во второй квартал и удалить запись. Тогда будет:
I) "Мой продукт", 1000 рублей.
II) не отображается (удалено)
III) "Мой продукт", 1000 рублей.
IV) "Мой продукт 111" за 2000.
Настанет 2019 год. По прежнему будет висеть "Мой продукт 111" за 2000. пока его не поменяешь.

[sim3x]

Anton Mashletov, изменил ответ

Связываем все через SKU
В конце квартала копируем текущую запись товара с изменением кастомного поля datetime

Answer 2

[Иван Торгов]

Не самый идеальный вариант в плане организации БД, но предложу такой вариант:
1. Добавляете в таблицу поле квартал (можно типом enum от 1 до 4, так как у нас всего 4 квартала и их никогда не станет больше).
2. Для поиска используете поиск по этому полю, текущий квартал можно взять с помощью гетера quarter у Carbon-даты.
3. Для обновления используйте конструкцию updateOrCreate, в качестве первого параметра передаёте массив с идентификатором и номером квартала, а вторым параметром массив с остальными данными. Тем самым редактируя запись во втором квартале eloquent не найдёт её и создаст новую.

Comments

[Иван Торгов]

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

Answer 3

[Andreo]

Сохраняйте как обычно с полями created_at и updated_at, но выборку делайте в разрезе этих самых ваших кварталов по полю updated_at

Comments

[Anton Mashletov]

А если мне надо изменить поле какое-нибудь и чтобы предыдущий квартал не затронулся?

[Andreo]

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

Answer 4

[d-stream]

Гм... Я бы отделил номенклатурную единицу, поступления товаров и установки цен.

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

Ну а каждое поступление и реализация - имеют свои конкретные цены.

То бишь номенклатурная единица X поступала в разные даты с разными ценами-количествами (себестоимость), а реализовывалась в разные даты по разным (актуальным на тот момент) ценам.

Comments

[Anton Mashletov]

Я не совсем ясно поставил задачу :( Цены не при чём. Основная суть — любое изменение записи в текущем квартале, не влияет на предыдущие. Поле и модель могут быть любыми (продукт - для примера. на самом деле совсем не связано с товаром).

Пример:
Сейчас я добавил продукт "Мой продукт", 1000 рублей. Сейчас 1кв2018.
Этот продукт отображатся в списке, все норм. Настал декабрь 2018 (это 4 кв). Я нажал на "редактировать", изменил название на "Мой продукт 111", и цену поставил поднял до 2000. Сохранил.
И теперь, переключая селект "квартал":
a) у меня в 4ом должен отображатся "Мой продукт 111" за 2000.
b) с 1 по 3 отображается "Мой продукт", 1000 рублей.

Я могу зайти, во второй квартал и удалить запись. Тогда будет:
I) "Мой продукт", 1000 рублей.
II) не отображается (удалено)
III) "Мой продукт", 1000 рублей.
IV) "Мой продукт 111" за 2000.
Настанет 2019 год. По прежнему будет висеть "Мой продукт 111" за 2000. пока его не поменяешь.

[d-stream]

Anton Mashletov, я бы сказал, что не задача неверно поставлена, а архитектура несколько вводит меня в когнитивный диссонанс)

Все-таки "продукт", "персона", "контрагент" (не суть) - это этакие неизменные сущности, но имеющие исторические атрибуты (по-моему в 1с такой термин фигурировал). По сути - это две таблицы с отношением 1:N - сам объект с уникальным идентификатором, неизменными или же имеющими единственную актуальность атрибутами и переменные атрибуты с хронологическими отметками.