我们只是将我们的ASP.Net商店实施(从简单的实施)升级到应该更灵活的结构。我只是在寻找一些如何存储与产品相关的图像的选项。 (将有两种类型的图像,产品的拇指,然后是产品的全视图图像)。它应该处理至少一百种产品。
到目前为止,我正在考虑两种选择:
1)在db中存储图像 - 图像从Db加载到流然后加载到图像中(使用IHttpHandler显示)
赞成
- 图像本身是我们在后面的代码中使用的类,业务对象的一部分
- 维护产品数据的一个地方
缺点
- 内存消耗
- 当我们从其他API获取产品数据时,流量增加
2)将图像存储在文件系统中 - 图像作为链接放入页面中
赞成
- 没有影响内存,因为它没有存储在会话,app cache中。它像简单的链接一样使用
- 没有内存消耗
缺点
- 需要为文件系统中的图像保留一些名称约定(甚至可能是某些文件夹结构)
- 更复杂的图像维护
还有其他合适的机制吗?你会建议使用什么?
我个人更喜欢文件系统中的图像,但由于存在两个不同的位置,因此可能难以维护它。
感谢您的任何评论。 X
BTW:我真的可以想象,在某个阶段,该产品还会有一些视频或其他需要显示的媒体。在这种情况下,Db不是真正的选择,不是吗?答案 0 :(得分:4)
我制作了一个与此类似的系统。在我看来,页面加载速度胜过所有其他考虑因素所以我选择了“在磁盘上存储图像”选项。
将图像添加到系统时,会裁剪原始图像并将其调整为所需的显示尺寸以供浏览,同时还会生成缩略图。然后将三个图像存储到磁盘,原始图像,显示大小和缩略图。每个人都有为其文件名生成的GUID。
(想象一下在亚马逊上购物,当您浏览产品列表时,只有缩略图可见。当您检查产品时,会显示其显示尺寸,您通常可以再次点击图像以查看完整尺寸。)
我有一个看起来有点像这样的数据库表。
ID int, PK
FullSizePath varchar(128)
DisplaySizePath varchar(128)
ThumbNailPath varchar(128)
OriginalData BLOB
我将原始数据保存在数据库中,只是在文件服务器上发生意外并且图像被删除,因此可以重新生成它们。但是在页面请求期间,这些数据永远不会从数据库中提取。
答案 1 :(得分:1)
我认为两者的混合是最好的, 对于小的关键图像db是优选的 对于数量和大小较大的文件系统更好
答案 2 :(得分:0)
我猜你已经覆盖了任何东西。您可以将主映像存储在filesystem / db中,但是您可以以编程方式动态生成缩略图,这样可以减少一些磁盘空间。
答案 3 :(得分:0)
在你的例子中,在我工作的地方,我们倾向于将图像存储在磁盘上,然后在数据库中记录文件名。
然后,当您拥有产品的数据库时,您可以查找并动态加载每个产品的图像。
如果您有一个用于添加/删除/编辑产品的管理系统,这也非常好。
我认为它介于两个原始建议之间,如果您愿意,甚至可以将所有图像存储在同一目录中。
答案 4 :(得分:0)
如果您使用的是MS SQL 2008,则可以选择FILESTREAM feature。
这是要点,但你应该阅读整篇白皮书:
FILESTREAM是SQL中的一项新功能 Server 2008发布。它允许 结构化数据存储在 数据库和相关的非结构化 (即BLOB)要存储的数据 直接在NTFS文件系统中。您 然后可以通过访问BLOB数据 高性能的Win32®流媒体 API,而不是必须支付 访问BLOB的性能损失 数据通过SQL Server。
FILESTREAM维护交易 结构化和 甚至在任何时候都是非结构化数据 允许时间点恢复 使用日志备份的FILESTREAM数据。 保持一致性 由SQL Server自动完成 不需要任何自定义逻辑 应用。 FILESTREAM机制 这是通过保持 相当于数据库事务 log,有很多相同的 管理要求(描述于 “配置”中的更多详细信息 FILESTREAM垃圾收集“部分 稍后在本白皮书中)。该 数据库的组合 事务日志与 FILESTREAM事务日志允许 FILESTREAM和结构化数据 事务性恢复正确。