开发 PHP 数据导入框架的最佳实践是什么？
在作为一家气象公司的 Web 开发人员的工作中，我们一次又一次面临相同的任务：从某个地方（FTP/Web/目录/邮件）获取一些文件并将其中包含的数据导入数据库。
当然，文件格式永远不会相同，数据库总是设计不同，必须处理无数特殊情况等等。
所以现在我正在为此类工作计划一个导入框架。 由于我们都是经验丰富的 PHP 开发人员，并且当前的脚本是 PHP 或 Perl，因此我们将坚持使用 PHP 作为脚本语言。
- 数据获取器将从源获取文件，打开它并将内容存储到字符串变量中。 （别担心，PHP 将从我们这里获得足够的内存。）
- 数据处理程序将完成复杂的工作，将字符串转换为某种数组。
- 该数组将被保存到数据库或写入新文件或我们应该用它做的任何事情。
除了此功能之外，还有一些常见的错误处理、日志写入和电子邮件报告。
这个想法是使用类的集合（一些 getter 类、许多专门的处理程序、一些 writer 类）。
我的问题：我如何在工作脚本中实际组织这些课程？ 我是否发明了某种将被解释并相应地调用类的元语言？ 或者只是提供这些类必须实现的一些简单接口，并且我的用户（就像我说的：经验丰富的 PHP 开发人员）将编写加载这些类的小型 PHP 脚本？
几乎可以肯定，第二个版本提供了最大的灵活性和可扩展性。
对于这样的事业，您还有其他的想法吗？
During our work as web developer for a meteorological company, we are faced with the same task over and over again: Get some files from somewhere (FTP/Web/directory/mail) and import the contained data to a database.
Of course the file format is never the same, the databases are always designed differently, countless special cases have to be handled, etc, etc.
So now I'm planning an importing framework for exactly this kind of work. Since we're all experienced PHP developers and the current scripts are either PHP or Perl, we'll stick with PHP as scripting language.
- A data getter will fetch the file from the source, open it and store the content into a string variable. (Don't worry, PHP will get enough memory from us.)
- The data handler will do the complicated work to convert the string into some kind of array.
- The array will be saved to the database or written to a new file or whatever we're supposed to do with it.
Along with this functionality there will be some common error handling, log writing and email reporting.
The idea is to use a collection of classes (Some getter-classes, a lot of specialised handlers, some writer classes).
My question: How do I practically organize these classes in a working script? Do I invent some kind of meta language which will be interpreted and the the classes are called accordingly? Or just provide some simple interfaces these classes have to implement and the my users (like I said: Experienced PHP developers) will write small PHP scripts loading these classes?
The second version almost certainly offers the biggest flexiblity and extensibility.
Do you have any other ideas concerning such an undertaking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在需要导入和导出的数十种不同外部数据格式的类似环境中工作，我建议至少尝试并让它们统一数据格式。 我们通过开发工具帮助公司外部的其他人将他们的数据转换为我们的格式，取得了一些成功。 我们还免费向他们提供了源代码。
其他一些人现在正在使用我们的工具为我们转换他们的数据，如果他们改变了格式，那么就是他们改变了转换工具。 减少我们头痛的原因之一。
在一种情况下，它甚至导致另一家公司改用我们系统内部使用的文件格式。 当然，这只是一个案例，但我认为这是漫长道路上的第一步;-)
Working in a similar environment of dozens of different external data formats that need to be im- and exported, I can recommend to at least try and get them to unify the data formats. We had some success by developing tools that help others outside our company to transform their data into our format. We also gave them the source code, for free.
Some others are now transforming their data for us using our tools, and if they change their format, it is them that changes the transformation tool. One cause of a headache less for us.
In one case it even lead to another company switching to the file format our systems use internally. Granted, it is only one case, but I consider it a first step on a long road ;-)
定义标准 Web 服务在这里不起作用是否有原因？ 然后，您可以以标准格式提供数据，如果出现错误，则返回 SOAP 错误（可能由输入文档中的字段填充）。
它可能比帕维尔的建议更有限（或者需要更多的前期设计），但可能值得考虑。
Is there a reason why defining a standard web service wouldn't work here? Then you can supply the data in a standard format, returning a SOAP error (possibly populated by a field in the input document) if there's a fault.
It's potentially more limited than Pavel's suggestion (or would require more up-front design), but might be something worth considering.
我建议借用数据转换服务 (DTS) 中的概念。 您可以拥有数据源和数据接收器、导入任务、转换任务等。
I suggest borrowing concepts from Data Transformation Services (DTS). You could have data sources and data sinks, import tasks, transformation tasks and so on.