如果我在数据库用户和用户信息中有两个表（出于规范化目的而拆分），我会生成两个模型User，UserInfo，并通过关系正常使用它们。
稍后，我有我的应用程序的一部分可以读取和写入两者，但是，创建条目时有相当多的业务逻辑，例如查找条件规则，字符串构建等其他表。
制作第三个模型（非数据库支持的模型）来处理所有这些并通过其他两个模型创建/保存是否有意义？ 还是我应该将其保留在控制器中？
另一个示例是导入一个CSV文件，其中所有数据都拆分在不同的表之间，应用程序其余部分使用单独的模型。我是否可以使用定义每行的模型来处理通过其他模型保存导入的数据。还是应该在控制器中？
我对开发大型轨道应用程序时的最佳实践感兴趣。
听起来你是在规范化（最小化冗余）而不是去规范化。
我不知道您的应用程序，所以请将其视为需要考虑的事情，而不是推荐的最佳实践：在这种情况下，我通常喜欢做的是将用户信息隐藏在用户后面，以便用户是应用程序中唯一知道存在用户信息的部分。这使代码的其他客户端（控制器、其他模型以及在控制台中与之交互时）保持简单、一致和 DRY。
引入第三个模型可能达到相同的目的，但它也增加了应用程序的概念权重。
答案取决于为什么首先将用户数据拆分为两个表 - 它应该解决什么问题。弄清楚这一点并尝试将相同的逻辑应用于模型。
无论如何，我同意创建第三个模型来封装使用其他两个模型的复杂性是有意义的。这使您可以向应用程序的其他层（控制器、视图）提供更简单的界面。但是，您必须仔细观察您在这方面走了多远。如果您发现自己通过委派对封装组件的调用来重新实现大部分 ActiveRecord：：Base，那么可能是时候重新考虑了。
顺便说一句，你所做的不是去规范化。关系数据库上下文中的非规范化意味着创建冗余（查看维基百科关于规范化的文章，非规范化恰恰相反）。这样做通常是为了通过减少所需的联接量来提高性能。