Кто разрабатывал такую выгрузку. Пока остановился на CSV. Выгружаю с помощью скд, который при сохранении в текстовый формат дает csv файл. Это быстрее чем с помощью записи текста. Есть более производительные способы?

А тебе повыпендриваться или есть реальная задача, что прям надо "быстро"?

(0) Отличие от текстового формата только в расширении имени файла )))

Если БД внешняя, то тогда и пиши туда напрямую безо всяких прокладок выгрузки-загрузки.

Думаю выпендривается
Ибо выгрузка в JSON из структур/массивов быстрей

А еще быстрей банальная выгрузка в DT
Как прочитать/распаковать DT это уже отдельный вопрос

Другой вариант это прямая выгрузка из скуля

Я реализовал с помощью csv и СКД. Может есть более быстрый способ выгрузки, не считая прямого обмена с базой данных.
(3) То есть запрос к базе данных, в цикле формируется структура, затем запись в файл? Основное время тратится на создание массива(структуры) данных. В чем преимущество? Памяти сколько будет отъедать? Пока не запишешь в файл структуру память будет использоваться

Если что речь идет об отдельных таблицах. Должно выгружаться как есть, но пропускаются колонки с типом хранилище значения, но это детали. Интересует сам формат обмена

Через СУБД

(0)

Вот короткий список риторических вопросов:

Что выгружать ?
Куда выгружать ? ("та" база счастлива от CSV  ?)
Сколько выгружать ? (транспорт файл ?)
Как часто ?
Зачем выгружать ?
Нужно ли потом поддерживать/расширять этот формат выгрузки ?

Я с dBaseIII уж 15 лет...

(7) Какой самый быстрый способ выгрузки данных во внешние базы данных из 1с вы знаете? Выгружать нужно результат какого либо запроса. На данный момент я выгружаю таблицы как есть в дереве метаданных. Это все не относится к вопросу. Данных много, выгружать нужно часто. Хотя бы раз в день. Опять же повторюсь, вопрос только в том какой способ выгрузки самый производительный. Есть допустим регистр партии. Нужно выгружать его во внешнюю базу данных. Процесс загрузки во внешнюю базу не интересует с ним все понятно

CSV очень "тяжелый" формат с точки зрения преобразования данных
А так же разных неожиданных ошибок и багов

Спец его не выберет со времен появления JSON

Определить спец или нет очень легко
Скажи как ты в строках служебные символы (запятая, точка с запятой, кавычки, переносы строки и прочие непечатные) будешь?
Как будешь дата/время кодировать?
Как будешь числа с каким разделителем?
Как булево?

А средства в 1С готовые платформенные для этого есть?
А как быстро они работают?

Для JSON есть на уровне платформы...

(10)
Надо тестировать. Сделаю еще одну функцию для выгрузки в своей обработке.
Как бы ты формировал JSON. Есть запрос, что дальше?
У меня программно создается скд. Строки обрабатываются с помощью выражения представления поля. Числа и дата с помощью условного оформления, хотя тоже можно с помощью выражения представления, думаю что будет одинаково отрабатывать. По умолчанию при сохранении табличного документа в текстовый файл как раз таки создается tsv файл(разделитель табуляция)

(11) -> (4)
Сделайте замер времени без режим отладки из конфигуратора (просто пользовательский режим с сообщением о замере времени).
Должно намного быстрее сформировать JSON, чем вы замеряли.

Табличный документ тоже подтребляет ОЗУ на сервере, так что это не показатель.

Действительно с JSON-ом получается раза в 2-2.5 быстрее. Но это в том случае если запрос выгружать в таблицу значений и таблицу затем сериализовать в json и записывать файл. Немного неудобный формат получается, нужно еще разбираться как это читать. Еще быстрее раза в два это ЗначениеВФайл, выгрузить запрос в ТЗ и записать с помощью это функции. Но тогда придется создать конвертер и не факт что будет выигрываться время.

(0) ЗначениеВСтрокуВнутр если между двумя 1С

(13) Можно еще в сторону ЗаписьFastInfoset посмотреть, в версионировании БСП его используют.

(13) С точки зрения чтения, JSON намного более удобный формат, чем CSV. (см 10)

Загрузку мы добивали до 1/5 от производительнгсти дисковой подсистемы, выгрузка тоже должна быть по идее в этих же пределах

+(14) Делал результат запроса в ЗначениеВФайл(), потом этот файл преобразовывал в csv сторонней программой. Работало как пуля.

