... файлов порядка 20 тысяч в каждом порядка 10 - 15 тысяч строк.
Структура файлов одинаковая.
Что самое быстрое?

GameWithFire?

GameWithFire на 1с8.3 не работает

(2) печаль.

просто прочитать? Или что-то с прочитанным сделать? ))

загрузить в скуль
читать как ВИД

обернуть все в фоновое задание и запустить несколько экземпляров (хоть сотню потоков)

(6) это не проблема, прочитать файлы и сделать N фоновых заданий. Проблема в другом - нужно будет потом эти 300 млн строк загнать в РС. И тут возникнет проблема с транзакцией и потеря времени при записи. Так как вместо одного набора и общей записи в 300 млн строк мне нужно писать блоками.

(4) необходимо потом данные загнать в РС. Но сейчас проблема прочитать и загнать в ТЗ. Долго. А писать блоками в РС еще дольше.

А что им делать в РС? Последуй умному совету из (5)

смотря что в файлах. если числа/строки - то можно попробовать и напрямую
ну и 300 мнл- "загнать в ТЗ" - тоже так себе подход. имхо, коненчно

(9) маркетологи хотят получать удовольствие от работы с динамическим списком.

Причем данные будут обновляться каждую ночь.

(5) внешний источник данных не всегда хорошо работает в рамках динамического списка. К тому же в этих файлах будет много дублирующих строк - это убьет все возможности нормальной работы с ВИД и доставит проблемы с формированием ключа.

Но идею с ВИД я попробую.

Открою секрет - ни один маркетолух не будет читать все 300 миллионов записей...

(15) все нет, но по ключевым словам хотят получать быстро выборку данных по поставщикам\конкурентам - так работать будут с 100-200 строк.

(8) врете. писать все равно блоками придется, тк транзакция в 300м сток - бред. при параллельной записи желательно учесть блокировки страничные.

в вашем случае быстрее всего писать сразу в субд.

(16) олап?

(16) Запрос. Или Олап - любой.

(18) с кубами вряд ли они захотят и смогут работать. Задача простая им нужна общая таблица с которой они будут работать из 1С при анализ цен по тем или иным позициям.
(19) запрос как и олап у трех женщин маркетологов вызовет ступор.

(20) да фигли там работать-то? ты их создай...
меня до сих пор достают просьбами "сделать в восьмерке кубики как были в семерке"...

(20) Сделай олап и выведи его в екселЬ. 10 минут обучения и оргазм у "трех женщин маркетологов" обеспечен...

(21) А в семерке были кубики? О_О

(16) >работать будут с 100-200 строк

Вот и загружай им эти 200 строк из скуля по запросу.

Но на будущее есть смысл обучить их простейшим навыкам в консоли отчетов.

(24) хотят видеть все и строить отборы в реальном времени без промежуточных нажатий.

(23) у меня были 0

(23) у меня были. да и не только у меня...

(26) Когда увидят в ДС 300 млн, пойдут хотелки "уберите лишнее". Ты что, пользователей не знаешь?

(29) так у них селективность 10е-8%

(29) Они не увидят. Не дождутся, пока список с 300 лямами записей откроется.

(31) динамический список в 500 млн записей 15 колонок открывается мгновенно. Стандартный поиск отрабатывает пара секунд.

xBase. Быстрее ничего нет.

я так понимаю - у Маньяка конкурент? ))

(32) а почему? потому что отрисовывается 20 строк, которые считаны плюс минус по 20 строк

(34) не, не. Лысый бребер вне конкуренции. Но ведь его поделки кого то интересуют. Здесь не будет универсализма. Просто хотюн заказчика.
(33) как ни странно, да. На текущий момент этот механизм самый быстрый.

(0)
1. Не надо это грузить в 1С
из этого логично вытекает
2. Внешняя СУБД, например mssql или postgresql или sqlite
3. 1С делает запросы к внешней БД, причем через ВК для скорости

Если очень хочется засунуть в РС в 1С то серверная база на MSSQL, делаешь ручками пару записей РС, смотришь как оно прямыми запросами в MSSQL и туда напрямую

(38) это

Читать способов много. Пихать всё это в 1с не надо. Сделать отдельную БД на SQLite или на чём хош. Грузить программой на чем нибудь компилируемом (C#, C, Pascal, чо умеешь). Такое за пару часов управится. Но лучше на 1с. Неделю будет грузить + измученное страданиями лицо. Больше денег дадут.

(36)
«как ни странно, да. На текущий момент этот механизм самый быстрый.»(с)
Ничего странного. :-) Ведь все инструменты работы с DBF базируются на «теории» xBase и его библиотеках.

(41) всю жизнь считал, что ADO без конкуренции )))
(37)(40) да, да. 1С плохая не справится. Буду изобретать велосипед на 100 часов с ВК и дальнейшим гемороемв сопровождении. Вышло даже больше 750 млн строк в РС залетели за ~30 минут идентификацией номенклатуры и контрагента. Стандартный поиск подтормаживает, но 15 секунд на отбор это ни о чем. А через настройку списка так вообще мгновенно.

(42) нифига у вас железо. 750 млн за 30 минут...

(42) интересно на сколько база распухла после такой заливки?

(43) каждый файл отдельным фоновым заданием, между каждыми 5 фоновыми 1 секунда паузы. На серверу по нагрузке  одновременно грузят 10-15 фоновых. Все это будет грузится каждую ночь - очищаться и перегружаться. Пока эксперимент что будет как будет работаться копией в многопользовательском режиме - если выдержит 3-4 пользователей с их хотюнами - оставим в таком режиме - нет. Все ж таки придется думать что то типа OLAP.
(44) не сильно MS SQL говорит, что таблица весит около 40 гиг, индексы в районе 15 гиг. Скорей всего уберем все поля, кроме нужных и будет меньше. Пока захотели все.

Представляю себе накладные расходы на индексирование такой таблицы после каждой порции вставки данных

В теории нужен способ отключить все индексы, перезаполнить таблицу, включить индексы, перестроить их.

(45) Редкое извращение, не проще (38) сделать?

А еще лучше все же не хранить в 1С ненужные там данные
Если очень хочется то на 1С можно интерфейс для работы с этими данными и все
Который запросы к внешней базе делает, что неоднократно уже написали
OLAP тут не причем, OLAP куб это предварительный расчет разных результатов (долгий) с быстрым показом

(49) вот как ты определяешь "не нужные"? Тебе не нужно, ты и не храни. Люди захотели именно так и ни как иначе. Пока их все устроило и даже согласились мирится со скоростью. Из всей структуры (24 поля) оставят всего 4 поля - таблица должна уменьшиться в размерах в разы.

Внешняя база. Не вижу смысла грузить эту пургу в 1с: растет объем базы - как следствие растет время на бэкап и объем самого бэкапа (причем важной и актуальной информации там будет 10%, а остальное - неактуальная хрень, которая тупо занимает место).