powered by simpleCommunicator - 2.0.28     © 2024 Programmizd 02
Map
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Сохранение в БД истории данных изменения цены на товары в интернет магазине.
57 сообщений из 57, показаны все 3 страниц
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119413
shantiom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем доброго дня!
Как правильно организовать хранение в БД истории изменения цен на товары в интернет магазине.
То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч.
Потом эти данные хочу сохранить в БД для последующего анализа.

Пока накидал такую структуру:

1) Таблица   Product (id, art, product_name)
2) Таблица Price (id, date, price, fk_product_id)
3) Таблица Category (id, category_name, fk_product_id)
4) Таблица Brand (id, brand_name, fk_product_id)

СУБД - Postgresql

В правильном ли направлении я двигаюсь ? Это мой первый опыт работы с БД и СУБД)
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119505
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shantiom,

В Price id не имеет значения можно убирать смело.
Brand (id, brand_name) приводим в такой вид. Бренд закидываем в Product. Конечно если бренд это производитель, а не сферический конь в ваккууме.

Ну и это все актуально если парсим сторонние сайты, а не свою поделку. Правда уже есть куча сервисов в которых видна динамика цен. )
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119511
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проще у владельца сайта попросить непосредственный доступ к БД. Если даст -
ничего парсить не придётся и с некоторой вероятностью там уже будет история цен.
Если не даст - этот топик перейдёт в разряд нарушения авторских прав и прочего
оффтопика.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119521
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Злой Бобр
В Price id не имеет значения можно убирать смело.

Я бы не стал. Тогда надо будет использовать мало того, что естественный ключ, так еще и композитный.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119523
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
Если не даст - этот топик перейдёт в разряд нарушения авторских прав

Почему?
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119527
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthatПочему?

Во-первых, это может быть явно запрещено в Terms of Service.
Во-вторых, если он собранные данные перерабатывает для себя - это fair use, но
если он их публикует и тем более за деньги, да ещё и выдавая за своё...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119529
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
fkthatПочему?

Во-первых, это может быть явно запрещено в Terms of Service.
Во-вторых, если он собранные данные перерабатывает для себя - это fair use, но
если он их публикует и тем более за деньги, да ещё и выдавая за своё...
Тогда "Яндекс Маркет" и им подобные это вообще преступная банда хуже нацистов :))
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119768
shantiom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov

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


Спасибо конечно за совет по АПИ, но это все вообще не относится к вопросу.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119769
ASNexus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fkthat
Dimitry Sibiryakov
пропущено...

Во-первых, это может быть явно запрещено в Terms of Service.
Во-вторых, если он собранные данные перерабатывает для себя - это fair use, но
если он их публикует и тем более за деньги, да ещё и выдавая за своё...

Тогда "Яндекс Маркет" и им подобные это вообще преступная банда хуже нацистов :))


Судя по тому, что на "Яндекс Маркет" есть данные далеко не по всем магазинам (в том числе и вполне известным), можно предположить, что они как раз используют данные только тех, с кем у них есть соответствующие соглашения, и, возможно, плюс тех, кто в принципе не ограничивает использование своей информации (в том-же Terms of Service)
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119770
shantiom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Злой Бобр
shantiom,

В Price id не имеет значения можно убирать смело.
Brand (id, brand_name) приводим в такой вид. Бренд закидываем в Product. Конечно если бренд это производитель, а не сферический конь в ваккууме.

Ну и это все актуально если парсим сторонние сайты, а не свою поделку. Правда уже есть куча сервисов в которых видна динамика цен. )


Спасибо за ответ.
Вообще вот что я нашел на эту тему, может кому пригодится:
Для сохранения такого рода данных используют Slowly_changing_dimension
https://en.m.wikipedia.org/wiki/Slowly_changing_dimension
https://www.sql.ru/forum/620607/shablony-primeneniya
https://www.sql.ru/forum/900025/scd2
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40119803
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shantiom
Вообще вот что я нашел на эту тему, может кому пригодится:
Для сохранения такого рода данных используют Slowly_changing_dimension