(16) JSON сложнее CSV. А чем сложнее формат, тем медленнее загрузка/выгрузка. Для тупой загрузки данных в таблицу БД, cмысла в JSON нет.

(19)К тому же json весит примерно в 10 раз больше в несжатом виде. Какой программой преобразовывали в csv

(20) "Какой программой преобразовывали в csv "
да какой. сам писал на паскале:)

Какой подход использовали для преобразования, можете подсказать? Читали построчно, разбирали строку? Как в таком случае разбирали строку, с помощью регулярных выражений или нет?

(22) да ну просто парсер. нам не сложно. Просто разобрать такую абракадабру.
{"T",4,2,"S","Code","S","Description","S","000000001","S","1 ляля","S","000000002","S","2 ббб","S","000000003","S","3 ббббб"}

любой школьник напишет или ИИ.

Все-таки использовали регулярно или посимвольный разбор?

тут же всё понятно. "T" таблица, "4,2" - четыре строки две колонки и погнали

(24) посимвольно конечно. регулярки будет медленней

да и не нужны они тут

забил это в ИИ :)

Отлично! Ты хочешь написать **парсер на Go** для разбора структуры вида:

```json
{"T",4,2,"S","Code","S","Description","S","000000001","S","1 ляля","S","000000002","S","2 ббб","S","000000003","S","3 ббббб"}
```

Это не стандартный JSON, а скорее **сериализованный массив значений**, где:
- `"T"` — тип (возможно, "Table")
- `4` и `2` — какие-то числа (например, количество строк и столбцов)
- `"S"` — указывает, что следующее значение — строка (`S` = String)

---

## 🎯 Цель

Превратить это выражение в понятную структуру, например:

```go
type ParsedData struct {
    Type     string
    Rows     int
    Columns  int
    Headers  []string
    Data     map[string]string // или []map[string]string в зависимости от формата
}
```

---

## ✅ Пример входных данных

```go
input := []interface{}{"T", 4, 2, "S", "Code", "S", "Description", "S", "000000001", "S", "1 ляля", "S", "000000002", "S", "2 ббб", "S", "000000003", "S", "3 ббббб"}
```

> Для упрощения будем считать, что входной массив уже распарсен как `[]interface{}`.

---

## 🔧 Реализация парсера

Вот готовый пример парсера на Go:

```go
package main

import (
    "fmt"
)

type ParsedData struct {
    Type     string
    Rows     int
    Columns  int
    Headers  []string       // Заголовки колонок
    Data     []map[string]string // Строки данных: ключ — заголовок, значение — значение
}

func parseCustomFormat(tokens []interface{}) (*ParsedData, error) {
    if len(tokens) < 5 {
        return nil, fmt.Errorf("слишком мало данных")
    }

    p := &ParsedData{}

    // Первое значение — тип
    if t, ok := tokens[0].(string); ok {
        p.Type = t
    } else {
        return nil, fmt.Errorf("первое значение должно быть строкой типа")
    }

    // Второе и третье — целые числа: Rows и Columns
    if r, ok := tokens[1].(int); ok {
        p.Rows = r
    } else {
        return nil, fmt.Errorf("второе значение должно быть целым числом")
    }

    if c, ok := tokens[2].(int); ok {
        p.Columns = c
    } else {
        return nil, fmt.Errorf("третье значение должно быть целым числом")
    }

    idx := 3

    // Читаем заголовки
    for i := 0; i < p.Columns && idx+1 < len(tokens); i++ {
        if s, ok := tokens[idx].(string); ok && s == "S" {
            header, ok := tokens[idx+1].(string)
            if !ok {
                return nil, fmt.Errorf("ожидалась строка для заголовка %d", i)
            }
            p.Headers = append(p.Headers, header)
            idx += 2
        } else {
            return nil, fmt.Errorf("ожидался 'S' перед заголовком")
        }
    }

    // Проверяем, что удалось прочитать все заголовки
    if len(p.Headers) != p.Columns {
        return nil, fmt.Errorf("не найдены все заголовки")
    }

    // Читаем данные
    for i := 0; i < p.Rows && idx+1 < len(tokens); i++ {
        row := make(map[string]string)
        for j := 0; j < p.Columns && idx+1 < len(tokens); j++ {
            if s, ok := tokens[idx].(string); ok && s == "S" {
                val, ok := tokens[idx+1].(string)
                if !ok {
                    return nil, fmt.Errorf("ожидалась строка для значения [%d][%d]", i, j)
                }
                row[p.Headers[j]] = val
                idx += 2
            } else {
                return nil, fmt.Errorf("ожидался 'S' перед значением [%d][%d]", i, j)
            }
        }
        p.Data = append(p.Data, row)
    }

    return p, nil
}

func main() {
    // Исходные данные в виде []interface{}
    input := []interface{}{
        "T", 4, 2, "S", "Code", "S", "Description",
        "S", "000000001", "S", "1 ляля",
        "S", "000000002", "S", "2 ббб",
        "S", "000000003", "S", "3 ббббб",
    }

    result, err := parseCustomFormat(input)
    if err != nil {
        fmt.Println("Ошибка:", err)
        return
    }

    // Вывод результата
    fmt.Printf("Тип: %s\n", result.Type)
    fmt.Printf("Строк: %d | Колонок: %d\n", result.Rows, result.Columns)
    fmt.Printf("Заголовки: %v\n", result.Headers)
    fmt.Println("Данные:")
    for _, row := range result.Data {
        fmt.Println(row)
    }
}
```

