|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Всем доброго дня! Как правильно организовать хранение в БД истории изменения цен на товары в интернет магазине. То есть, собираю данные с сайта интернет-магазина, сбор 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 В правильном ли направлении я двигаюсь ? Это мой первый опыт работы с БД и СУБД) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2021, 14:07 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
shantiom, В Price id не имеет значения можно убирать смело. Brand (id, brand_name) приводим в такой вид. Бренд закидываем в Product. Конечно если бренд это производитель, а не сферический конь в ваккууме. Ну и это все актуально если парсим сторонние сайты, а не свою поделку. Правда уже есть куча сервисов в которых видна динамика цен. ) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2021, 21:34 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Проще у владельца сайта попросить непосредственный доступ к БД. Если даст - ничего парсить не придётся и с некоторой вероятностью там уже будет история цен. Если не даст - этот топик перейдёт в разряд нарушения авторских прав и прочего оффтопика. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2021, 23:06 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Злой Бобр В Price id не имеет значения можно убирать смело. Я бы не стал. Тогда надо будет использовать мало того, что естественный ключ, так еще и композитный. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 00:35 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Если не даст - этот топик перейдёт в разряд нарушения авторских прав Почему? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 00:36 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fkthatПочему? Во-первых, это может быть явно запрещено в Terms of Service. Во-вторых, если он собранные данные перерабатывает для себя - это fair use, но если он их публикует и тем более за деньги, да ещё и выдавая за своё... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 01:40 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov fkthatПочему? Во-первых, это может быть явно запрещено в Terms of Service. Во-вторых, если он собранные данные перерабатывает для себя - это fair use, но если он их публикует и тем более за деньги, да ещё и выдавая за своё... Тогда "Яндекс Маркет" и им подобные это вообще преступная банда хуже нацистов :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 01:58 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Проще у владельца сайта попросить непосредственный доступ к БД. Если даст - ничего парсить не придётся и с некоторой вероятностью там уже будет история цен. Если не даст - этот топик перейдёт в разряд нарушения авторских прав и прочего оффтопика. Спасибо конечно за совет по АПИ, но это все вообще не относится к вопросу. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 22:47 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fkthat Dimitry Sibiryakov пропущено... Во-первых, это может быть явно запрещено в Terms of Service. Во-вторых, если он собранные данные перерабатывает для себя - это fair use, но если он их публикует и тем более за деньги, да ещё и выдавая за своё... Тогда "Яндекс Маркет" и им подобные это вообще преступная банда хуже нацистов :)) Судя по тому, что на "Яндекс Маркет" есть данные далеко не по всем магазинам (в том числе и вполне известным), можно предположить, что они как раз используют данные только тех, с кем у них есть соответствующие соглашения, и, возможно, плюс тех, кто в принципе не ограничивает использование своей информации (в том-же Terms of Service) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 22:49 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Злой Бобр 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 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2021, 22:53 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
shantiom Вообще вот что я нашел на эту тему, может кому пригодится: Для сохранения такого рода данных используют Slowly_changing_dimension Цена - это ну совсем не dimension. Это стопроцентный и однозначный fact. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2021, 07:09 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
softwarer shantiom Вообще вот что я нашел на эту тему, может кому пригодится: Для сохранения такого рода данных используют Slowly_changing_dimension Цена - это ну совсем не dimension. Это стопроцентный и однозначный fact. Продажа товара, транзакция, и стоимость транзакции - это fact. Цена товара на конкретный день - это dimension. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 14:37 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
artel.dev Цена товара на конкретный день - это dimension. Если бы это была "просто цена", то было бы да, но приписка "на конкретный день" уже сама по себе указывает что это fact. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 15:11 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
artel.dev Продажа товара, транзакция, и стоимость транзакции - это fact. Да. artel.dev Цена товара на конкретный день - это dimension. Нет. Это факт, причём не связанный с фактом продажи товара. Если бы цена товара была dimension - значит, хотя бы теоретически могли бы существовать два факта (продажи товара), отличающиеся только значением этого dimension. Ты прав в том, что есть ряд сущностей, которые сами по себе являются фактом, но при этом могут выступать как измерение для другого факта. Но это - не тот случай. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 19:48 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
softwarer Если бы цена товара была dimension - значит, хотя бы теоретически могли бы существовать два факта (продажи товара), отличающиеся только значением этого dimension. это происходило, происходит и будет всегда происходить причем даже не теоретически а практически: - текущая цена в прайсе на день 1000 р - одному продали без скидки за 1000 р - другому продали со скидкой 10 % за 900 р - третьему ............................20% за 800 р А это всё не просто был один и тот же товар, это вообще один и тот же батон колбасы, половина которого до сих пор лежит на прилавке и его сегодня еще купят 5-10 покупателей не известно по какой цене... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 20:48 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
vmag это происходило, происходит и будет всегда происходить не теоретически а практически: - текущая цена в прайсе на день 1000 р - одному продали без скидки за 1000 р - другому продали со скидкой 10 % за 900 р - третьему ............................20% за 800 р Применённые скидки, категории клиентов итп. - это разные dimension-ы. И это как раз теория. Я о случае, когда один товар, одна категория клиентов, одни скидки, одна секунда - а цена разная, причём и та, и другая - названы как возможная (разные элементы dimension-а). На практике происходит другое. Текущая цена в прайсе (для этой категории покупателей, с этими скидками итп.) 1000, а продали за 990. Почему? А потому, что ценник не успели поменять, например. Или ещё по уйме причин. У меня на текущем месте работы вообще был замечательный случай. Два магазина, ну там допустим Adidas и Nike. И вот, покупатели зашли в первый, и там пока они расплачивались на кассе, ребятёнок взял поиграться маленький резиновый мячик. И они ушли. Зашли во второй, и там на кассе этот мячик заметили и пробили. А поскольку у магазинов общий владелец - мячик взял и пробился. Информация об этом ушла в общий учёт, и он маленько встал на уши. Можете помедитировать над вопросом, по какой цене он при этом пробился - из первого магазина или из второго. И вот поэтому цена - это не dimension. Это просто атрибут транзакции: товар продан по такой-то цене. За конкретную единицу получено столько-то денег. Это реальность, факт нашей жизни. Который может попадать в некий факт из "цен", а может и не попадать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 21:02 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Автор пишет - собираю для анализа. И нужна история изменения цен. Наверное копеечная точность автору не будет нужна. А будут нужны какие-то тренды. Типа - растет цена на масло за период в среднем, или падает. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 22:41 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
mayton, то, что анализируется - это тем более fact. Dimension - это разрез, в котором может производиться анализ. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 22:55 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Нам не стоит в топике обсуждать фактическую цену продажи товара. Это оффтоп и запутывает автора. Автор - парсит сайты и там будут только прайсы без фактов продаж. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 23:07 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Коллеги, вы что, угараете что ли?) Есть же стандартный подход: в таблице Price вместо поля date вводим BeginDate и EndDate и храним периоды действия цен. Если цена не менялась год - вместо 365 записей будем хранить 2. Я на собесах эту задачу на мидла задаю... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 10:25 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
mayton Автор - парсит сайты и там будут только прайсы без фактов продаж. Еще раз. Там будут прайсы товара на определенную дату . А прайс товара на определенную дату это уже fact, для которого dimensions это, например, "дата прайса", "продавец", "город продавца", "товар", "категория товара" и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 11:25 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Александр Бердышев Есть же стандартный подход Можно ссылку на этот "стандарт"? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 11:26 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fkthat mayton Автор - парсит сайты и там будут только прайсы без фактов продаж. Еще раз. Там будут прайсы товара на определенную дату . А прайс товара на определенную дату это уже fact, для которого dimensions это, например, "дата прайса", "продавец", "город продавца", "товар", "категория товара" и т.п. У нас цель поспорить, где таблица фактов, а где измерений? Постановка задачи - нужна бд для аналитики цен по товарам. ссылка на товар / цена / начало действия этой цены/ дата окончания действия этой цены. Так, как я написал - в данном случае хранить оптимальнее всего. 1. Займёт меньше места. 2. Быстрее будет работать - т.к. данные меньше весят -> меньший объём нужно читать с диска и обрабатывать 3. При такой структуре таблицы ещё и запросы удобно писать. Правда нужно будет аккуратнее подходить к индексам - если запросы будут с аналитикой за период. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 16:16 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 16:36 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
maytonЕсть специальные структуры данных для темпоральных сведений в таблицах Но в данном случае они не подходят, поскольку считают периодом срок от DML до DML и им невозможно указать требуемые значения вручную. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 16:57 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Александр Бердышев У нас цель поспорить, где таблица фактов, а где измерений? Постановка задачи - нужна бд для аналитики цен по товарам. Аналитика всегда и подразумевает использование star/snowflake схемы. Сделай какую-то другую и ты очешуеешь от тормозов запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 17:54 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Александр Бердышев ссылка на товар / цена / начало действия этой цены/ дата окончания действия этой цены. Если данные собираются только в отдельные моменты времени в виде цены в этот момент времени, то что такое "дата начала" и "дата конца"? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 17:56 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fkthatЕсли данные собираются только в отдельные моменты времени в виде цены в этот момент времени, то что такое "дата начала" и "дата конца"? Вероятнее всего это даты, когда очередное о-grab-ление сайта интернет-магазина принесло новую цену. Не предлагаете же Вы хранить и анализировать сырые данные каждого ограбления?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 18:23 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Не предлагаете же Вы хранить и анализировать сырые данные каждого ограбления?.. Если я правильно понимаю интерес автора, то для каждого сбора сохранял бы дату/время сбора, цену сбора и разницу с ценой предыдущего сбора. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 18:40 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fkthat Александр Бердышев У нас цель поспорить, где таблица фактов, а где измерений? Постановка задачи - нужна бд для аналитики цен по товарам. Аналитика всегда и подразумевает использование star/snowflake схемы. Сделай какую-то другую и ты очешуеешь от тормозов запросов. Хотите сказать, что сохранять по записи на день - будет работать быстрее, чем то, что я предложил? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:18 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 21:22 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Александр Бердышев Есть же стандартный подход: в таблице Price вместо поля date вводим BeginDate и EndDate и храним периоды действия цен. Ага, у меня была такая структура. Но потом начинаются переоценки задним числом, конкурентные обновления и вся эта структура с грохотом наворачивается. Достаточно хранить только дату начала действия новой цены ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 00:23 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Давайте разграничим юзкейсы по технологиям. У нас есть таймсерии. И есть темпоральность. Я считаю что для данной задачи. Для задачи автора. Подходит темпоральность. Цена действует в диапазоне времён. Это может быть открытие магазина или опер-дня. И цена может отсутствовать. Не торговался товар вчера к примеру. Таймсерии тоже можно использовать но она больше применима к физике. Датчик меряет температуру. Температура - точка во времени. Вот как-то так думаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 01:15 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Шавлюк Евгенийконкурентные обновления Чтобы нарваться на конкурентные обновления надо чтобы два человека одновременно (плюс-минус время транзакции) изменили цену одного и того же товара в одном и том же временном диапазоне. Это у тебя люди были такие шустрые или транзакции такие долгие? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 01:22 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
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/ Подключай да смотри всё красиво. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 01:53 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Возможна ситуация когда сначала вводят накладную с новой ценой, затем понимают что ошиблись датой и меняют ее. В этом случае цена может разорвать один диапазон и появится в другом. Ситуация конкурентности крайне редкая, но она возникает. Есть товар цена установлена с 01.12.2021 по 01.01.2100 (макс. дата). Далее вводят 2 документа с 19.12 и 20.12 Оба этих документа по отдельности разрывают предыдущий диапазон на 2. И вот в случае одновременного сохранения документов получаем проблему. Следующая проблема если один из документов удаляется. То интервалы теперь надо "склеить". Такой запрос намного проще Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 02:11 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Шавлюк Евгений, Не Дмитрий, но вклинюсь. По поводу: авторВозможна ситуация когда сначала вводят накладную с новой ценой, затем понимают что ошиблись датой и меняют ее. В этом случае цена может разорвать один диапазон и появится в другом. Разве любое изменение не должно фиксироваться?, а исправление ошибок выполняется "корректирующей проводкой", чтобы было видно, кто ввёл ошибочные данные и почему тонну "золота" с 8:22 по 8:26 отгрузили/продали по 1000$, а должны были по 2000$. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 02:31 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Шавлюк Евгений Но потом начинаются переоценки задним числом, конкурентные обновления и вся эта структура с грохотом наворачивается. Это уже зависит от рук. Шавлюк Евгений Достаточно хранить только дату начала действия новой цены Во-первых, недостаточно. "Дата начала действия новой цены" при возможности ввода задним числом не позволит знать, что в некоторый период действия цены не было. Во-вторых же, структура начало-конец позволяет писать более простые синтаксически и при этом более эффективно выполняющиеся запросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 02:44 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Шавлюк Евгений Возможна ситуация когда сначала вводят накладную с новой ценой, затем понимают что ошиблись датой и меняют ее. В этом случае цена может разорвать один диапазон и появится в другом. Это ровно то, о чём я говорил здесь: 22411584 Ошибка в том, что цена из накладной вообще пытается что-то "разрывать". Это просто атрибут транзакции, это не dimension, и это значение не должен лезть за пределы своей операции. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 02:50 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Александр Бердышев Коллеги, вы что, угараете что ли?) Есть же стандартный подход: в таблице Price вместо поля date вводим BeginDate и EndDate и храним периоды действия цен. Если цена не менялась год - вместо 365 записей будем хранить 2. Я на собесах эту задачу на мидла задаю... Ваш стандартный подход очень смело обощается на задачу топикстартера. А в задаче сказано - "сбор 2-3 раза в неделю", т.е. нам не известно каково было значение между этими сборами, и поэтому расширение даты сбора до каких-то других дат - это некоторое натягивание совы на глобус, изображаем в базе некие обобщения которые не факт что соответствуют истине. Если мы снимали данные 1и 10 числа, и данные совпали, то это не значит что в промежутке цена не такая же. Она там NULL. Такой подход позволит иметь в базе записи про реальные факты, когда мы реально фиксировали имеющиеся в инет-магазине цены. В промежутке между считывания цены могли скакать как угодно, мы эти факты никак не фиксировали. А вот потом уже, при обработке этих данных можно делать всякие обобщения и допущения, что бы попытаться из имеющихся данных увидеть какие-то тренды. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2021, 20:22 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2021, 21:19 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fraksт.е. нам не известно каково было значение между этими сборами Если бы аффтару были интересны краткосрочные колебания цен, он, натурально, поднял бы частоту их сбора. Раз он этого не делает, значит они (колебания) могут быть проигнорированы любым способом. Например, сглаживанием или интерполяцией. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2021, 21:30 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov fraksт.е. нам не известно каково было значение между этими сборами Если бы аффтару были интересны краткосрочные колебания цен, он, натурально, поднял бы частоту их сбора. Раз он этого не делает, значит они (колебания) могут быть проигнорированы любым способом. Например, сглаживанием или интерполяцией. Могут быть проигнорированы. При обработке данных. А речь идет про то что мы потратили ресурсы на сбор данных, но уже на этапе сохранения данных часть из них потеряли без возможности восстановления. Например, было кратковременное отклонение цен. Зная дату и имея это в сохраненных данных можно делать выводы - мы это не увидели по причине того что не попали датой сбора в этот пик, или мы датой таки попали, но в этом магазине пика и не было. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2021, 21:49 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Тут кто, как понял автора. На мой взгляд это:
На мой взгляд задача 100% timeseries, т.к. мы не знаем точное время обновления и применения, окончания прайса. Возможно вообще нет смысла хранить сырые данные, а считать сразу агрегат/потоковой обработкой (со сглаживанием, интерполяцией), т.к. акция может быть из разряда: HabrУ меня вот бизнес часто хочет что-то типа «всем зайчикам, проживающим в одной хатке с бобриками, с 3 до 5 утра по их таймзоне, давать скидку на морковку зеленого цвета, в 10 долларов в рублях по текущему курсу, если морковку сажали беременные белочки, и грядки были не далее 10 км от речки». ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2021, 23:39 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Bsplesk Возможно вообще нет смысла хранить сырые данные, а считать сразу агрегат/потоковой обработкой (со сглаживанием, интерполяцией), т.к. акция может быть из разряда: Имеет смысл сначала сохранять сырые данные, а потом отдельным процессом их обсчитывать и складывать в удобную для потребления схему (т.е. то что во "взрослых" системах называется ETL). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2021, 23:48 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fkthat, У нас есть требования: СУБД - Postgresql (для него есть расширения прим. PipelineDB хранит только результат потоковых вычислений). Сырые данные могут занимать много места, а это затраты на их хранение. Не каждому бизнесу нужны сырые данные, чтобы потом их крутить в условном "PowerBI" и искать закономерности, т.к. данных может быть слишком мало и основные моменты понятны и известны без всякого "machine learning". С сырыми, конечно, лучше т.к. например легко даст картину, что магазин X в субботу и воскресенье даёт скидку 10%, а вот с "зайчиками" уже будет сложней и если данных нет, то ты хоть ужом извернись, но понять никак. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 00:03 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Давайте еще раз вернемся к 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 новых строк по изменениям цен в наихудшем случае. Если инфляция какая-то. А так - цены не будут часто менятся. Старую темпоральную запись можно просто не трогать. Вот такая вот слабенькая система выходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:01 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Bsplesk fkthat, ... Сырые данные могут занимать много места, а это затраты на их хранение. авторизменения цен на товары в интернет магазинE. То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч. Потом эти данные хочу сохранить в БД для последующего анализа. У автора заявлено в магазинЕ а не магазинаХ. 3 раза в неделю на нескольких тысячах товаров - смешные объемы данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:02 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov fraksт.е. нам не известно каково было значение между этими сборами Если бы аффтару были интересны краткосрочные колебания цен, он, натурально, поднял бы частоту их сбора. Интернет-магазины борятся с такими сборщиками т.к. они создают значительную нагрузку на хостинге. Посему увеличить частоту сбора может тупо не получиться - забанят. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:05 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Я никогда не писал скрейперов за которые-бы кто-то заплатил денег. Но если-бы писал - то наверное создавал бы деликатную нагрузку с паузами и работал - бы через 100 проксей. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:12 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fraksПосему увеличить частоту сбора может тупо не получиться - забанят. Что и возвращает нас к 22408690 Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:22 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov fraksПосему увеличить частоту сбора может тупо не получиться - забанят. Что и возвращает нас к 22408690 Как это нарушает авторские права мне непонятно. Интернет-магазин - публичное пространство, кто угодно может смотреть там инфу. А вот попросить дать инфу у владельца сайта - вполне может прокатить. Если у них есть разработчики или внятная техподдержка. Доступа к БД конечно не дадут, но выгрузку вполне могут дать, что бы им сайт не дрючили парсером :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:42 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
fraks Доступа к БД конечно не дадут, но выгрузку вполне могут дать, что бы им сайт не дрючили парсером :) Лучше дать доступы к зеркалу исторических данных. Хоть в CSV, хоть в JSON. Это всяко лучше чем роботы будут дрючить html с пагинацией на 100500 страниц с дизайном. Вот лет 15 назад была такая практика что например университеты имели свои сайты типа www.univercity.org и такие-же публичные ftp ресурсы в домене типа ftp.univer.org. Всё открыто для анонимоса. Заходи. Качай хоть закачайся. Научные работы кафедры. Всякое файло-барахло. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 01:51 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
mayton, Тут у всех позиция разная. В большинстве случаев никто, ничего просто так = бесплатно не даст (тем более исторические данные). Более умные предоставляют api с минимум информации (только та, что и так на сайте оф. открыта, а не, которую удалось выудить через "кривой запрос"). На api также будет ограничение, но работать будет удобнее, но без "вкусняшек". Тоесть только для того чтобы разгрузить сайт поставщику. В большинстве ставят защиты, чтобы scraping стал невыгодным . Proxy стоят денег, как и работа + меняют артикулы или их формат, описание, в прежние "теги" подставляют фейковые данные (сразу и не поймешь, что тебя дурят, допустим просто мешают артикулы), вводят персональные, фантомные скидки и.т.д., что ручками замучаешься всё перемапливать и вычищать, чтобы сохранить историчность. Пара таких "финтов" и в БД будет помойка, которую разбирать только нейросетями. В конкурентной среде, где торгуют одним и тем же Г. все методы хороши, в том числе доходит даже до пром. шпионажа. При 15000 в месяц (180000/год) вообще не ясно зачем автору БД. Excel поддерживает 1048576 строк. Сделать годовую ротацию и сохранять, как csv файлик, крутить сразу можно в памяти в Excel PowerQuery или аналогичном туле. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 03:13 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Как-то давным-давно, сайт конторы в которой я работал, точно так же дрючили парсером. Причем там было хуже, они каждую минуту все позиции пробегали. Додрючили до того, что вроде бы наши достучались до них первыми и предложили забирать напрямую XML, который у нас использовался внутри, для тех же нужд. Я к чему, можно конечно парсить, но лучше спросить, нет ли у них данных в формате данных, а не отображения. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 17:01 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
Bsplesk Сырые данные могут занимать много места, а это затраты на их хранение. Тут мы входящих не знаем. Нефункциональные требования автор не озвучивал. Может у него под БД древняя карта памяти на 256М, а может собственный ЦОД. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 17:40 |
|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#18+
три страницы споров ни о чем... shantiom Как правильно организовать хранение в БД истории изменения цен на товары в интернет магазине. То есть, собираю данные с сайта интернет-магазина, сбор 2-3 раза в неделю. Товаров несколько тысяч. У автора нет проблем со сбором информации... СОБИРАЮ - значит уже собираю и нет смысла тарахтеть попами в эту сторону... Автор мля, сохрани уже хоть как-то и через месяц поймешь чего тебе не хватает или на это укажет заказчик... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 19:58 |
|
|
start [/forum/topic.php?all=1&fid=32&tid=1539765]: |
0ms |
get settings: |
8ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
30ms |
get topic data: |
7ms |
get forum data: |
1ms |
get page messages: |
928ms |
get tp. blocked users: |
1ms |
others: | 353ms |
total: | 1335ms |
0 / 0 |