Очистить цены

1. triviumfan 93 21.06.18 08:56 Сейчас в теме
Доброго дня, коллеги!

Стоит вопрос по очистке регистра цен.
Начальные данные задачи
Регистр сведений "Цены", подчинен регистратору, набор измерений ТипЦен, Номенклатура, ХарактеристикаНоменклатуры, ЕдиницаИзмерения, ПодразделениеКомпании, Контрагент.
Количество записей: 53кк
Размер таблицы: 35гб (из них индексы этой таблицы 27гб) плюс сам документ 14 гигов, при том, что размер базы 80гб.

Что нужно сделать
Было решено оставить последнюю цену (разумеется, в разрезе групп измерений) и удалить все имеющиеся с 2008 года.

Вопрос к знатокам - как правильно методически выполнить сию задачу?
Сейчас у меня кроме как создать обработку на создание документа "изменение цен" с последним срезом цен (на текущую дату) и удалить все старые записи (правда ещё стоит вопрос, как это делать... уж точно не средствами 1с).
Просьба помочь, пнуть в нужную сторону, дать совет...
Прикрепленные файлы:
По теме из базы знаний
Вознаграждение за ответ
Показать полностью
Найденные решения
3. Synoecium 779 21.06.18 09:09 Сейчас в теме +0.5 $m
ну я бы выгрузил срез последних в файл или в отдельную таблицу, затем средствами SQL выполнил Truncate table для таблицы регистра(выполняется мгновенно), затем залил бы срез последних назад. Время выполнения в общем будет зависеть от того, насколько большая у вас таблица со срезом последних
28. Alexander.Shvets 222 21.06.18 12:44 Сейчас в теме +0.5 $m
Ну, мое решение вам не понравится. База была на 1,2 ТБ. Так что об выборке "в 1с" в принципе не может идти речь.

В сиквеле получил срез последних (max по дате) и left join этой же таблицы. Все что null - delete.
По факту, в 1с, у проведенных старых доках просто исчезли движения.

Сами документы уже не удалял (оставил как историю для запросов), проведенный документ без движений - значит "история". Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE

Если же нужно сохранить эти данные, делаем бекап "всей" базы и складываем на полочку.

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

upd. И да, данное "варварство" ведет к проблемам с "срез первых". При попытке получить срез - в лучшем случае скуль отматерит вас по полной, дай бог что бы не сошел с ума =))). Я не пользуюсь данным срезом, посему не заморачивался.
Остальные ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
12. Dream_kz 129 21.06.18 09:34 Сейчас в теме
(1) Какая конфигурация?
С вводом среза последних проблем по идее быть не должно, можно взять типовую свертку, она введет остатки через КорректировкуЗаписейРегистров(в зависимости от конфы свой служебный документ)
С удалением сложнее, лучше конечно средствами 1С, например в несколько потоков очищать наборы записей по регистраторам (по идее пересечения быть не должно), а потом и сами регистраторы удалять.
Если скулем, удалить таблицу, создать заново, через выгрузкузагрузкуxml загрузить документ по переносу цен (но это так, теория, на практике я такое не делал)

з.Ы Какой обработкой размеры таблиц смотрели?
20. triviumfan 93 21.06.18 10:24 Сейчас в теме
(12) о какой типово свертке идёт речь? конфа "альфа-авто"...
смотрел отчетом "размер таблиц баз данных" (с ИС скачивал), он делает прямые запросы, так что данные корректны.
24. Dream_kz 129 21.06.18 11:18 Сейчас в теме
(20)
о какой типово свертке идёт речь?

Стандартная обработка для свертки типовых конфигураций, по-моему на ИТС была

(23)
1с даже не хочет вернуть мне результат

Тогда имеет смысл наложить отборы по типу цен и номенклатуре и дергать все это пачками, селективность будет выше
2. triviumfan 93 21.06.18 09:02 Сейчас в теме
ЗЫ: Запрос типа
ВЫБРАТЬ
	КОЛИЧЕСТВО(*) КАК Поле1
ИЗ
	РегистрСведений.Цены КАК Цены

