Имя: Пароль:
1C
1С v8
Чтение большого количества файлов dbf ...
, ,
0 Eeeehhhh
 
03.03.21
12:09
1. Другое (поделюсь тайной) 67% (2)
2. XBase 33% (1)
3. ADO 0% (0)
4. Excel 0% (0)
Всего мнений: 3

... файлов порядка 20 тысяч в каждом порядка 10 - 15 тысяч строк.
Структура файлов одинаковая.
Что самое быстрое?
1 Eeeehhhh
 
03.03.21
12:22
GameWithFire?
2 МихаилМ
 
03.03.21
12:23
GameWithFire на 1с8.3 не работает
3 Eeeehhhh
 
03.03.21
12:24
(2) печаль.
4 ДенисЧ
 
03.03.21
12:30
просто прочитать? Или что-то с прочитанным сделать? ))
5 mikecool
 
03.03.21
12:36
загрузить в скуль
читать как ВИД
6 DrShad
 
03.03.21
12:40
обернуть все в фоновое задание и запустить несколько экземпляров (хоть сотню потоков)

Другое (поделюсь тайной)
7 Eeeehhhh
 
03.03.21
12:42
(6) это не проблема, прочитать файлы и сделать N фоновых заданий. Проблема в другом - нужно будет потом эти 300 млн строк загнать в РС. И тут возникнет проблема с транзакцией и потеря времени при записи. Так как вместо одного набора и общей записи в 300 млн строк мне нужно писать блоками.
8 Eeeehhhh
 
03.03.21
12:43
(4) необходимо потом данные загнать в РС. Но сейчас проблема прочитать и загнать в ТЗ. Долго. А писать блоками в РС еще дольше.
9 ДенисЧ
 
03.03.21
12:45
А что им делать в РС? Последуй умному совету из (5)
10 Mikeware
 
03.03.21
12:46
смотря что в файлах. если числа/строки - то можно попробовать и напрямую
ну и 300 мнл- "загнать в ТЗ" - тоже так себе подход. имхо, коненчно
11 Eeeehhhh
 
03.03.21
12:46
(9) маркетологи хотят получать удовольствие от работы с динамическим списком.
12 Eeeehhhh
 
03.03.21
12:47
Причем данные будут обновляться каждую ночь.
13 Eeeehhhh
 
03.03.21
12:49
(5) внешний источник данных не всегда хорошо работает в рамках динамического списка. К тому же в этих файлах будет много дублирующих строк - это убьет все возможности нормальной работы с ВИД и доставит проблемы с формированием ключа.
14 Eeeehhhh
 
03.03.21
12:50
Но идею с ВИД я попробую.
15 ДенисЧ
 
03.03.21
12:51
Открою секрет - ни один маркетолух не будет читать все 300 миллионов записей...
16 Eeeehhhh
 
03.03.21
12:52
(15) все нет, но по ключевым словам хотят получать быстро выборку данных по поставщикам\конкурентам - так работать будут с 100-200 строк.
17 МихаилМ
 
03.03.21
12:53
(8) врете. писать все равно блоками придется, тк транзакция в 300м сток - бред. при параллельной записи желательно учесть блокировки страничные.

в вашем случае быстрее всего писать сразу в субд.
18 Mikeware
 
03.03.21
12:53
(16) олап?
19 ДенисЧ
 
03.03.21
12:55
(16) Запрос. Или Олап - любой.
20 Eeeehhhh
 
03.03.21
12:55
(18) с кубами вряд ли они захотят и смогут работать. Задача простая им нужна общая таблица с которой они будут работать из 1С при анализ цен по тем или иным позициям.
(19) запрос как и олап у трех женщин маркетологов вызовет ступор.
21 Mikeware
 
03.03.21
12:58
(20) да фигли там работать-то? ты их создай...
меня до сих пор достают просьбами "сделать в восьмерке кубики как были в семерке"...
22 ДенисЧ
 
03.03.21
12:59
(20) Сделай олап и выведи его в екселЬ. 10 минут обучения и оргазм у "трех женщин маркетологов" обеспечен...
23 ДенисЧ
 
03.03.21
12:59
(21) А в семерке были кубики? О_О
24 mistеr
 
03.03.21
12:59
(16) >работать будут с 100-200 строк

Вот и загружай им эти 200 строк из скуля по запросу.
25 mistеr
 
03.03.21
13:00
Но на будущее есть смысл обучить их простейшим навыкам в консоли отчетов.
26 Eeeehhhh
 
03.03.21
13:00
(24) хотят видеть все и строить отборы в реальном времени без промежуточных нажатий.
27 Eeeehhhh
 
03.03.21
13:00
(23) у меня были 0
28 Mikeware
 
03.03.21
13:02
(23) у меня были. да и не только у меня...
29 mistеr
 
03.03.21
13:02
(26) Когда увидят в ДС 300 млн, пойдут хотелки "уберите лишнее". Ты что, пользователей не знаешь?
30 Йохохо
 
03.03.21
13:04
(29) так у них селективность 10е-8%
31 ДенисЧ
 
