我正在与以前没有使用过 Ruby OR Rails 的开发人员一起开发一个项目。
在我看来，他们创建了一个过于复杂的模式。该模式有 117 个表，获取最简单的信息需要遍历/连接 7 个表……当然，没有“主”表作为它们之间的一种键。该模式呈现了许多 Rails 工具，如“查找”方法，并且许多 has_many/belongs 关系几乎无用。为所有这些关系编写代码可能会比我们有钱编写代码更耗时。
问题：
假设您非常确信（恕我直言……呵呵）架构并不理想，并且有多种方法可以表示域，那么您将如何主张简化架构（除了我已经说过的）？
我将在这里扮演两个角色
我假设 DBA 是一个真正了解所有数据库技巧的人。真的知道。
DBA：
数据库是应用程序的关键，应该具有预定义的结构，以便很好地服务于其目的并具有最佳性能。
如果您不能使用随机模式（这是合理规范化的并且很好），那么这些工具就是错误的。
开发人员：
数据库只是一个数据存储，所以我们需要保持简单并专注于应用程序。
DBA：
数据库不是存储，它是应用程序的核心。没有数据库就没有应用程序。
开发人员：
不。应用程序是核心。没有前端和应用到它的业务逻辑就没有应用程序。
战争开始了……
这两点都是有效的，而且总是要权衡取舍。
如果该数据库仅由 RoR 使用，那么您可以更像一个简单的 store来使用它。
如果数据库可以被其他应用程序使用，或者它将与大量数据和高流量一起使用，它必须强制执行一些最佳实践。
通常，您无法不同意 DBA。
但他们可以了解您的情况，并可能允许您稍微放宽标准，这样您就可以提高工作效率。
所以你需要密切合作，一起工作。
你需要互相交谈来解释和证明为什么数据库应该这样或那样。
否则，团队就会破裂，项目很可能会失败。
ActiveRecord 是一个非常方便的工具。但它不能为你做一切。默认情况下，它不提供您所期望的数据库结构。所以应该调一下。
另一方面。如果 DBA 可以接受所有 PK 都是自动递增的整数，这将使开发人员的生活更轻松（ActiveRecord 默认会这样做）。
另一方面，如果开发人员愿意接受一些 DBA 约束，那么 DBA 的生活就会变得更轻松。
现在回答你的问题：
你会如何争论简化架构
不要争论。与团队会面并传达信息并指出为什么应该这样做。
也许它真的不应该，你不知道所有的事情，也许他们不知道什么。
您可以就数据库的一般结构达成一致，并尝试使用 RoR 迁移作为元语言来描述它。
这样他们就会看到总体情况，而您将使用您出色的 ActiveRecords。而且每个人都会在同一页面上。
您的数据库架构应反映域及其关系。
仅当您测量到存在性能问题时才应进行反规范化。
7 连接并不过分或不好，只要您有良好的索引。
在链条上提出这个论点的一般方法是基于成本。如果你做事简单，就会有更少的代码和更少的错误。该系统将能够更快地构建或具有更多功能，从而创造更多的投资回报率。如果您可以通过这种方法让资金经理参与进来，他或她可能会让您向团队发号施令。有人反驳说极端的过度规范化可以防止坏数据，但我发现情况并非如此，因为它产生的复杂性往往会导致更多的错误和更多的数据库代码。
这里的架构和技术论点很简单。您已决定使用 Ruby on Rails。因此，您决定使用 ActiveRecord 模式。ActiveRecord 模式是通过让数据库表匹配对象模型来驱动的。这就是这里和许多其他地方使用的模式，因此他们试图应用极端数据规范化的最佳实践根本不适用。购买《企业应用程序架构模式》的副本并将红色小书签放在第 160 页，以便他们从架构的角度了解该模式的工作原理。
DBA 类型往往不知道 ActiveRecord 为您做了多少工作，从查询生成、级联删除、乐观锁定、自动填充列、版本控制（使用acts_as_versioned）、软删除（使用acts_as_paranoid）等等。使用经过良好测试的、社区支持的库函数来执行这些操作与必须由 DBA 维护的自定义代码的有力论据。
DBA 的真正问题是他们需要做一些工作。让他们专注于监控性能、查找代码中的慢查询、创建索引和进行备份。
如果您最终失去了理智模式的政治斗争，您可能需要考虑切换到 DataMapper。这是 PoEAA 中的下一个模式。您可以让他们做的另一件事是在数据库中创建与对象模型相对应的视图。这样，您可以基于视图使用 ActiveRecord 模型中的许多查找功能，但具有自定义的插入、更新和删除方法。