Либо повиснет, либо выполнится за минуту, что не может не настораживать)
3. Synoecium 779 21.06.18 09:09 Сейчас в теме +0.5 $m
ну я бы выгрузил срез последних в файл или в отдельную таблицу, затем средствами SQL выполнил Truncate table для таблицы регистра(выполняется мгновенно), затем залил бы срез последних назад. Время выполнения в общем будет зависеть от того, насколько большая у вас таблица со срезом последних
4. triviumfan 93 21.06.18 09:14 Сейчас в теме
(3) вы не учитываете регистратор и индекс регистратор+номерстроки.
единственное, что я понял из ваших слов, то можно временную таблицу запилить со срезом, и на основании её создать средствами 1с документы "изменение цен".
5. Synoecium 779 21.06.18 09:15 Сейчас в теме
(4) индексы всегда можно пересчитать, регистратор надо вытаскивать при получении таблицы со срезом последних, это ваша задача их учесть)
имею ввиду регистратор можно оставить старый, тогда не нужен будет новый документ изменения цен. Если же будете делать через новый документ, то еще проще - регистратор заполнится автоматически при проведении документа
6. triviumfan 93 21.06.18 09:20 Сейчас в теме
(5) Срез с регистратором... что же это получится такое =)
7. Synoecium 779 21.06.18 09:22 Сейчас в теме
(6) собсна вот, вполне рабочий запрос
ВЫБРАТЬ
	ЦеныНоменклатурыСрезПоследних.Период,
	ЦеныНоменклатурыСрезПоследних.Регистратор,
	ЦеныНоменклатурыСрезПоследних.НомерСтроки,
	ЦеныНоменклатурыСрезПоследних.Активность,
	ЦеныНоменклатурыСрезПоследних.ТипЦен,
	ЦеныНоменклатурыСрезПоследних.Номенклатура,
	ЦеныНоменклатурыСрезПоследних.ХарактеристикаНоменклатуры,
	ЦеныНоменклатурыСрезПоследних.Валюта,
	ЦеныНоменклатурыСрезПоследних.Цена,
	ЦеныНоменклатурыСрезПоследних.ЕдиницаИзмерения,
	ЦеныНоменклатурыСрезПоследних.ПроцентСкидкиНаценки,
	ЦеныНоменклатурыСрезПоследних.СпособРасчетаЦены
ИЗ
	РегистрСведений.ЦеныНоменклатуры.СрезПоследних КАК ЦеныНоменклатурыСрезПоследних
Показать
9. triviumfan 93 21.06.18 09:29 Сейчас в теме
(7) В моем случае он будет выполняться бесконечность, плюс боюсь предположить размер этого среза...
ВЫБРАТЬ
	ЦеныСрезПоследних.ТипЦен,
	ЦеныСрезПоследних.Номенклатура,
	ЦеныСрезПоследних.ХарактеристикаНоменклатуры,
	ЦеныСрезПоследних.ЕдиницаИзмерения,
	ЦеныСрезПоследних.ПодразделениеКомпании,
	ЦеныСрезПоследних.Контрагент,
	ЦеныСрезПоследних.Цена
ИЗ
	РегистрСведений.Цены.СрезПоследних КАК ЦеныСрезПоследних
Показать

Уже 30 минут жду... а если ещё и по регистратору... даже страшно.
14. Synoecium 779 21.06.18 09:42 Сейчас в теме
(9) срез последних немного по-другому работает, он дает срез на комбинацию всех измерений регистра + период и регистратор (неважно, все или не все измерения выведены в запросе). Остальные поля побочные, просто берутся те значения, которые соответствуют ключу записи.
22. triviumfan 93 21.06.18 10:31 Сейчас в теме
(9) Запрос типа среза последних с разворотом по типу цен, подразделению, контрагенту, единице измерений и номенклатуре выдал 4.5кк записей.
Боюсь, с регистратором их будет... в разы больше.
Прикрепленные файлы:
8. Artem1995amyr 21.06.18 09:29 Сейчас в теме
Я бы сделал срез баз через конвертацию перенес бы данные за последние три года в новую конфигурацию (Ту же самою только пустую) а все старое на жесткий и в архив)
10. triviumfan 93 21.06.18 09:30 Сейчас в теме
(8)
срез баз через конвертацию

