DBIx::Class 结果类和实际表
我正在研究 DBIx 类，但我有点困惑，因为到目前为止我与数据库的交互都是 PHP 代码中的普通 SQL 查询。
无论如何，据我了解，该类使用结果类中定义的模式进行操作，而不是直接与数据库交互。该模式可以通过各种 .pm 类手动构建，也可以通过 Loader 类从数据库中提取。
我的问题是：首选的方法是什么？如果我手动构建结果类然后更改数据库会怎样？我想我必须编辑表和类，这不是有点不切实际吗？
谢谢
I'm studying DBIx classes and I'm a bit confused since my interaction with a database so far has been plain SQL queries in PHP code.
Anyway, as I understand it, the class operates with the schema defined in the result classes instead of interacting directly with the database. The schema can be either be built manually via the various .pm classes or pulled from the database via the Loader class.
My question is: what is the preferred approach to this? What if I manually build my result classes and then alter my database? I guess I have to edit both the tables and the classes, isn't it a bit impractical?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 DBIx::Class 等对象关系映射系统的困难之一是您必须使表类与您的模式保持最新。通常，它就像在这里或那里添加一个字段一样简单，也许偶尔添加一个新的外键关系。如果您的代码处于版本控制中，那么跟踪应该相对简单。
在两个地方维护相同的东西（数据库模式）的缺点被拥有一个 ORM 系统的优点所抵消（恕我直言）。一旦习惯了使用 DBIx::Class 查询及其结果集，事情就会比一直编写原始 DBI 调用快得多。
就我个人而言，我在 Loader 类方面运气不佳，但我已经有一段时间没有尝试过它们了。如果它们适合您，那么它可能比在代码中手动维护架构定义更容易。另一方面，我从来没有因为这需要付出的微小努力而烦恼。一旦系统启动并运行，数据库模式往往不会经常更改。
One of the difficulties in using an object-relational mapping system like DBIx::Class is that you have to keep your table classes up-to-date with your schema. Usually, it's as simple as adding a field here and there, maybe adding a new foreign key relation once in a while. If you've got your code in version control, then it should be relatively simple to keep track.
The disadvantage of maintaining the same thing (DB schema) in two places is outweighed (IMHO) by the advantage of having an ORM system in place. Once you get used to working with DBIx::Class queries and their ResultSets things go a lot faster than writing raw DBI calls all the time.
Personally, I've not had good luck with the Loader classes, but it's been quite a while since I've tried them. If they work for you, it's probably easier than manually maintaining your schema definitions in the code. On the other hand, I have never been bothered by the minuscule effort that this requires. Database schemas tend not to change too often once a system is up and running.