在Rails中将图像作为模型存储

Question

在我正在构建的网站的CMS中，我使用Paperclip来处理文件上传。用户可以上传图像，必须为每个图像提供简要描述，然后用于命名图像（用于SEO）和用于图像的alt标记。每个图像都被调整为一些预定义的大小并存储在S3上。

用户可以在许多地方使用此图像，实际上创建多种不同类型的模型，每种类型都与特定图像相关。因此，考虑到我需要存储有关图像的元数据（其描述），并且我需要在多个模型之间共享单个图像，似乎将图像封装在其自己的模型中是有意义的，然后可以将其添加为任何需要它的模型上的关联。然后，Image模型具有Paperclip的附加文件。这意味着我不需要在引用图像的任何模型上存储重复信息。

我的担忧是性能问题。现在，任何图像请求都需要通过Image模型进行，而不是直接作为属性访问URL。

这是否是明智的解决方案，还是应该以不同的方式处理？

- Undistraction

---

直接访问URL是什么意思？如果您正在使用Paperclip，则始终会通过模型访问链接，例如@user.avatar.url。 - claptimes

据我所知，Paperclip附件不是一个模型，也不会被持久化到数据库中。检查任何使用Paperclip的项目中的迁移/模式，您都不会找到单独的模型。它是在实例化模型时临时生成的类。存储发生在Paperclipped模型上，因此当我说“直接”时，我的意思是直接访问模型属性，而不必深入到另一个模型中。 - Undistraction

那么你是在说 @item.image.url 和 @item.image_url 之间的区别吗？ - claptimes

@claptimes 没错。前者会额外增加一次数据库访问。我已经进行了编辑以使其更清晰。 - Undistraction

我觉得你想太多了...locomotive做了类似的事情，虽然locomotive使用的是mongo而不是sql，但在IO操作方面并没有太大的区别。如果你正在构建一个CMS，你可能不会公开实际的“Image”模型。你可能会将其作为某种资产名称或元键，一旦模板被编译，它就会被解析。如果你担心查找时间，那么应用缓存。 - j03w

Answer 1

你想得很对。你需要的是Rails多态关联，文档在这里。实际上，在示例中使用了图像作为用例。

任何性能差异都将是可以忽略不计的，并且可能比手动处理其他解决方案更好。

- pduey