Можно поподробней? Боюсь, это самое долгое у худшее решение.
11. ranis888 104 21.06.18 09:33 Сейчас в теме
А почему не создать обработку на очистку регистра сведений цены? Запросом выбираешь цены, в отбор ставишь дату
Sherdrada; +1 Ответить
15. wbazil 138 21.06.18 09:44 Сейчас в теме
(11) такая обработка с такими объемами будет работать много много часов :(
16. ranis888 104 21.06.18 09:47 Сейчас в теме
(15) ну если у них сервер или терминал слабый, то да
17. triviumfan 93 21.06.18 09:48 Сейчас в теме
(11) можно подробней логику работы обработки? сервер нормальный)
13. wbazil 138 21.06.18 09:38 Сейчас в теме
1.сделать копию базы 1+ раз
----> дальше все на копии
2.создать документ установка цен с необходимыми ценами
3.выгрузить документ в XML
4. через SQL TRUNCATE TABLE_infoRg5011 если не сработало то delete from _infoRg5011
5. залить из XML документ установка цен и провести
6. если на копии ответственным и тебе всё нравиться
7. делать в продуктовой базе, предварительно сделав ещё 1+ копий

ЗЫ: подобным способом чистил 5 млн. налоговых
mifka186; +1 Ответить
21. Timur.V 78 21.06.18 10:24 Сейчас в теме
Самый быстрый способ - это очистка на уровне ms sql, как написал пользователь (13). Для этого нужно знать название таблицы (вы её уже знаете).
Только желательно, чтобы с базой в этот момент никто не работал.
39. Synoecium 779 27.06.18 09:08 Сейчас в теме
(13) нормально описали, но я бы заменил загрузку/выгрузку в XML на копирование средствами SQL в промежуточную таблицу, которую можно создать в отдельной базе (запрос на срез последних можно поймать трассировкой и, выполнив его, залить результат в промежуточную таблицу). Это будет во много раз быстрее, к тому же XML очень объемный формат хранения данных, под такие объемы файлы будут просто огромными.
18. triviumfan 93 21.06.18 09:54 Сейчас в теме
2.создать документ установка цен с необходимыми ценами

Можно тут подробней?)
номенклатуры 1кк, таких документов с учетом всех измерений цен будет.. думаю много) тем более ограничение на количество строк в ТЧ в 50к (вроде)
19. user633533_encantado 11 21.06.18 10:21 Сейчас в теме
Я что-то сомневаюсь что прям так долго будет работать обработка, которая распроведет все документы, кроме последнего (в котором вы укажате срез последних цен).
Можно сделать регламентное задание которое постепенно пачками распроведет документы.
23. triviumfan 93 21.06.18 10:39 Сейчас в теме
1с даже не хочет вернуть мне результат, о какой обработке может идти речь.
Запрос типа (учет характеристик не ведётся)
ВЫБРАТЬ
	ЦеныСрезПоследних.ТипЦен,
	ЦеныСрезПоследних.Номенклатура,
	ЦеныСрезПоследних.ЕдиницаИзмерения,
	ЦеныСрезПоследних.ПодразделениеКомпании,
	ЦеныСрезПоследних.Контрагент,
	ЦеныСрезПоследних.Цена
ИЗ
	РегистрСведений.Цены.СрезПоследних КАК ЦеныСрезПоследних
Показать

