我有一个收集数据的应用。这是对各种各样的调查。可以通过与应用程序中的数据库表绑定的GUI来管理调查问题。但问题的实际答案存储在一个表中：观察。我已经考虑过EAV模型了，但是让我们暂时把它放在一边。观察实体拥有900多处房产，因为该调查涉及很多问题。到目前为止，这已经成功了，即使它有点难看。但现在我正在努力使这个应用程序能力成为新客户的新调查。我维护相同的代码库和相同的git存储库是关键，但应用程序需要容纳另外700个观察属性。我将它们添加到我的实体并尝试进行迁移以创建新的数据库列。但是，我发现错误告诉我行大小太大。列太多了！
我想探索的解决方法是拥有多个版本的Observation实体。我可以为每个调查都有一个，并使用配置文件来选择正确的。但我希望所选实体位于ORM层次结构中的相同位置。所以，例如。如果我打电话
$subscription->getObservation()
我希望它返回正确的类型 基于配置的观察。如果每个安装最终都有一个表用于每个调查，这是可以的，因为除了其中一个表之外的所有表都有0行。
如上所述，另一种选择是放弃宽桌设计并使用EAV。但这种方法有一些重大缺点。