Zend DB（标准方式或表网关）与Zend 2中的Doctrine。有些人可能会说这是苹果与橙子的比较，但我会说因为它们是替代品（我们使用两个之间的一个），所以可以进行比较（因为要求并不总是很清楚）。
当我开始 Zend 2 时，因为文档、书籍、教程都基于 Zend DB 或表网关，我使用它，但我对我们必须处理 2、3 个或更多表连接（多个表网关适配器）的方法不满意，所以我切换到 Doctrine ORM（也读到很多人说"学说对大型项目有好处"）。我已经在symfony项目中使用了doctrine，所以并不困难，但我也不喜欢像实体之间的复杂连接（额外工作）这样的doctrine，尤其是与Zend DB相比缓慢和额外的内存。
现在我真的很困惑我该怎么办？那么你们有什么建议呢？
根据我的分析：
表网关
优点
- 轻量级（保持简单）
- Zend原生（现在和将来的更新都有更好的支持）
- 更多文档手册
- 更好的社区或用户支持（因为这是许多人正在努力的工作）
- 关闭数据库表（我擅长SQL。所以感觉很好）
- 更灵活
- 更易于使用其他原则原生功能，例如 ACL
缺点：
- 表连接（更复杂）
- 在某些情况下是原始的
- 处理多个表网关实例很困难。
学说
优点
- 更多类松散耦合 — 更好的控制
- 带来使用ORM的所有优势 关于
- 教义本身（教程-文档）已经有很多工作，大部分时间都有效
- 减少对数据库的依赖
- 缓存（也可以使用 Zend DB 表网关）
缺点：
- 更多内存和更慢（与Zend DB表网关相比）用于中型项目
- 增加复杂性（额外的文件 + 配置 + 自己的约定）
- 有时对于中型项目矫枉过正
- 在实体之间的多对多关系或复杂联接中工作更多
- 额外工作 YAML 架构
- 更少的教程-书籍-用户对Zend + Doctrine的支持
还有其他人吗？（两者兼而有之）
那么，鉴于这些，您建议哪一个？致力于我可以扩展的通用 CMS。
或者为什么Zend DB不能/不应该在大型项目中使用？
我在这里找到了一些讨论，但不是根据其优缺点分析。
我做了相反的事情。我删除了原则 2 并切换到 Zend DB 2，它将我们的查询提高了 5 倍，然后我们能够自定义 Zend DB 表网关的某些部分，并且我们在查询上获得了 5 倍的性能（几乎是本机）。
我会说，如果你离开了，就不要使用Doctrine，如果你有大型数据集。请记住，教义消耗了大量资源。
多年后我转向了教义，我认为如果你能让它与Zend兼容，这比Zend_Db要好得多。Doctrine可以migrate您的数据库，这意味着您只需一个命令即可将客户数据库更新到最新版本。另一个好处是您的entities可以在多种DBMS中实现，例如mysql，mssql，mangodb和...
为了获得更多兼容性，您可以使用拉曼框架（该框架为 Zend 1.12 添加了一些功能）
如果以下内容对你很重要，那么我会说绝对使用 Zend/Db/*
- 性能
- 可扩展性
- 学习曲线低