тупо виснет
смотрю в профайлер:
SEL ECT
T1.Fld5012RRef,
T1.Fld5013RRef,
T1.Fld6523RRef,
T1.Fld6524RRef,
T1.Fld6525RRef,
T1.Fld5014RRef,
T1.Fld5015_
FR OM (SEL ECT
T6._Fld6524RRef AS Fld6524RRef,
T6._Fld6523RRef AS Fld6523RRef,
T6._Fld5013RRef AS Fld5013RRef,
T6._Fld6525RRef AS Fld6525RRef,
T6._Fld5015 AS Fld5015_,
T6._Fld5012RRef AS Fld5012RRef,
T6._Fld5014RRef AS Fld5014RRef
FR OM (SEL ECT
T3.Fld5012RRef AS Fld5012RRef,
T3.Fld5013RRef AS Fld5013RRef,
T3.Fld6523RRef AS Fld6523RRef,
T3.Fld6524RRef AS Fld6524RRef,
T3.Fld6525RRef AS Fld6525RRef,
T3.Fld5014RRef AS Fld5014RRef,
T3.MAXPERIOD_ AS MAXPERIOD_,
SUBSTRING(MAX(T5._RecorderTRef + T5._RecorderRRef),1,4) AS MAXRECORDERTRef,
SUBSTRING(MAX(T5._RecorderTRef + T5._RecorderRRef),5,16) AS MAXRECORDERRRef
FROM (SELECT
T4._Fld5012RRef AS Fld5012RRef,
T4._Fld5013RRef AS Fld5013RRef,
T4._Fld6523RRef AS Fld6523RRef,
T4._Fld6524RRef AS Fld6524RRef,
T4._Fld6525RRef AS Fld6525RRef,
T4._Fld5014RRef AS Fld5014RRef,
MAX(T4._Period) AS MAXPERIOD_
FR OM dbo._InfoRg5011 T4 WITH(NOLOCK)
WH ERE T4._Active = 0x01
GROUP BY T4._Fld5012RRef,
T4._Fld5013RRef,
T4._Fld6523RRef,
T4._Fld6524RRef,
T4._Fld6525RRef,
T4._Fld5014RRef) T3
INNER JOIN dbo._InfoRg5011 T5 WITH(NOLOCK)
ON T3.Fld5012RRef = T5._Fld5012RRef AND T3.Fld5013RRef = T5._Fld5013RRef AND T3.Fld6523RRef = T5._Fld6523RRef AND T3.Fld6524RRef = T5._Fld6524RRef AND T3.Fld6525RRef = T5._Fld6525RRef AND T3.Fld5014RRef = T5._Fld5014RRef AND T3.MAXPERIOD_ = T5._Period
WH ERE T5._Active = 0x01
GROUP BY T3.Fld5012RRef,
T3.Fld5013RRef,
T3.Fld6523RRef,
T3.Fld6524RRef,
T3.Fld6525RRef,
T3.Fld5014RRef,
T3.MAXPERIOD_) T2
INNER JOIN dbo._InfoRg5011 T6 WITH(NOLOCK)
ON T2.Fld5012RRef = T6._Fld5012RRef AND T2.Fld5013RRef = T6._Fld5013RRef AND T2.Fld6523RRef = T6._Fld6523RRef AND T2.Fld6524RRef = T6._Fld6524RRef AND T2.Fld6525RRef = T6._Fld6525RRef AND T2.Fld5014RRef = T6._Fld5014RRef AND T2.MAXPERIOD_ = T6._Period AND T2.MAXRECORDERTRef = T6._RecorderTRef AND T2.MAXRECORDERRRef = T6._RecorderRRef) T1
Показать

Пришлось переписать:
select
t1._Fld6524RRef,
t1._Fld5014RRef,
t1._Fld5013RRef,
t1._Fld6525RRef,
t1._Fld5012RRef,
t1._Fld5015
fr om
_InfoRg5011 as t1
inner join
(
select
_Fld6524RRef,
_Fld5014RRef,
_Fld5013RRef,
_Fld6525RRef,
_Fld5012RRef,
MAX(_Period) as _Period
fr om  
_InfoRg5011
group by 
_Fld6524RRef,
_Fld5014RRef,
_Fld5013RRef,
_Fld6525RRef,
_Fld5012RRef
) as t2
on t1._Fld6524RRef = t2._Fld6524RRef
and t1._Fld5014RRef = t2._Fld5014RRef
and t1._Fld5013RRef = t2._Fld5013RRef
and t1._Fld6525RRef = t2._Fld6525RRef
and t1._Fld5012RRef = t2._Fld5012RRef
and t1._Period = t2._Period
Показать

этот за 16 минут выдал результат...
Боюсь, что только средствами 1с эту задачу не решить.
Буду пробовать сохранить этот результат (в файл или вспомогательную таблицу) и создать на основании полученного среза новые документы "Изменение цен".
25. wbazil 138 21.06.18 11:44 Сейчас в теме
(23) 1с даже не хочет вернуть мне результат

