支持完全复合主键/外键的PHP ORM

我正在寻找PHP5ORM，它完全支持基于复合主键和外键的复合（多列）关系

我希望第二条原则能够解决这个问题，但事实并非如此。这是关系数据建模的一个基本特性，但我所知道的PHP ORM软件都不支持它

---

我最近发现SQLAlchemy有完全的支持，但我需要的是PHP，而不是Python。

来自Doctrine2参考：

条令2允许使用复合材料 主键。但也有一些 反对使用单一 标识符。使用 @GeneratedValue注释仅适用于 支持简单（非复合） 主键，这意味着您只能 如果生成了组合键，请使用组合键 主键值在您之前 在上调用EntityManager#persist（） 实体

指定复合主键的步骤/ 标识符，只需放置@Id标记 在构成的所有字段上添加注释 主键

---

当您从数据库的角度来处理应用程序时，像Doctrine2（PHP）或Hibernate（Java）这样的“派生”应用程序是不合适的。当您想换一种方式（即“我有一个OO域模型，需要将其保存在关系数据库中”，而不是“我有一个关系数据库，需要一个（生成的？）OO接口，而不在数据库方面做出任何妥协”）时，这些方法更合适。如果你不顾方法上的这些重要差异而使用它们，并且你更喜欢你的关系模式，而不是你的对象模型，你只会感到沮丧

区分不同类别的ORM工具非常重要，因为它们往往侧重于不同的开发模型

也许可以试试Propel或RedBeanPHP，它们似乎适合于几乎没有映射的数据库驱动开发模型，只是简单生成（通常是愚蠢的）“数据对象”，没有太多抽象。在这些解决方案中，外键字段只是直接放入对象中，所以它们可能“支持”您想要的所有复合内容

Doctrine2或Hibernate等解决方案不鼓励使用复合键，因此只在一定程度上支持它们（Hibernate走得相当远，但不建议使用它们）

---

就我个人而言，我不喜欢复合键（除了没有额外数据的纯多对多链接表），因为我倾向于从应用程序/域模型/对象方面处理更多的事情，而映射到对象的复合键通常很难处理，即使底层映射技术支持它们。代理键（或者至少是单字段自然键）使事情变得更简单。我不是一个关系数据库规范化迷，在我看来，“更好的性能”是非常值得怀疑的。如果系统中存在实际的性能问题，保存偶尔加入不会为您节省时间。

条令2.1完全解决了此问题。

您可以尝试使用PHP 5编写的。可在github上访问

Leap ORM完全支持主键和外键的复合键。同样，它也适用于非整数主键/外键。在ORM模型中，您可以创建字段别名、字段适配器和关系

尽管它是为编写的，但只需在代码中添加一个简单的自动加载函数，就可以轻松地使它与任何PHP框架一起工作。Leap使用以下数据库：DB2、Drizzle、Firebird、MariaDB、MS SQL、MySQL、Oracle、PostgreSQL和SQLite。它还提供了查询生成器和数据库连接池

---

在ORM的网站上，有很多好东西可以帮助你理解如何使用它。

不，你的信息是无用的。即使是原则1也支持复合主键。我需要基于复合主键和复合外键的多列关系。第二条原则的参考文献说，它在这里不支持这一点：是的，对不起，你是对的，我没有看到这一点。我在使用v1.2，我现在也在使用教义v1.2。在这种情况下，我会创建丑陋的代理键来模拟所需的功能。。。但它破坏了良好的关系数据设计，并最终导致性能降低（不必要的索引）。合成键是有争议的问题。例如，RubyonRails根本不支持复合主键，但谁说RubyonRails有很好的ORM呢？正确使用组合键可以实现更好的数据库设计和更好的性能（有时可以省略连接，这是查询中最大的瓶颈之一）。请不要提及Hibernate。它完全能够从数据库中创建域模型，尤其是复合键。谢谢，这是一个很好的观点，但在我看来，关系数据模型比应用程序更重要。我知道数据库使用时间超过25年（没有重大更改）的系统，它们的应用程序前端完全更改了几十次。更改应用程序非常容易—如果不重新添加一半的数据，更改或调整不良数据设计非常困难，有时甚至不可能。这就是为什么我认为软件开发应该以数据为中心，而不是以应用程序为中心，这也是为什么我寻找数据库驱动的ORM。@jpartogi：在我看来，通过对关系数据库进行反向工程，永远无法创建（好的）域模型，而且也不鼓励在Hibernate中使用复合键。引用文档中的话：“有一种替代声明允许使用复合键访问遗留数据。强烈建议不要将其用于任何其他用途。”我知道它对它有很强的支持，但主要是对遗留数据库的支持。@jpartogi：我提到了Hibernate，因为它是相同的方法：鼓励以对象为中心的开发模型，而不鼓励使用复合键。