powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Map
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Сохранение в БД истории данных изменения цены на товары в интернет магазине.
25 сообщений из 57, страница 2 из 3
Сохранение в БД истории данных изменения цены на товары в интернет магазине.
    #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
25 сообщений из 57, страница 2 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Сохранение в БД истории данных изменения цены на товары в интернет магазине.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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