我正在查看文件上传 gem，似乎倾向于将所有资产放在单个“资产”表中，并使用 STI 对它们进行子类化。比如ImageAsset, VideoAsset,AudioAsset等。
我是 Rails 新手，从未使用过 STI。以前我只会制作images, videos,audios单独的表格。当然，他们可能会共享几列，但我会说他们也会有一些不同的列（采样率不适用于图像，例如）
将所有这些填充在一个“资产”表中的优点：更容易对所有资产运行查询。缺点：桌子会更快变大。我想如果这是一个问题，我总是可以在“类型”列上分片。此外，我预计所有仅音频列在图像行等上都将为空。
我的整个应用程序将基于资产，所以我想在做出决定之前确保我有直截了当的利弊。有没有人做过 STI 资产并后悔过？有没有人做过并且不后悔（对于大量资产）？CTI（类表继承）在这里会是更好的解决方案吗？
我想说的是，使用 STI 的最大缺点之一是，如果您向表中添加了一个在 STI 的所有模型之间未共享的列（并且这意味着相同的事情），那么您就完蛋了您的数据完整性就在那里。
（关系）数据库中的空字段通常会导致比它们解决的问题更多的问题。
我已经被这个问题困扰了好几次，当你的 STI 关系中的类开始拥有它们自己的子类时，它变得特别令人沮丧，这反过来又在表中添加了更多的列。
我想说，如果你想让这个结构尽可能好，我真的认为 CTI 是一个更好的选择，尽管让它与 rails 一起工作可能有点棘手。至少它比 STI 复杂得多。
在我的脑海中，我只能想到一种 STI 可能实际上是合理的场景，那就是当您处理交易模型时（例如从银行账户存款和取款等）。在这些情况下，除了交易的“方向”之外，这两种模型基本上是相同的。
也可以说 STI 对快速原型设计“很好”，如果你只是想快速组合一些东西只是为了看看它是否有效，你可以使用 STI，但是一旦你开始添加不支持的列对关系中的所有模型都没有意义，您可能应该将其重构为 CTI 或其他东西。