---

## 📦 Результат выполнения:

```text
Тип: T
Строк: 4 | Колонок: 2
Заголовки: [Code Description]
Данные:
map[Code:000000001 Description:1 ляля]
map[Code:000000002 Description:2 ббб]
map[Code:000000003 Description:3 ббббб]
map[Code:000000003 Description:3 ббббб] ← если rows > данных — будет повтор?
```

> ⚠️ В твоих данных только 3 строки, но указано `rows=4`. Если нужно — можно добавить проверку.

---

## ✅ Что умеет парсер:

- Парсит тип (`T`)
- Читает число строк и столбцов
- Читает заголовки по метке `"S"`
- Читает данные по строкам и привязывает к заголовкам
- Выдает результат в удобной структуре

---

## 🚀 Что можно добавить:

- Поддержку других типов, кроме `"S"` (например, `"I"` — integer, `"B"` — boolean)
- Валидацию длины данных
- Возможность сериализации обратно
- Поддержку JSON/YAML вывода

---

Если тебе нужно адаптировать это под конкретный протокол, формат или API — пиши, я помогу! 😊

ИИ конечно фигню написал, но примерный объем работ виден.

Я уже забивал в ИИ). Буду смотреть, спасибо

(30) Да на ИИ можно и не тратить время. За день сам напишешь (если конечно знаешь какой нибудь язык программирования). Если большие файлы, обязательно используй буферизацию или MMAP.

C++, есть опыт

(32) От это тебя угораздило. Неделю теперь будешь писать :)

(0) самый производительный - это репликация БД средствами скуля

(0)  если источник ms sql , cоздайте в нем линкованый сервер на приемник. И обычным select into.

Linked Server

Запрос -> ТЗ -> ЗначениеВФайл -> ВнешняяКмпонентаНаДельфи которая преобразует формат 1С в csv -> bulkinsert из csv в БД.

(34) это да, но не хотелось бы связываться с прямыми запросами, не всегда есть доступ к базе данных. (37) Тоже пришел к такому выводу. Осталось сделать конвертер

(29) ИИ написал не просто фигню а много фигни
На практике все намного проще в Go

Имхо ТС херней занимается

Если надо самый быстрый способ:
То ПолучитьСтруктуруХраненияБазыДанных() и прямые запросы

Если надо просто, удобно, гибко и достаточно быстро:
Использовать JSON в платформе 1С и не выделываться

(37) объясни нахера промежуточные шаги, когда можно сразу из СУБД запросами прямыми???

(41)+ пишется запрос на 1С, профайлером (есть ИР) ловится
напрямую исполняется в СУБД, результат в текст в удобном виде
зачем еще ВК изобретать?
или использовать официально не рекомендованный ЗначениеВФайл

(41) Грузани напрямую контрагентов в базу битрикса. А мы похохочем ...

(43) 1. Конфу не указал
2. Самому что знаний не хватает для подобного?
3. Лично я сделаю на JSON и http-сервисах. И не буду выделываться с разными CSV, ЗначениеВФайл, ЗначениеВСтрокуВнутр, внешними компонентами и прочими извратами

(42)Потому что к субд не всегда есть доступ. А если файловый вариант? JSON сложнее загружать в субд, тоже нужна прослойка, но согласен ее написать легче чем для внутреннего формата 1с(ЗначениеВФайл).

(45)

"Файловый вариант"

Сначала быстрей, быстрей -- напишем конвертер на Си,
нет -- на Си, но с asm-вставками.

А теперь оказывается выгрузка из файловой базы.

(45) к СУБД всегда есть доступ
если у тебя есть доступ в Конфигуратор, то можно выгнать всех нахрен, выгрузить в DT и загрузить ее в свою СУБД

это если разовая выгрузка-загрузка

а если постоянная - используйте стандартные общепринятые механизмы (json, http и т.д.)
и наймите спецов вместо этого нубского лепета

для bulk в СУБД есть специальные форматы
и CSV там не главный, главный sql insert

(46)Я ожидал этого сообщения. Решение должно быть универсальным. Мне не охота писать несколько вариантов - один быстрый, другой медленный третий еще какой-то

(44) как JSON и вебсервис поможет "быстро выгрузить из 1С"? Это же два галимых тормоза тормоза :)

И JSON этот по умолчанию будет в каждую строчку имена полей вставлять, что есть идиотизм. А если делать нормальный JSON, то он будет похож на CSV как однояйцевые близнецы.

(48) щас я суп доварю, сделаю тебе конвертор этот. заодно замерим у кого быстрее получится.

(0) Данных недостаточно

выгрузка одноразовая или это периодический обмен?

Таблица в плоском виде или более сложная структура?

Какие системы участвуют в обмене? Если делается внутри между базами sql , тогда зачем будут нужны файлы если можно напрямую

(34) 🤣 зато честно

если серьезно, то пост максимально не серьезный.
автор  после своего потока сознания поставил знак вопроса и спросил тут.

Вот заколбасил. Только имена полей пока тупо генерятся F1 F2 F3.... Неохота сейчас с ними возиться.
https://github.com/qxlreport/tocsv

Потестил код из (55)
На моем стремительном i7-3770 3.40GHz и SSD
гигабайтный файл в 10 млн записей из двух полей переделывает за 5 секунд
вполне себе быстренько

За какое время такую кучу сможет вывалить 1С через ЗначениеВФайл() науке пока не известно

подкрутил чтобы имена полей выводил такие же как и в запросе
кому надо, лежит здесь https://github.com/qxlreport/tocsv

Ммм тут мысля возникла
А есть возможность получить сформированную ВТ с данными в СУБД снаружи текущего сеанса?

Я к чему, делать прямые запросы это весьма трудозатратно
Но можно же слегка схитрить и подготовить временные таблички простой структуры, причем известной
А затем их банально забрать из СУБД

У меня на подходе своя версия на с++ ). (59) Скорей всего если использовать менеджер временных таблиц, то временная таблица будет существовать пока существует менеджер. Осталось узнать ее название.
В 8.3.12 таблица значений обозначается так:
{"#",acf6192e-81ca-46ef-93a6-5a6968b78663,

(50) Ну добавьте в csv данные по контрагентам, номенклатуре, организации, складу, остаткам и тд. В JSON это все проще, можно отдельной сущностью описать.

(59) => (52) проще какую-то синхронизацию с самописной БД организовать, чем от 1С плясать если нужна скорость именно выгрузки. Актуализацию данных можно организовать через регистр сведений и рег.задание. Чет видал какие-то подобные хотелки по гос.контрактам чтобы данные выгружались не более 3 сек.

(61) " В JSON это все проще, "
А загружать это потом как? SQL Server сам догадается, что в какие таблицы писать? CSV булькнул и готово

В JSON однозначно проще и гибче. При желании ваше CSV можно преобразовать в JSON. Размер при этом будет примерно одинаковый. Зато пропадут все проблемы со специальными символами и экранированием. Читать будет не медленнее.

(62) Слон позволяет гибко работать с JSON, помимо этого можно делать запросы SQL к данным файлам JSON, а не линейным таблицам как в MSSQL

Вот и моя версия на c++
https://github.com/kolts1/1c_converter/tree/main
Пока что только исходник, на данный момент нет обработки данных, то есть пишется в csv как есть. Также пока нет обработки экранированных символов, нужно разбираться.
Указываем входящий и исходящий файл.

(65) "нет обработки экранированных символов" так там уже всё 1С заэкранировал. Можно тупо копировать, что есть.

(63)(64) У вас секта какая то чтоли? JSON JSON JSON

(67) Да просто CSV уже практически никто не использует. А JSON быстрый и универсальный. Если он у тебя тормозит - значит, ты не умеешь его готовить.

(68) для каждого своя цель.
Как пример для обмена прайсами никому JSON не нужен, а прайсы не редки  1кк +- строк.

JSON - сам по себе не может быть быстрым, это механизмы его использующие оптимизированы с ним работать.

(68) CSV используют все. Не выдумывай. Особенно для загрузки во всякие PowerBI и т.п, для которых и нужна быстрая выгрузка из 1С.

(70) Все, кто не осилил более современные и удобные форматы данных. Тот же PowerBI прекрасно работает с XML.

(71) Ну тогда в какой-нибудь протобуф выгружай. Он пипец какой современный

(72) 1С умеет с ним работать на уровне платформы? Иногда голову желательно всё-таки включать.

(73) свою голову включи сначала

(67) модно, стильно, молодежно.

(75) "более современные и удобные форматы данных" :) (71)

(76) Прочитай (10) и попробуй подумать. Если не получится, перечитай ещё раз. Понятно, что для ларька, для передачи цен на овощи, вполне хватит и CSV. Но для действительно больших объемов данных, к тому же содержащие что-то сложнее, чем строки типа "Морковка - 10р.", CSV я бы не использовал.

(76) карго-культ. Желание подражать java смузихлебам.

(78) Да нет. Всего лишь опыт работы с получением больших объемов данных из различных внешних источников (не 1С). Почему-то никто не передаёт их в CSV.
Наверное, у всех крупных компаний карго-культ :))))

(68) А ничего, что csv - все еще стандарт в качестве источника для импорта данных аля bulk insert, в различных СУБД? Да даже взять финансовые аппы, везде экспорт-импорт в основном csv. Я вот буквально вчера пилил себе дома импорт из csv для ZenMoney, в 2025. Предыдущая прога тоже csv-only.
(79) Крупные компании передают в чем угодно, от csv и xls, до xml и json. Не стоит думать, что здесь все в ларьках работали всю жизнь.

(80) ZenMoney - да, это серьёзный аргумент. Все крупные компании только её и используют. Например, Газпром, РЖД и прочие - всю финотчетность только в ZenMoney ведут. :)))

(80) "Крупные компании передают в чем угодно, от csv и xls, до xml и json."

Ну вот давненько я не встречал передачи больших объемов данных от крупных компаний в csv, хотя работаю с ними постоянно. Но вы продолжайте теоретизировать.

(78) смузихлёбы тоже уже подозревают, что гонять JSON между сервисами очень накладно

(83) "большие" объемы получаются из-за xml. Но можно же просто на ночь запустить и нормально. Правда?

(81) Смешно смотритесь. Мне кажется, прямо сейчас вы с "Газпромом" не работаете. )
Ну давайте без шутовства все-таки, меряться тут, кто с кем работал... Какая капитализация и сравнить с нынешней капитализацией Газпрома (я рад, что не акционер оного ныне). Честно - наплевать в чем там у них отчетность, мне важнее мой дашборд на ZenMoney сделать. csv-один из наиболее распространенных форматов и это факт, а если религия не позволяет с ним работать - это проблемы с вашей религией.

(83) Месье, вы врете. CSV и XLS - были и остаются одними из основных форматов обмена. Но, возможно, мы о разном говорим. Мне пофиг на ваш BI, никогда с ним дело не имел. И миллиарды записей в Elastic не грузил, это да.

(77) В (10) написана херня. Причем несколько пунктов херни.

(86) А я не говорил, что мне религия запрещает работать с CSV. Вопрос в (0) звучал так: "Самый производительный способ выгрузки во внешние базы данных."

Я дал на него ответ, исходя из личного опыта. Если мой ответ и практический опыт не вмещается в вашу религию - то это проблемы с вашей религией.

(87) В овощных ларьках - возможно да. Там, где речь идет о действительно серьёзных объемах данных - CSV не встречал.

(90) А про XLS с его ограничением на количество строк - звучит, как детский сад.

(89) Ну и какой, по твоему, "Самый производительный способ выгрузки во внешние базы данных."
JSON? JSON это способ? Это же просто текстовый формат, а не способ

(90) Из этого следует, что вы никогда не работали с самыми распространенными СУБД.
Ну вот такая у вас религия, ага.

(90) Овощной ларек - Газпром с нынешней капитализацией.

+(91) Инфа для ларёчников:
https://support.microsoft.com/ru-ru/office/%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5-%D1%85%D0%B0%D1%80%D0%B0%D0%BA%D1%82%D0%B5%D1%80%D0%B8%D1%81%D1%82%D0%B8%D0%BA%D0%B8-%D0%B8-%D0%BE%D0%B3%D1%80%D0%B0%D0%BD%D0%B8%D1%87%D0%B5%D0%BD%D0%B8%D1%8F-excel-1672b34d-7043-467e-8e27-269d656771c3