Цена - это ну совсем не dimension. Это стопроцентный и однозначный fact.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121225
artel.dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer
shantiom
Вообще вот что я нашел на эту тему, может кому пригодится:
Для сохранения такого рода данных используют Slowly_changing_dimension

Цена - это ну совсем не dimension. Это стопроцентный и однозначный fact.


Продажа товара, транзакция, и стоимость транзакции - это fact.

Цена товара на конкретный день - это dimension.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121227
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
artel.dev
Цена товара на конкретный день - это dimension.
.
Если бы это была "просто цена", то было бы да, но приписка "на конкретный день" уже сама по себе указывает что это fact.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121262
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
artel.dev
Продажа товара, транзакция, и стоимость транзакции - это fact.

Да.

artel.dev
Цена товара на конкретный день - это dimension.

Нет. Это факт, причём не связанный с фактом продажи товара.

Если бы цена товара была dimension - значит, хотя бы теоретически могли бы существовать два факта (продажи товара), отличающиеся только значением этого dimension.

Ты прав в том, что есть ряд сущностей, которые сами по себе являются фактом, но при этом могут выступать как измерение для другого факта. Но это - не тот случай.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121268
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Если бы цена товара была dimension - значит, хотя бы теоретически могли бы существовать два факта (продажи товара), отличающиеся только значением этого dimension.

это происходило, происходит и будет всегда происходить причем даже не теоретически а практически:
- текущая цена в прайсе на день 1000 р
- одному продали без скидки за 1000 р
- другому продали со скидкой 10 % за 900 р
- третьему ............................20% за 800 р

А это всё не просто был один и тот же товар, это вообще один и тот же батон колбасы, половина которого до сих пор лежит на прилавке и его сегодня еще купят 5-10 покупателей не известно по какой цене...
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121269
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
это происходило, происходит и будет всегда происходить не теоретически а практически:
- текущая цена в прайсе на день 1000 р
- одному продали без скидки за 1000 р
- другому продали со скидкой 10 % за 900 р
- третьему ............................20% за 800 р

Применённые скидки, категории клиентов итп. - это разные dimension-ы. И это как раз теория. Я о случае, когда один товар, одна категория клиентов, одни скидки, одна секунда - а цена разная, причём и та, и другая - названы как возможная (разные элементы dimension-а).

На практике происходит другое. Текущая цена в прайсе (для этой категории покупателей, с этими скидками итп.) 1000, а продали за 990. Почему? А потому, что ценник не успели поменять, например. Или ещё по уйме причин. У меня на текущем месте работы вообще был замечательный случай. Два магазина, ну там допустим Adidas и Nike. И вот, покупатели зашли в первый, и там пока они расплачивались на кассе, ребятёнок взял поиграться маленький резиновый мячик. И они ушли. Зашли во второй, и там на кассе этот мячик заметили и пробили. А поскольку у магазинов общий владелец - мячик взял и пробился. Информация об этом ушла в общий учёт, и он маленько встал на уши. Можете помедитировать над вопросом, по какой цене он при этом пробился - из первого магазина или из второго.

И вот поэтому цена - это не dimension. Это просто атрибут транзакции: товар продан по такой-то цене. За конкретную единицу получено столько-то денег. Это реальность, факт нашей жизни. Который может попадать в некий факт из "цен", а может и не попадать.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121279
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Автор пишет - собираю для анализа.
И нужна история изменения цен.

Наверное копеечная точность автору не будет нужна.
А будут нужны какие-то тренды. Типа - растет цена на масло за период в среднем, или падает.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121282
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