думаю скорее всего она не может вывести результат в консоль, а не выбрать
26. triviumfan 93 21.06.18 12:13 Сейчас в теме
(25) нет, я и прямой запрос пробовал - sql ругнулся, забыл ошибку. Вроде с ожиданием что-то.
27. wbazil 138 21.06.18 12:20 Сейчас в теме
регламентные работы на базе сделаны
28. Alexander.Shvets 222 21.06.18 12:44 Сейчас в теме +0.5 $m
Ну, мое решение вам не понравится. База была на 1,2 ТБ. Так что об выборке "в 1с" в принципе не может идти речь.

В сиквеле получил срез последних (max по дате) и left join этой же таблицы. Все что null - delete.
По факту, в 1с, у проведенных старых доках просто исчезли движения.

Сами документы уже не удалял (оставил как историю для запросов), проведенный документ без движений - значит "история". Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE

Если же нужно сохранить эти данные, делаем бекап "всей" базы и складываем на полочку.

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

upd. И да, данное "варварство" ведет к проблемам с "срез первых". При попытке получить срез - в лучшем случае скуль отматерит вас по полной, дай бог что бы не сошел с ума =))). Я не пользуюсь данным срезом, посему не заморачивался.
29. triviumfan 93 21.06.18 12:56 Сейчас в теме
(28)
Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE

тогда наверное таблица тч регистратора? ведь может быть документ с 50к строк, и по всем удалены движения, кроме одной)
И да, данное "варварство" ведет к проблемам с "срез первых"

А можно поподробней? отчего это
30. Alexander.Shvets 222 21.06.18 13:16 Сейчас в теме
(29)
а наверное таблица тч регистратора

угу, очепятка, но таблицу доков с пустыми строками все равно тогда удалять 3-м этапом. + с номерами строк все "поедет". Хз надо ли.
.
(29)
ведь может быть документ с 50к строк, и по всем удалены движения, кроме одной

для первого запроса - нет необходимости, если надо очищать доки - делайте это вторым этапом

Вам бы забыть про документ как объект и про его ТЧ, он вам не нужен. Все запросы строятся по регистрам ведь. Оптимизация размера табл дока практически ни на что не влияет (кроме места)
Если он перепроведется руками - запись по всем товарам "восстановиться".

У вас есть регистр цен, с которым и надо работать.

регистратор1|товар1|цена|период3
регистратор1|товар2|цена|период2
регистратор2|товар1|цена|период1
регистратор2|товар2|цена|период4
регистратор2|товар3|цена|период5


Из данной табл получаем MAX по периоду и товару

товар1|период3
товар2|период4
товар3|период5

Соединяем эту таблицу с основной, получаем

регистратор1|товар1|цена|период3- товар1
регистратор1|товар2|цена|период2 - null
регистратор2|товар1|цена|период1 - null
регистратор2|товар2|цена|период4 - товар2
регистратор2|товар3|цена|период5 - товар3

Как по мне - ничего страшного, если документ 50 записей, а движений только 1.
Если хотите заморачиваться - пишите доп запрос, по очистке ТЧ документа.

В нашем случае это регистратор1, у которого в тч только 1 актуальный товар "товар1".

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

(29)
А можно поподробней? отчего это

Срез первых как и срез последних - виртуальная таблица, которая хранит только актуальные правилу строки. А что будет, если запись среза есть, а этих строк не найдется в реальной таблице? Правильно, исключение, которое может быть не обработано 1с интерпретатором.

