|
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
|
|||
---|---|---|---|
#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 |
|
|
start [/forum/topic.php?fid=32&msg=40121516&tid=1539765]: |
0ms |
get settings: |
22ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
66ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
509ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 645ms |
0 / 0 |