то, что анализируется - это тем более fact. Dimension - это разрез, в котором может производиться анализ.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121284
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нам не стоит в топике обсуждать фактическую цену продажи товара.
Это оффтоп и запутывает автора. Автор - парсит сайты и там будут
только прайсы без фактов продаж.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121309
Александр Бердышев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, вы что, угараете что ли?)
Есть же стандартный подход: в таблице Price вместо поля date вводим BeginDate и EndDate и храним периоды действия цен.
Если цена не менялась год - вместо 365 записей будем хранить 2.
Я на собесах эту задачу на мидла задаю...
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121321
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Автор - парсит сайты и там будут
только прайсы без фактов продаж.

Еще раз. Там будут прайсы товара на определенную дату . А прайс товара на определенную дату это уже fact, для которого dimensions это, например, "дата прайса", "продавец", "город продавца", "товар", "категория товара" и т.п.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121323
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Бердышев
Есть же стандартный подход

Можно ссылку на этот "стандарт"?
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121382
Александр Бердышев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
mayton
Автор - парсит сайты и там будут
только прайсы без фактов продаж.

Еще раз. Там будут прайсы товара на определенную дату . А прайс товара на определенную дату это уже fact, для которого dimensions это, например, "дата прайса", "продавец", "город продавца", "товар", "категория товара" и т.п.

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

ссылка на товар / цена / начало действия этой цены/ дата окончания действия этой цены.
Так, как я написал - в данном случае хранить оптимальнее всего.
1. Займёт меньше места.
2. Быстрее будет работать - т.к. данные меньше весят -> меньший объём нужно читать с диска и обрабатывать
3. При такой структуре таблицы ещё и запросы удобно писать.

Правда нужно будет аккуратнее подходить к индексам - если запросы будут с аналитикой за период.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121384
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shantiom

СУБД - Postgresql

Ради расширения кругозора. Есть специальные структуры данных для темпоральных сведений в таблицах

Oracle - Temporal Validity Support
https://docs.oracle.com/database/121/ADFNS/adfns_design.htm#ADFNS967

MSSQL - Temporal Tables
https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121391
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЕсть специальные структуры данных для темпоральных сведений в таблицах

Но в данном случае они не подходят, поскольку считают периодом срок от DML до
DML и им невозможно указать требуемые значения вручную.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121404
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Бердышев
У нас цель поспорить, где таблица фактов, а где измерений?
Постановка задачи - нужна бд для аналитики цен по товарам.

Аналитика всегда и подразумевает использование star/snowflake схемы. Сделай какую-то другую и ты очешуеешь от тормозов запросов.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121405
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Бердышев
ссылка на товар / цена / начало действия этой цены/ дата окончания действия этой цены.

Если данные собираются только в отдельные моменты времени в виде цены в этот момент времени, то что такое "дата начала" и "дата конца"?
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121414
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthatЕсли данные собираются только в отдельные моменты времени в виде цены в этот
момент времени, то что такое "дата начала" и "дата конца"?

Вероятнее всего это даты, когда очередное о-grab-ление сайта интернет-магазина
принесло новую цену. Не предлагаете же Вы хранить и анализировать сырые данные
каждого ограбления?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121419
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
Не предлагаете же Вы хранить и анализировать сырые данные
каждого ограбления?..

Если я правильно понимаю интерес автора, то для каждого сбора сохранял бы дату/время сбора, цену сбора и разницу с ценой предыдущего сбора.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121426
Александр Бердышев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Александр Бердышев
У нас цель поспорить, где таблица фактов, а где измерений?
Постановка задачи - нужна бд для аналитики цен по товарам.

Аналитика всегда и подразумевает использование star/snowflake схемы. Сделай какую-то другую и ты очешуеешь от тормозов запросов.

Хотите сказать, что сохранять по записи на день - будет работать быстрее, чем то, что я предложил?
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121476
Bsplesk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton
shantiom

СУБД - Postgresql

Ради расширения кругозора. Есть специальные структуры данных для темпоральных сведений в таблицах

Oracle - Temporal Validity Support
https://docs.oracle.com/database/121/ADFNS/adfns_design.htm#ADFNS967

MSSQL - Temporal Tables
https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15


Postgresql - timeseries extension (fast)
https://habr.com/ru/company/oleg-bunin/blog/464303/
https://en.wikipedia.org/wiki/Time_series