Соответственно таблицы индексов ([_InfoRgхххх_ByPeriod],[_InfoRgхххх_ххххх]) надо будет переформировать.
31. Alexander.Shvets 222 21.06.18 14:04 Сейчас в теме
(30) Вот вам sql запрос, как пища для рассуждений.

 
Select TOP 5 Tbl._Period, Tbl.[_Fld904RRef], Tbl.[_Fld942RRef],  TblGroup._Period Fr om _InfoRg876 as Tbl
left join (select max(_Period) as _Period, _Fld904RRef, _Fld942RRef Fr om _InfoRg876  
group by _Fld904RRef, _Fld942RRef ) as TblGroup
on Tbl._Period = TblGroup._Period and Tbl._Fld904RRef = TblGroup._Fld904RRef  and Tbl._Fld942RRef = TblGroup._Fld942RRef 
where  TblGroup._Period is null
order by Tbl._Period DESC
38. triviumfan 93 22.06.18 22:47 Сейчас в теме
(30)
1. Создал копию регистра в конфигураторе (со всеми регистраторами).
2. Получил срез (выбрать * из регистрсведений.цены) и залил его в копию.
3. trunc table таблицацен
4. залил в исходную таблицу цен полученный срез из копии.
5. удалил все регистраторы, у которых не оказалось движений
6. удалил все строки табличной части товаров, у которых не осталось ссылок на основную таблицу.

В итоге база увеличилась (на 20 гб, стала аж 100 гб!) после delete table. Ломал голову, а оказалось журнал превысил размеры базы, сжал его и уаля.
Размер базы уменьшился ровно в 2 раза. Профит.
40. Synoecium 779 27.06.18 10:54 Сейчас в теме
(38) из любопытства, сколько времени заняла загрузка/выгрузка в копию регистра? Как делали, срез последних в запросе 1с и запись через набор записей?
41. triviumfan 93 27.06.18 11:44 Сейчас в теме
(40) 55кк записей цен.
Срез (выбрать * из регистрсведений.цены.срезпоследних) и "заливка" его в копию таблицы заняло 15 минут.
Удаление документов (меня интересовал лишь установка цен: 20к документов и 150кк+ строк тч) без движений заняло часа 2.
Все средствами SSMS. Боюсь, что средствами 1с вышло бы очень долго и тяжелее (пришлось бы ещё разбивать на порции).
32. roman77 332 21.06.18 14:42 Сейчас в теме
Исхожу из того, что база все-таки хоть как-то, пусть медленно, но работает. Соответственно я бы попытался обойтись средствами 1С. Но не пытался бы вычистить всё сразу, а растянул бы процесс во времени- сделал бы регламентное задание, которое поштучно снимало бы с проводки и помечало на удаление старые документы установки цен, допустим по 1 штуке в N минут, где N зависит от среднего количества строк в документах. Пусть бы работало только ночью.

А перед этим обработкой создал бы новые документы с текущими ценами. Допустим, порциями по 1000 строк в документе.
33. kudlach 12 21.06.18 14:48 Сейчас в теме
Я бы предложил такой вариант - создать документ "Установка цен номенклатуры" с датой на начало года и установленными последними действующими ценами по всем применяемым на сегодня типам цен, остальные документы пометить на удаление и удалить.
После этого штатные процедуры "дефрагментации" с базой SQL и тестирование исправление в 1С.
Все делается типовыми средствами 1С (в том числе групповой обработкой документов).
По крайней мере логику базы не нарушит - 146%.
34. kudlach 12 21.06.18 14:51 Сейчас в теме
Если единовременно средствами 1С выполняется долго - разбейте задачу по аналитике номенклатуры - или по родительским группам номенклатуры или по видам номенклатуры.
35. Radkt 21.06.18 16:59 Сейчас в теме
Взять срез последних записать в 1 или несколько установок цен номенклатуры.
Как очищать, можно грохнуть регистр в конфигурации, а потом провести последний(е) документ(ы) (ради эксперимента), Но я бы постепенно распроводил старые документы
36. Alexander.Shvets 222 22.06.18 04:04 Сейчас в теме
Друзья, вы же !!!точно понимаете, что такое 53 000 000 записей? И сколько лет будет работать штатное распроведение?

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

Это мы не берем во внимания ошибки записи (тут обменданными.запись не установишь, режим проведения так то).

Если учитывать рандомные вылеты 1с, глюки сиквела или службы 1с, попутно забивая журнал регистрации событиями, возможно, за годик справимся.
37. mad375 22.06.18 07:13 Сейчас в теме
(36)Да лан, обрабатывать по 10к штук только и всего, да, конечно дольше чем в SQL, но тем не менее...
42. Alexander.Shvets 222 03.07.18 03:46 Сейчас в теме
Если кому еще понадобиться - решение есть тут Чистим цены
triviumfan; +1 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот