我正在与以前没有使用过 Ruby 或 Rails 的开发人员合作一个项目。
在我看来，他们创建的模式过于复杂。该模式有 117 个表，获取最简单的信息需要遍历/连接 7 个表……当然，没有“主”表作为它们之间的一种键。该模式呈现许多 Rails 工具，如“查找”方法，并且许多 has_many/belongs 关系几乎无用。为所有这些关系编写代码可能比我们有钱编写代码更耗时。
问题:
假设您非常确信(恕我直言...嘿嘿)模式并不理想，并且有多种方式来表示域，您会如何主张简化模式(除了我已经说过的) ？
最佳答案
我会在这里扮演两个角色
- DBA:数据库管理员/设计师。
- Dev:应用程序开发人员。
我假设 DBA 是真正知道所有数据库技巧的人。真的知道。
数据库管理员:
数据库是应用程序的关键，应该有预定义的结构，以便很好地服务于它的目的和最佳性能。
如果您不能使用随机模式(合理规范化且良好)，那么这些工具就是错误的。
开发人员:
数据库只是一个数据存储，因此我们需要保持简单并专注于应用程序。
数据库管理员:
数据库不是存储，它是应用程序的核心。没有数据库就没有应用。
开发人员:
不，应用程序是核心。没有前端和应用于它的业务逻辑就没有应用程序。
war 开始了......
这两点都是有效的，而且总是权衡取舍。
如果数据库仅供 RoR 使用，那么您可以将其用作简单存储。
如果数据库可以被其他应用程序使用，或者它将被大量数据和高流量使用，它必须执行一些最佳实践。
一般来说，你不可能不同意 DBA。
但他们可以理解你的情况，可能会让你放宽标准一点，这样你就可以更有效率。
因此您需要紧密合作。
而且您需要彼此交谈以解释和证明这一点为什么数据库应该像这个或那个。
否则，团队会崩溃，项目很可能会失败。
ActiveRecord 是一个非常方便的工具。但它不能为您做所有事情。默认情况下，它不提供您所期望的数据库结构。所以应该调一下。
另一边。如果 DBA 可以接受所有 PK 都是自动递增的整数，这将使开发人员的工作更轻松(ActiveRecord 默认情况下会这样做)。
另一方面，如果开发人员愿意接受一些 DBA 约束，这将使 DBA 的工作更轻松。
现在回答你的问题:
how would you argue FOR simplifying the schema
不要争论。与团队会面并传递信息并指出为什么应该这样做。
也许它真的不应该，你不知道所有的事情，也许他们不知道某些事情。
您可以就数据库的一般结构达成一致，并尝试使用 RoR 迁移作为元语言来描述它。
通过这种方式，他们可以看到总体情况，而您可以使用出色的 ActiveRecords。 而且每个人都会在同一页面上。
关于ruby-on-rails - Ruby 社区重视简单性……您对在新项目中简化数据库模式有何看法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1871133/