+Temporal Data & Time Travelin PostgreSQL
https://wiki.postgresql.org/images/6/64/Fosdem20150130PostgresqlTemporal.pdf
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121502
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Бердышев
Есть же стандартный подход: в таблице Price вместо поля date вводим BeginDate и EndDate и храним периоды действия цен.

Ага, у меня была такая структура. Но потом начинаются переоценки задним числом, конкурентные обновления и вся эта структура с грохотом наворачивается. Достаточно хранить только дату начала действия новой цены
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121507
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте разграничим юзкейсы по технологиям.

У нас есть таймсерии.
И есть темпоральность.

Я считаю что для данной задачи. Для задачи автора.
Подходит темпоральность. Цена действует в диапазоне времён. Это может быть открытие магазина или опер-дня. И цена может отсутствовать. Не торговался товар вчера к примеру.

Таймсерии тоже можно использовать но она больше применима к физике. Датчик меряет температуру.
Температура - точка во времени.

Вот как-то так думаю.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121510
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Шавлюк Евгенийконкурентные обновления

Чтобы нарваться на конкурентные обновления надо чтобы два человека одновременно
(плюс-минус время транзакции) изменили цену одного и того же товара в одном и
том же временном диапазоне. Это у тебя люди были такие шустрые или транзакции
такие долгие?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121512
Bsplesk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton
Давайте разграничим юзкейсы по технологиям.

У нас есть таймсерии.
И есть темпоральность.

Я считаю что для данной задачи. Для задачи автора.
Подходит темпоральность. Цена действует в диапазоне времён. Это может быть открытие магазина или опер-дня. И цена может отсутствовать. Не торговался товар вчера к примеру.

Таймсерии тоже можно использовать но она больше применима к физике. Датчик меряет температуру.
Температура - точка во времени.

Вот как-то так думаю.


Более того, в PostgreSql есть еще multirange (Диапазонные типы).
https://www.percona.com/blog/using-the-multirange-data-type-in-postgresql-14/
https://postgrespro.ru/docs/postgresql/14/rangetypes

Мне по постановке более похоже не на SCD (slow), а как раз time-series.
Есть датчики (сайты с ценами). С какой-то продолжительностью идет опрос (допустим раз в час). Дата изменения/обновления цен неизвестна! - толи в 4 часа утра обновили, а завтра 21:07 (есть возможность только получить факт изменения в моменте, и зафиксировать изменение). И показать, что с X по Y цена была изменена.
При этом у каждого "датчика" свой уникальный набор параметров, но можно выделить единые (тут раз нужен jsonb и соответствующие индексы).

Тем более для time-series есть отличная морда https://prometheus.io/docs/visualization/grafana/
Подключай да смотри всё красиво.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121514
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

Возможна ситуация когда сначала вводят накладную с новой ценой, затем понимают что ошиблись датой и меняют ее. В этом случае цена может разорвать один диапазон и появится в другом.
Ситуация конкурентности крайне редкая, но она возникает.
Есть товар цена установлена с 01.12.2021 по 01.01.2100 (макс. дата).
Далее вводят 2 документа с 19.12 и 20.12
Оба этих документа по отдельности разрывают предыдущий диапазон на 2.
И вот в случае одновременного сохранения документов получаем проблему. Следующая проблема если один из документов удаляется. То интервалы теперь надо "склеить".
Такой запрос намного проще
Код: sql
1.
Select first 1 price from prices where date <= :d order by date desc
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121516
Bsplesk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Шавлюк Евгений,

Не Дмитрий, но вклинюсь.
По поводу:
авторВозможна ситуация когда сначала вводят накладную с новой ценой, затем понимают что ошиблись датой и меняют ее. В этом случае цена может разорвать один диапазон и появится в другом.

