JSON или CSV для обмена данными между БД?

Заметил, что зачастую для интеграции реляционных баз данных используются объектно-ориентированные сообщения. В сущности, это означает лишние расходы на преобразования между реляционным и объектным представлениями данных.

Например, в системе управления заказами клиентов есть логическая сущность заказ, состоящая из "шапки" и строк заказа. В реляционной БД она представляется двумя таблицами.

Пусть в них хранится заказ с тремя строками:

-- таблица order - шапка заказа

order_id order_date client_id
-------- ---------- ---------
     321 2024-10-15       515

-- таблица order_lines - строки заказа

order_id item_id quantity item_price
-------- ------- -------- ----------
     321 202223         5     270.00
     321 197716         1     499.00
     321 254412         1     720.00

Для передачи в корпоративную шину данных, объединяющую все системы компании, заказ преобразуется в объектно-ориентированное представление в формате JSON:

{
    "operation": "change",
    "order_id": 321,
    "order_date": "2024-10-15",
    "clinet_id": 515,
    "lines": [
        {"article": "202223", "qty": 5, "price": 270.00},
        {"article": "197716", "qty": 1, "price": 499.00},
        {"article": "254412", "qty": 1, "price": 720.00}
    ]
}

(Здесь поле "operation", по сути, определяет тип сообщения и принимает одно из двух значений: "change" или "delete". Сообщение "change" формируется при создании или изменении заказа и содержит все значимые поля заказа и его строки, а сообщение "delete" — при удалении заказа и содержит только идентификатор удаляемого заказа.)

Для загрузки в корпоративное хранилище данных или другую реляционную БД заказ снова преобразуется в реляционное представление - это опять две таблицы, которые отличаются от таблиц в системе-источнике именами и, возможно, специфичными для СУБД типами данных столбцов:

-- таблица order

order_code order_date client_code
---------- ---------- -----------
       321 2024-10-15         515

--таблица order_pos

order_code article qty price
---------- ------- --- --------
       321 202223    5   270.00
       321 197716    1   499.00
       321 254412    1   720.00

Вопрос: при том, что потребителями сообщений шины данных на 90% являются реляционные БД, целесообразно ли использовать объектно-ориентированное представление (JSON) для передачи данных? Да, читабельно, как за счет именованных полей, так и за счет объединения всех компонентов заказа в один объект, но...

Более легковесной альтернативой может быть передача строк с разделителем полей (CSV), где первые два поля идентифицируют компонент логической сущности и операцию, соответственно:

order_head;change;321;2024-10-15;515
order_line;change;321;202223;5;270.00
order_line;change;321;197716;1;499.00
order_line;change;321;254412;1;720.00

Минус такого представления в том, что здесь отсутствует информация об именах полей. Но ведь сообщения формируются и обрабатываются автоматически и не предназначены для непосредственного чтения пользователями (хотя читабельность JSON это приятный бонус).

А автоматическое формирование и автоматическая обработка таких сообщений реализуются проще и требуют меньше ресурсов, чем формирование и обработка JSON. К тому же, CSV-представление занимает меньше места.

Отсутствие имен полей в CSV-представлении означает необходимость обращаться к значениям полей по позиции в строке. Это менее удобно, чем обращение по именам, и может провоцировать ошибки обработки, особенно при изменении состава передаваемых полей. (Но предупрежден — значит вооружен.)

Другой минус CSV-представления в том, что компоненты заказа (и, в общем случае, любой другой логической сущности) не объединены в одну структуру, а передаются в отдельных строках. В связи с этим имеет смысл передавать в шапке заказа общее количество строк и/или общую сумму заказа, чтобы принимающая сторона имела возможность убедиться в целостности принятых данных.

На этом все. А выбор за вами.