Существуют ли универсальный framework на PHP активно использующий ООП для разбора, импорта и экспорта таблиц?

Question

[Александр Карпов]

Есть у нас например таблица exel и есть например у нас "noname" cms
Я могу написать скрипт, разбирающий excel и в соответствии с тем что мы видим при разборе, выполнять различные методы предоставленные нам "noname" cms. Получится у нас портянка, которая почти не годится для того, чтоб быстро применить её, например, для другой cms.
Мне интересно, существуют ли решения, где умные люди думали и придумали, такую вещь, которая предлагает высокоэффективную организацию импортов и экспортов, позволяет обрабатывать зависимости между таблицами, конвертации, обработку и т.д. Короче творить чудеса. Если вы не знаете о таких решениях, то интересно ваше мнение об этой идее. С какими проблемами вы сталкиваетесь постоянно и что на ваш взгляд должен решать подобный framework. Спасибо!

Answer 1

[Котик Антон]

Получится у нас портянка, которая почти не годится для того, чтоб быстро применить её, например, для другой cms.

Написать решение, которое будет легко встраиваться в любую CMS невозможно. Обычно пишут какую-либо библиотеку для решения конкретных задач, а затем дополняют её плагинами, позволяющими интегрировать её в различные CMS. Причём под каждую CMS свой плагин.

Сама же библиотека никак не должна зависеть от конкретной CMS, с другой стороны при написании библиотеки можно использовать всё, что угодно. Я бы взял PHPExcel, отдельные компоненты от любого популярного фреймворка (например EventManager из ZF2). И написал бы собственную ORM, заточенную для работы с Excel, опираясь на опыт и архитектуру Doctrine. Если нужна работа не только с Excel значит дополнительно реализуем адаптеры под различные источники данных.

Готовых решений для подобных задач не встречал.

Answer 2

[Adamos]

Проблема, собственно, не в том, что CMS разные.
Проблема в том, что Ёксель - это не данные. Это всего лишь таблицы.
А чтобы "творить чудеса", на вход все-таки нужно получать данные.
Так что единственный путь, который хоть куда-нибудь ведет - это отбрасывание костылей и исключение Ёкселя из техпроцесса в принципе.
Пока это не сделано - портянки и головная боль неизбежны.

Comments

[Александр Карпов]

Мне нравится идея исключить из производства Ёксель, однако вопрос остается актуальным даже для xml

[Adamos]

Александр К: ну, я же не о том, чтобы тупо сконвертировать таблицы в другой формат. А о том, что сама идея подготовки данных в виде тупых таблиц, без семантики - это тупиковый путь и неизбежный оверхед.

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

[Александр Карпов]

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

[Adamos]

Александр К: Скажите это Яндекс.Недвижимости, например.
Они таки не стали городить универсальный парсер Ёкселя и ПоверПойнта.
В результате их система осталась и вменяемой, и гибкой.

Answer 3

[xmoonlight]

Такого не встречал.
Что хотелось бы:
1. Для создания единой интеграционной/миграционной "шины" на основе различных типов данных нужна унификация этих данных и простое создание зависимостей (схемы данных) на основе унифицированных данных.
2. Также, нужна возможность работы с этими данными посредством ORM (этой "шины"), т.е. возможность оперировать информационными объектами и потоками).
3. Также, должны быть настраиваемые интервалы для автоматического сбора информации с источников.
4. Система event-ов/триггеров умеющих "дёргать" внешние API (GET/POST и т.д.) по контролируемым событиям (например, для сигнала одной из систем "шины", что пришли её данные - можно начинать разбирать).
--------------------------------------------
Addon:
Ручной импорт/экспорт Excel:
https://dev.mysql.com/doc/mysql-for-excel/en/mysql...
https://sqlizer.io/
www.sqlmanager.net/ru/products/mysql/manager

Comments

[Александр Карпов]

xmoonlight Извините, но ваш ответ очень далек от моего вопроса. Во-первых, я указал CMS (и даже PHP) в пример не просто так, т.к. управление данными и организация этих данных происходит на уровне CMS - это обычная практика, на сколько мне известно. Это позволяет не быть привязанным к определенной базе данных (как минимум), реализовывать необходимую парадигму, зависимости, события в системе. Во-вторых, не стоит задачи "как спарсить Exel", стоит задача в системном подходе к экспорту и импорту. Или, пожалуйста, поясните ваш ответ, или же я не смогу его принять, т.к. мне непонятно, как он связан с вопросом. Спасибо!

[xmoonlight]

Александр К: ну я думал Вы собираетесь парсить Excel. А вообще, схема данных делается не через PHP, а через специализированные визуальные инструменты. Например EMS Mysql Manager: www.sqlmanager.net/ru/products/mysql/manager
Если речь идёт об автоматической миграции данных между хранилищами разных форматов, тогда этот алгоритм прописывается через API ORM для конкретной CMS-системы и создаётся миграционная "шина", посредством которой данные имеют унифицированный формат внутри всей инфраструктуры.

[xmoonlight]

Александр К: обновил ответ.

[Александр Карпов]

xmoonlight: да, проектирование организации данных делается не через CMS, я может быть просто недостаточно точно объяснил мысль, я должен был как раз упомянуть об ORM, собственно с ней ведь и приходится работать, если CMS нормальная, прямые запросы вообще не приходится делать. Спасибо, что обновили свой ответ и проявили интерес к моему вопросу.

Answer 4

[dmitriy]

Я бы реализовал не инструмент для cms, а самодостаточный сервис. Под капотом имея все необходимые инструменты для работы с Excel и другими форматами можно не только производить разметку, но и например выгружать в CMS данные по специализированному АПИ по определенному событию/периодичности, например раз в сутки.