Разве любое изменение не должно фиксироваться?, а исправление ошибок выполняется "корректирующей проводкой", чтобы было видно, кто ввёл ошибочные данные и почему тонну "золота" с 8:22 по 8:26 отгрузили/продали по 1000$, а должны были по 2000$.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121517
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Шавлюк Евгений
Но потом начинаются переоценки задним числом, конкурентные обновления и вся эта структура с грохотом наворачивается.

Это уже зависит от рук.

Шавлюк Евгений
Достаточно хранить только дату начала действия новой цены

Во-первых, недостаточно. "Дата начала действия новой цены" при возможности ввода задним числом не позволит знать, что в некоторый период действия цены не было. Во-вторых же, структура начало-конец позволяет писать более простые синтаксически и при этом более эффективно выполняющиеся запросы.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40121518
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Шавлюк Евгений
Возможна ситуация когда сначала вводят накладную с новой ценой, затем понимают что ошиблись датой и меняют ее. В этом случае цена может разорвать один диапазон и появится в другом.

Это ровно то, о чём я говорил здесь: 22411584 Ошибка в том, что цена из накладной вообще пытается что-то "разрывать". Это просто атрибут транзакции, это не dimension, и это значение не должен лезть за пределы своей операции.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123006
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Бердышев
Коллеги, вы что, угараете что ли?)
Есть же стандартный подход: в таблице Price вместо поля date вводим BeginDate и EndDate и храним периоды действия цен.
Если цена не менялась год - вместо 365 записей будем хранить 2.
Я на собесах эту задачу на мидла задаю...


Ваш стандартный подход очень смело обощается на задачу топикстартера.
А в задаче сказано - "сбор 2-3 раза в неделю", т.е. нам не известно каково было значение между этими сборами, и поэтому расширение даты сбора до каких-то других дат - это некоторое натягивание совы на глобус, изображаем в базе некие обобщения которые не факт что соответствуют истине. Если мы снимали данные 1и 10 числа, и данные совпали, то это не значит что в промежутке цена не такая же. Она там NULL.
Такой подход позволит иметь в базе записи про реальные факты, когда мы реально фиксировали имеющиеся в инет-магазине цены. В промежутке между считывания цены могли скакать как угодно, мы эти факты никак не фиксировали.

А вот потом уже, при обработке этих данных можно делать всякие обобщения и допущения, что бы попытаться из имеющихся данных увидеть какие-то тренды.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123023
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shantiom
Всем доброго дня!
Как правильно организовать хранение в БД истории изменения цен на товары в интернет магазине.
То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч.
Потом эти данные хочу сохранить в БД для последующего анализа.

Пока накидал такую структуру:

1) Таблица   Product (id, art, product_name)
2) Таблица Price (id, date, price, fk_product_id)
3) Таблица Category (id, category_name, fk_product_id)
4) Таблица Brand (id, brand_name, fk_product_id)

В правильном ли направлении я двигаюсь ? Это мой первый опыт работы с БД и СУБД)


ИМХО, для поставленной задачи структура верная. Если постановка тут описана правильно :)

Пара советов от меня, по личному опыту.

1. Удобнее структуру таблиц накидывать сразу в виде sql-скрипта, не прибегая к каким-либо иным нотациям. По крайней мере мой мозг заточился читать структуру именно так как она выглядит в базе, а все иные представления заставляют заниматься мысленным переводом в эту sql-структуру. Если все равно дело придет именно к sql - то зачем эти предварительные представления в каком-то ином виде?

2. Есть разные подходы к именованию полей, но тут смешано в кучу сразу несколько разных, и получается странно.
Мой подход такой:
- не повторять имя которое есть в имени таблицы в имени поля
- первичный ключ - это id (там где это возможно, а возможно почти всегда)
- ссылки на другие таблицы начинаются с id_[имя таблицы]

Соответственно, структура выглядела бы так:
Хм... как только начал приводить к виду sql так сразу вылезли косяки в структуре.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
-- https://www.sql.ru/forum/1340801/sohranenie-v-bd-istorii-dannyh-izmeneniya-ceny-na-tovary-v-internet-magazine