Общее количество строк и столбцов на листе
1 048 576 строк и 16 384 столбца


Всего миллион строк - это не объем вообще. Для передачи больших объёмов не подходит от слова совсем.

(92) Так и CSV внезапно, это текстовый формат, а не способ :)))

(93) Конечно не работал, успокойся уже. Никто не покушается на твою наивную веру :)))

(95) Ну добавь еще 100 листов. Excel, кстати, тоже xml. Так что это твой выбор :)

(96) Вот и я об том же. Нехер тут спорить про форматы, если речь идет совсем о другом

(98) Блин. XML - содержится в формате XLSX, а речь шла про XLS. Ты даже про это не в курсе? :))))

(97) Так что насчет bulk insert, это тоже для ларьков?

(99) Ну тут не совсем соглашусь. От формата зависит во-первых объем данных, во-вторых скорость разбора данных. Также немаловажно удобство работы с форматом - либо для каждого обмена придется писать новую процедуру разбора, и в случае любого изменения переписывать её, либо использовать более универсальные процедуры выгрузки/загрузки, легко адаптируемые под изменения.
И выбор формата зависит как и от объемов выгружаемых данных, так и от их содержимого.
Где-то подойдет CSV, а где-то XML или JSON. в (0), кстати, не озвучены ни объемы данных ни их типы. Так что спор вообще ни о чём.

(100) В XLS 1048576 строк не влезет. Ты в (95) написал про xlsx. В xls 65535 было, если мне не изменяет память

(101) bulk insert можно использовать только внутри компании. Ты извини, конечно, но я не представляю ситуации обмена между различными организациями через bulk insert.

(103) Да? Ну значит, ссылку второпях не ту нашёл.
А 65535 - это вообще детский объём. Но вот товарищ на серьёзных щах утверждал, что это "... XLS - были и остаются одними из основных форматов обмена." :))))

(102) Ну вот и читай, что сам написал.
Объем - csv меньше чем JSON и XML
"Также немаловажно удобство работы с форматом - либо для каждого обмена придется писать новую процедуру разбора"
Все БД и аналитические программы всасывают csv как родной.

(105) Ну и правильно говорит. В xls постоянно обмениваются. Это плохо, но это так

(106) Всё-таки попробуй перечитать (10). Похоже, ты так и не понял, что там написано, раз не смог ничего возразить.

(104) Так ты представь. Всё тоже самое, только в 10 раз быстрее.

(107) Так я же и не спорю, что для небольших объемов данных подойдёт любой формат. Я лишь говорю, что для больших объёмов такой формат не годится. А вы почему-то с этим спорите.

(109) Не представляю крупную компанию, в которой СБ допустит такое. И скорость тут вообще ни при чём. Но в ларьке, вполне допускаю, могут и не такое учудить :)))

(108) В (10) написана херня. Просто пердок в лужу.

В общем, всё, как обычно. Набежали ларёчники и стали доказывать, что их тормозные, трудозатратные в реализации и костыльные способы обмена (хотя на их объемах разницу вообще не заметишь) - самые лучшие :)))

Но религия - вещь серьёзная.

(112) Обосновать по пунктам можешь или ты даже не понял, что там написано?

(105) Ты зациклился на своих задачах. Обмены на xls-ках и SFTP - пока еще существуют, как бы всем это не нравилось. Разумеется, там не миллионы записей в одном файле, там куча файлов с <65565 строк. Но раз выгружает условный Юнилевер ларькам данные в таком виде, значит, не всегда могут даже в XML сделать. Хотя уже даже ларьки как раз просят json, так как любой Вася умеет с ним работать.

(110) вот xml и json это для маленьких объемов. А миллионы записей заливаются более простыми форматами. Чем проще формат, тем быстрее заливается. Это же очевидно. CSV гораздо проще JSON и XML.

(113) когда сутки устанут выгружать в файлик любого формата , тогда и бэкапскульный  с нарочным на диске за радость будет.

(114) Ты думаешь, если ты не понял, что там написано, то и другие не поняли?

(116) Не вижу смысла даже спорить, раз ты не осилил ответить на вопросы, озвученные в (10).
Когда столкнёшься с реальными данными, тогда и поговорим.

(119) Ой мля. Да о чем с тобой разговаривать.