如果我在数据库用户和用户信息中有两个表（分为规范化目的），我生成两个模型User，UserInfo并通过关系将它们用作正常。
后来我的应用程序部分读取和写入两者，但是，创建条目有相当多的业务逻辑，例如查找条件规则的其他表，字符串构建等。
制作第三个模型（非数据库支持的模型）来处理所有这些以及通过其他两个模型创建/保存是否有意义？或者我应该把它保存在控制器中？
另一个例子可能是导入一个CSV文件，其中所有数据在不同的表之间分开，这是应用程序其余部分使用的单独模型。我可以使用定义每一行的模型来处理通过其他模型保存导入的数据。或者这应该在控制器中吗？
我对开发大型轨道应用程序时的最佳实践感兴趣。
答案 0 :(得分：2)
听起来你正常化（最小化冗余）而不是去规范化。
我不知道你的应用程序，所以请把它作为考虑而不是推荐的最佳实践：在这种情况下我通常喜欢做的是隐藏用户背后的Userinfo，以便用户是只有部分应用程序甚至知道有一个Userinfo。这可以使代码的其他客户端（控制器，其他模型以及你在控制台中与它交互时）保持简单和一致，并且干燥。
引入第三个模型可能会起到同样的作用，但它也会给应用程序增加概念上的重量。
答案 1 :(得分：0)
答案取决于你首先将用户数据分成两个表的原因 - 它应该解决什么问题。想出来并尝试将相同的逻辑应用于模型。
无论如何，我同意创建第三个模型是有意义的，该模型封装了与其他两个一起工作的复杂性。这使您可以向应用程序的其他层（控制器，视图）提供更简单的界面。但是，你必须仔细观察你的目标。如果您发现自己通过委托对封装组件的调用来重新实现大部分ActiveRecord :: Base，那么可能需要重新考虑。
顺便说一句，你做的不是去标准化。在关系数据库的上下文中去标准化意味着创建冗余（检查Wikipedia article on normalization，反标准化是相反的）。这通常是为了通过减少所需的连接数来提高性能。