-- 1) Таблица Product  (id, art, product_name)
-- 2) Таблица Price    (id, date, price, fk_product_id)
-- 3) Таблица Category (id, category_name, fk_product_id)
-- 4) Таблица Brand    (id, brand_name, fk_product_id)

----------------------------------------------------------
-- справочник товаров
create table product (
  id         integer not null primary key,
  art        varchar(50),
  name       varchar(250)
);

----------------------------------------------------------
-- прайсы
create table price (
  id         integer not null primary key,
  id_product integer not null,  --> product.id
  date       date,
  price      numeric(18,2)
);

alter table price add constraint price_fk_idpost foreign key (id_product) references product (id);

----------------------------------------------------------
-- а вот дальше с предоставленной структурой не совсем все ровно.
-- исходный вариант такой

----------------------------------------------------------
-- справочник категорий
create table category (
  id          integer not null,
  id_product  integer not null, --> product.id
  name        varchar(100)
);

----------------------------------------------------------
-- справочник брендов
create table brand (
  id          integer not null,
  id_product  integer not null, --> product.id
  name        varchar(100)
);

-- эта структура позволяет связать с одним товаром N записей бренда и N записей категорий.
-- но при этом у нас полностью отсутствует понятие "справочник брендов" и "справочник категорий"
-- группировать что-либо по этим полям возможно только группировкой по полю varchar,
-- при этом возможно различное написание в разных записях и они сгруппируются в разные группы

-- Вариант организации справочника который часто применяю я, выглядит так

----------------------------------------------------------
-- справочник категорий
create table category (
  id          integer not null primary key,
  name        varchar(100)
);

----------------------------------------------------------
-- справочник брендов
create table brand (
  id          integer not null primary key,
  name        varchar(100)
);

-- а справочник ссылается на бренд и группу

----------------------------------------------------------
-- справочник товаров
create table product (
  id          integer not null primary key,
  --
  id_brand    integer, --> brand.id
  id_category integer, --> category.id
  --
  art        varchar(50),
  name       varchar(250)
);

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

-- соответственно, приходим к схеме: справочники отдельно, связи отдельно

----------------------------------------------------------
-- справочник категорий
create table category (
  id          integer not null primary key,
  name        varchar(100)
);

----------------------------------------------------------
-- справочник брендов
create table brand (
  id          integer not null primary key,
  name        varchar(100)
);

----------------------------------------------------------
-- справочник товаров
create table product (
  id          integer not null primary key,
  art        varchar(50), -- привязка к товару в магазине
  name       varchar(250)
);

----------------------------------------------------------
-- привязки товар <-> категория
create table product_in_category (
  id_product  integer not null, --> product.id
  id_category integer not null  --> category.id
);

alter table product_in_category add constraint product_in_category_pk primary key (id_product, id_category);

----------------------------------------------------------
-- привязки товар <-> бренд
create table product_in_brand (
  id_product  integer not null, --> product.id
  id_brand    integer not null  --> brand.id
);

alter table product_in_brand add constraint product_in_brand_pk primary key (id_product, id_brand);

----------------------------------------------------------
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123027
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fraksт.е. нам не известно каково было значение между этими сборами

Если бы аффтару были интересны краткосрочные колебания цен, он, натурально,
поднял бы частоту их сбора. Раз он этого не делает, значит они (колебания) могут
быть проигнорированы любым способом. Например, сглаживанием или интерполяцией.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123036
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

fraksт.е. нам не известно каково было значение между этими сборами

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

Могут быть проигнорированы. При обработке данных.
А речь идет про то что мы потратили ресурсы на сбор данных, но уже на этапе сохранения данных часть из них потеряли без возможности восстановления.
Например, было кратковременное отклонение цен. Зная дату и имея это в сохраненных данных можно делать выводы - мы это не увидели по причине того что не попали датой сбора в этот пик, или мы датой таки попали, но в этом магазине пика и не было.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123076
Bsplesk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