03.03.21
13:05
(29) Они не увидят. Не дождутся, пока список с 300 лямами записей откроется.
32 Eeeehhhh
 
03.03.21
13:16
(31) динамический список в 500 млн записей 15 колонок открывается мгновенно. Стандартный поиск отрабатывает пара секунд.
33 hogik
 
03.03.21
21:00
xBase. Быстрее ничего нет.

XBase
34 mikecool
 
03.03.21
21:03
я так понимаю - у Маньяка конкурент? ))
35 mikecool
 
03.03.21
21:03
(32) а почему? потому что отрисовывается 20 строк, которые считаны плюс минус по 20 строк
36 Eeeehhhh
 
03.03.21
21:42
(34) не, не. Лысый бребер вне конкуренции. Но ведь его поделки кого то интересуют. Здесь не будет универсализма. Просто хотюн заказчика.
(33) как ни странно, да. На текущий момент этот механизм самый быстрый.
37 Garykom
 
гуру
03.03.21
22:01
(0)
1. Не надо это грузить в 1С
из этого логично вытекает
2. Внешняя СУБД, например mssql или postgresql или sqlite
3. 1С делает запросы к внешней БД, причем через ВК для скорости
38 Garykom
 
гуру
03.03.21
22:02
Если очень хочется засунуть в РС в 1С то серверная база на MSSQL, делаешь ручками пару записей РС, смотришь как оно прямыми запросами в MSSQL и туда напрямую
39 Garykom
 
гуру
03.03.21
22:03
(38) это

Другое (поделюсь тайной)
40 Кирпич
 
03.03.21
22:27
Читать способов много. Пихать всё это в 1с не надо. Сделать отдельную БД на SQLite или на чём хош. Грузить программой на чем нибудь компилируемом (C#, C, Pascal, чо умеешь). Такое за пару часов управится. Но лучше на 1с. Неделю будет грузить + измученное страданиями лицо. Больше денег дадут.
41 hogik
 
04.03.21
03:50
(36)
«как ни странно, да. На текущий момент этот механизм самый быстрый.»(с)
Ничего странного. :-) Ведь все инструменты работы с DBF базируются на «теории» xBase и его библиотеках.
42 Eeeehhhh
 
04.03.21
10:33
(41) всю жизнь считал, что ADO без конкуренции )))
(37)(40) да, да. 1С плохая не справится. Буду изобретать велосипед на 100 часов с ВК и дальнейшим гемороемв сопровождении. Вышло даже больше 750 млн строк в РС залетели за ~30 минут идентификацией номенклатуры и контрагента. Стандартный поиск подтормаживает, но 15 секунд на отбор это ни о чем. А через настройку списка так вообще мгновенно.
43 Кирпич
 
04.03.21
17:43
(42) нифига у вас железо. 750 млн за 30 минут...
44 Kassern
 
04.03.21
17:46
(42) интересно на сколько база распухла после такой заливки?
45 Eeeehhhh
 
05.03.21
09:10
(43) каждый файл отдельным фоновым заданием, между каждыми 5 фоновыми 1 секунда паузы. На серверу по нагрузке  одновременно грузят 10-15 фоновых. Все это будет грузится каждую ночь - очищаться и перегружаться. Пока эксперимент что будет как будет работаться копией в многопользовательском режиме - если выдержит 3-4 пользователей с их хотюнами - оставим в таком режиме - нет. Все ж таки придется думать что то типа OLAP.
(44) не сильно MS SQL говорит, что таблица весит около 40 гиг, индексы в районе 15 гиг. Скорей всего уберем все поля, кроме нужных и будет меньше. Пока захотели все.
46 Почему 1С
 
05.03.21
10:10
Представляю себе накладные расходы на индексирование такой таблицы после каждой порции вставки данных
47 Почему 1С
 
05.03.21
10:14
В теории нужен способ отключить все индексы, перезаполнить таблицу, включить индексы, перестроить их.
48 Garykom
 
гуру
05.03.21
11:07
(45) Редкое извращение, не проще (38) сделать?
49 Garykom
 
гуру
05.03.21
11:10
А еще лучше все же не хранить в 1С ненужные там данные
Если очень хочется то на 1С можно интерфейс для работы с этими данными и все
Который запросы к внешней базе делает, что неоднократно уже написали
OLAP тут не причем, OLAP куб это предварительный расчет разных результатов (долгий) с быстрым показом
50 Eeeehhhh
 
05.03.21
11:52
(49) вот как ты определяешь "не нужные"? Тебе не нужно, ты и не храни. Люди захотели именно так и ни как иначе. Пока их все устроило и даже согласились мирится со скоростью. Из всей структуры (24 поля) оставят всего 4 поля - таблица должна уменьшиться в размерах в разы.
51 VladZ
 
05.03.21
12:07
Внешняя база. Не вижу смысла грузить эту пургу в 1с: растет объем базы - как следствие растет время на бэкап и объем самого бэкапа (причем важной и актуальной информации там будет 10%, а остальное - неактуальная хрень, которая тупо занимает место).