Выбор источника данных для загрузки

Какой вариант загрузки выбрать, если есть выбор. «Грузить данные из API, это современный подход, а файлы Excel устаревший метод» это не совсем так, выбирать надо по ситуации.

Табличные файлы

Загрузка данных из файлов табличных документов, прайс-листы в формате Excel.

Минусы:

• Табличная структура, проблематично загрузить сложные данные, например товары, со списком характеристик, списком ссылок на фотографии, несколькими описаниями. Именно сложно, но возможно;
• Невозможна выборочная загрузка, в любом случае надо прочитать все, затем уже на этапе записи отобрать нужные записи;
• Невозможна постепенная загрузка, обязательно переда записью файл загружается в память целиком, затем уже анализируется и извлекаются нужные данные, для записи. При большом объеме файла, может быть серьезной проблемой. Но это скорее исключение, как правило таких больших файлов не создают, его и в офисном ПО было бы проблемно открыть.

Плюсы:

• Табличная структура, структура дает возможность разработать универсальный загрузчик, с настройкой колонок таблицы, соответствующим данным системы;
• Табличная структура, с заранее известными колонками позволяет создать временную таблицу, передать ее в запрос к базе учетной системы, и разом подставить к строкам связанные данные из учетной системы, а не делать это построчно. Например при загрузке прайс-листа подставить товары по идентификатору, которые уже были ранее загружены. Такая возможность увеличит скорость обновления данных;
• Локальный файл, все загружаемые данные в нашем распоряжении, это быстро и надежно.

XML файлы

YML (Яндекс маркет), CommerceML, либо собственная структура поставщика данных.

Минусы:

• Нет единого формата, XML это набор правил для описания древовидной структуры данных. Если не повезло, и данные не в распространенном формате YML, необходимо будет разработать модуль загрузки под каждый такой формат;
• Из за древовидной структуры данных, нет возможности разработать универсальный загрузчик под любые XML. Нет я видел «решения», где предлагают по типу как выбор колонок для табличного документа, настроить фразы поиска, или даже выбрать какие теги. Но это же по сути попытка написать, свой вариант XSLT процессора, при чем упрощенный и… ну никакой. Лучше уже тогда взяли бы готовый XSLT процессор и написал под каждый формат XSLT шаблоны, что по сути почти тоже самое и есть, как сопоставление колонок. В данном решении XSLT процессор не использую, так как файлы XML читаем только потоком, не считывая сразу весь файл в память.

Плюсы:

• Древовидная структура файла, позволяет загружать данные с вложениями, любой сложности. Что в табличном формате может быть невозможно;
• Возможность читать файл потоком, не загружая весь файл в память, что очень важно при загрузке большого объема. При таком подходе файл может быть хоть 100ГБ, грузится конечно будет долго, но загрузится;
• Локальный файл, все загружаемые данные в нашем распоряжении, это быстро и надежно. Что особенно актуально при загрузке больших объемов данных.

API интерфейс

Загрузка данных через API интерфейс внешних систем.

Минусы:

• Внешний сервер, зависим от скорости работы интернета, и что еще хуже от загруженности системы, которая предоставляет API. Низкая скорость загрузки;
• Только частичная загрузка данных, нет возможности получить сразу все данные, данные придется запрашивать частями, на сколько большими зависит от правил API, бывает и так что только под одно записи. Длительное время, при загрузке большого объема.

Плюсы:

• Актуальность данных, данные получается сразу из внешней системы, а значит они более актуальные, чем в выгруженных файлах, которые формируют периодически, и за это время данные могут устареть. Но при глобальной загрузке, пока мы загрузим все, пройдет достаточно времени, значит и запускать такую загрузку будем не так часто, данные тоже будут уже не такие актуальные;
• Избранность данных, возможность загрузить только нужные и самые актуальные данные. Например, когда надо запросить цену или остаток на конкретный товар;
• Больше данных, как правило в файлы выгружают данные выборочно, API дает более полный объем информации.

Резюмируя, какой вариант лучше, если есть выбор:

• Регулярную загрузка большого объема данных с простой структурой, лучше всего делать из файлов табличных документов тип Excel. Например обновление цен на все товары поставщика.
• Загрузка большого объема, со сложной структурой, лучше всего из файлов XML. Например загрузка контента для товаров.
• Выборочная загрузка, чтобы получить самые актуальные данные, но на небольшой объем, лучше делать через API, чтобы не загружать избыточные данные, когда нам нужны только избранные. Например получить актуальный остаток на выбранный товар, или список товаров в базе поставщика.

На практике используется, регулярная загрузка довольно больших объемов данных, таких как обновление цен на товары поставщика. Если у поставщика не 1..2 тыс позиций, то вариант с полной загрузкой через API это самый не желательный, его стоит использовать только в крайнем случае, если нет альтернативы в виде файла табличного документа, а такая альтернатива в большинстве случаев есть.

Не рекомендую использовать API для обновления цен и остатков на все товары поставщика. Только если у поставщика не большой ассортимент номенклатура, 1..2 тыс позиций, либо нет альтернативы в виде файла.