Тут кто, как понял автора.
На мой взгляд это:
  • Задача: Отслеживания цен конкурентов (мониторинг);
  • Процесс: Конкурентная корректировка цен (Real Time Marketing);
Далее выяснения причины снижение цены (возможно временная акция) или "последний товар/распродажа остатков" или (скорей всего вручную) ..... и возможный набор действий - снизить цену или сделать акцию x2, x3, "Нашли дешевле.. дадим скидку" и "всякое" маркетинговое или вообще уйти из этого региона (поставить его на отслеживание, вдруг демпингатор разорится), т.к. нет смысла и дать аналогичную цену нерентабельно. И вот все про это.

На мой взгляд задача 100% timeseries, т.к. мы не знаем точное время обновления и применения, окончания прайса. Возможно вообще нет смысла хранить сырые данные, а считать сразу агрегат/потоковой обработкой (со сглаживанием, интерполяцией), т.к. акция может быть из разряда:

HabrУ меня вот бизнес часто хочет что-то типа «всем зайчикам, проживающим в одной
хатке с бобриками, с 3 до 5 утра по их таймзоне, давать скидку на морковку зеленого
цвета, в 10 долларов в рублях по текущему курсу, если морковку сажали беременные
белочки, и грядки были не далее 10 км от речки».
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123080
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bsplesk
Возможно вообще нет смысла хранить сырые данные, а считать сразу агрегат/потоковой обработкой (со сглаживанием, интерполяцией), т.к. акция может быть из разряда:

Имеет смысл сначала сохранять сырые данные, а потом отдельным процессом их обсчитывать и складывать в удобную для потребления схему (т.е. то что во "взрослых" системах называется ETL).
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123082
Bsplesk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fkthat,

У нас есть требования: СУБД - Postgresql (для него есть расширения прим. PipelineDB хранит только результат потоковых вычислений).
Сырые данные могут занимать много места, а это затраты на их хранение.
Не каждому бизнесу нужны сырые данные, чтобы потом их крутить в условном "PowerBI" и искать закономерности, т.к. данных может быть слишком мало и основные моменты понятны и известны без всякого "machine learning".
С сырыми, конечно, лучше т.к. например легко даст картину, что магазин X в субботу и воскресенье даёт скидку 10%, а вот с "зайчиками" уже будет сложней и если данных нет, то ты хоть ужом извернись, но понять никак.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123089
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте еще раз вернемся к 1 посту автора.

То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч.
Потом эти данные хочу сохранить в БД для последующего анализа.

Пока накидал такую структуру:

1) Таблица Product (id, art, product_name)
2) Таблица Price (id, date, price, fk_product_id)
3) Таблица Category (id, category_name, fk_product_id)
4) Таблица Brand (id, brand_name, fk_product_id)

2-3 раза в неделю запускайтеся скрейпер который тянет инфу с сайта. Товаров несколько (но не десятки) тысяч.
Допустим их 5000 штук.

В снежинке самая толстая веточка - это price. Она и будет активно расти. Остальное - суть справочники.
3 раза в неделю по 5000 товаров - тоесть 15000 новых строк по изменениям цен в наихудшем случае.
Если инфляция какая-то. А так - цены не будут часто менятся. Старую темпоральную запись можно
просто не трогать.

Вот такая вот слабенькая система выходит.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123090
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bsplesk
fkthat,
...
Сырые данные могут занимать много места, а это затраты на их хранение.


авторизменения цен на товары в интернет магазинE.
То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч.
Потом эти данные хочу сохранить в БД для последующего анализа.

У автора заявлено в магазинЕ а не магазинаХ.
3 раза в неделю на нескольких тысячах товаров - смешные объемы данных.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123091
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

fraksт.е. нам не известно каково было значение между этими сборами

