Какова лучшая практика для разработки структуры импорта данных PHP? - PullRequest
3 голосов
/ 09 февраля 2009

Во время нашей работы в качестве веб-разработчика для метеорологической компании мы снова и снова сталкивались с одной и той же задачей: получить некоторые файлы откуда-нибудь (FTP / Web / directory / mail) и импортировать содержащиеся в них данные в базу данных.

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

Так что теперь я планирую импортировать фреймворк именно для такой работы. Поскольку все мы являемся опытными разработчиками PHP, и текущие сценарии являются либо PHP, либо Perl, мы будем использовать PHP в качестве языка сценариев.

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

Наряду с этой функциональностью будет реализована некоторая общая обработка ошибок, запись в журнал и создание отчетов по электронной почте.

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

Мой вопрос: Как практически организовать эти классы в рабочем сценарии? Придумаю ли я какой-то мета-язык, который будет интерпретироваться, и классы будут называться соответственно? Или просто предоставьте несколько простых интерфейсов, которые должны реализовать эти классы, и мои пользователи (как я уже говорил: опытные разработчики PHP) будут писать небольшие PHP-скрипты, загружающие эти классы?

Вторая версия почти наверняка предлагает наибольшую гибкость и расширяемость.

Есть ли у вас другие идеи относительно такого мероприятия?

Ответы [ 3 ]

4 голосов
/ 09 февраля 2009

Я предлагаю заимствовать концепции у Служб преобразования данных (DTS). Вы можете иметь источники данных и приемники данных, задачи импорта, задачи преобразования и т. Д.

3 голосов
/ 09 февраля 2009

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

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

В одном случае это даже привело к тому, что другая компания переключилась на формат файлов, используемый нашими системами для внутреннего использования. Конечно, это только один случай, но я считаю это первым шагом на долгом пути; -)

0 голосов
/ 09 февраля 2009

Есть ли причина, по которой определение стандартного веб-сервиса здесь не работает? Затем вы можете предоставить данные в стандартном формате, возвращая ошибку SOAP (возможно, заполненную полем во входном документе) в случае ошибки.

Он потенциально более ограничен, чем предложение Павла (или потребует более предварительный дизайн), но, возможно, стоит подумать.

...