Если бы аффтару были интересны краткосрочные колебания цен, он, натурально,
поднял бы частоту их сбора.
Интернет-магазины борятся с такими сборщиками т.к. они создают значительную нагрузку на хостинге.
Посему увеличить частоту сбора может тупо не получиться - забанят.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123092
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я никогда не писал скрейперов за которые-бы кто-то заплатил денег. Но если-бы писал - то наверное
создавал бы деликатную нагрузку с паузами и работал - бы через 100 проксей.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123096
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fraksПосему увеличить частоту сбора может тупо не получиться - забанят.

Что и возвращает нас к 22408690
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123097
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

fraksПосему увеличить частоту сбора может тупо не получиться - забанят.

Что и возвращает нас к 22408690

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

А вот попросить дать инфу у владельца сайта - вполне может прокатить. Если у них есть разработчики или внятная техподдержка.
Доступа к БД конечно не дадут, но выгрузку вполне могут дать, что бы им сайт не дрючили парсером :)
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123099
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fraks

Доступа к БД конечно не дадут, но выгрузку вполне могут дать, что бы им сайт не дрючили парсером :)

Лучше дать доступы к зеркалу исторических данных. Хоть в CSV, хоть в JSON. Это всяко лучше
чем роботы будут дрючить html с пагинацией на 100500 страниц с дизайном.

Вот лет 15 назад была такая практика что например университеты имели свои сайты типа
www.univercity.org и такие-же публичные ftp ресурсы в домене типа ftp.univer.org. Всё открыто
для анонимоса. Заходи. Качай хоть закачайся. Научные работы кафедры. Всякое файло-барахло.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123103
Bsplesk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton,

Тут у всех позиция разная. В большинстве случаев никто, ничего просто так = бесплатно не даст (тем более исторические данные). Более умные предоставляют api с минимум информации (только та, что и так на сайте оф. открыта, а не, которую удалось выудить через "кривой запрос"). На api также будет ограничение, но работать будет удобнее, но без "вкусняшек". Тоесть только для того чтобы разгрузить сайт поставщику.
В большинстве ставят защиты, чтобы scraping стал невыгодным . Proxy стоят денег, как и работа + меняют артикулы или их формат, описание, в прежние "теги" подставляют фейковые данные (сразу и не поймешь, что тебя дурят, допустим просто мешают артикулы), вводят персональные, фантомные скидки и.т.д., что ручками замучаешься всё перемапливать и вычищать, чтобы сохранить историчность. Пара таких "финтов" и в БД будет помойка, которую разбирать только нейросетями.

В конкурентной среде, где торгуют одним и тем же Г. все методы хороши, в том числе доходит даже до пром. шпионажа.

При 15000 в месяц (180000/год) вообще не ясно зачем автору БД. Excel поддерживает 1048576 строк.
Сделать годовую ротацию и сохранять, как csv файлик, крутить сразу можно в памяти в Excel PowerQuery или аналогичном туле.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123181
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как-то давным-давно, сайт конторы в которой я работал, точно так же дрючили парсером. Причем там было хуже, они каждую минуту все позиции пробегали. Додрючили до того, что вроде бы наши достучались до них первыми и предложили забирать напрямую XML, который у нас использовался внутри, для тех же нужд.

Я к чему, можно конечно парсить, но лучше спросить, нет ли у них данных в формате данных, а не отображения.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123189
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bsplesk
Сырые данные могут занимать много места, а это затраты на их хранение.

Тут мы входящих не знаем. Нефункциональные требования автор не озвучивал. Может у него под БД древняя карта памяти на 256М, а может собственный ЦОД.
...
Рейтинг: 0 / 0
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #40123205
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
три страницы споров ни о чем...

shantiom
Как правильно организовать хранение в БД истории изменения цен на товары в интернет магазине.
То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч.


У автора нет проблем со сбором информации... СОБИРАЮ - значит уже собираю и нет смысла тарахтеть попами в эту сторону...
Автор мля, сохрани уже хоть как-то и через месяц поймешь чего тебе не хватает или на это укажет заказчик...
...
Рейтинг: 0 / 0
57 сообщений из 57, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Сохранение в БД истории данных изменения цены на товары в интернет магазине.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]