储存影像 - 网络桌面应用

相关： Storing Images in DB - Yea or Nay?储存影像 - 网络桌面应用

看完上面的问题后，似乎对图像存储与数据库的首选方法是存储在数据库中唯一的文件路径。但是，这些答案中的大部分似乎都集中在Web服务器上。

就我而言，我正在开发一个桌面应用程序，该应用程序将在Intranet中的多台计算机上使用。专用服务器将托管数据库，其中包含与在各种设备上执行测试有关的信息。

图像需要以某种方式存储在服务器上。在这种情况下，将图像存储在数据库中是否是正确的方法，甚至是唯一的方法？

优点：

备份仅限于数据库中。
无需打开服务器的文件系统到网络。
用于服务器信息访问的单一协议。
受保护的文件访问。（用户不能进去，并删除所有图像）

缺点

性能问题在未来如果有太多的图像。

编辑：如标签中所述，应用程序正在使用C＃/ .NET编写。如果在这种情况下将图像写入文件系统是一个选项，我可以使用一些帮助了解如何完成此操作。在下面的评论中详细阐述了一些内容，现在我假定一个MySQL数据库，尽管SQL Server 2008的FileStream功能可能会改变这种情况。

同样在我的情况下，图像会经常被添加，并且在此之后可以被认为是只读的，因为它们不应该被改变，并且将在需要时被读出。图像可能会很小（每个〜70K），而且我还在考虑服务器上的其他二进制格式存储，每个文件大约20K，我可能会应用相同的方法进行存储和检索。

来源

2009-12-07 Will Eddins

我认为答案是，有没有正确的答案。与编程（和生活）中的大多数事情一样，它取决于。

以下是DB存储的一些优点和缺点：

的观光

轻松备份，管理和应用程序中的数据一站式的
更少依赖你应用和更少的移动部件。 KISS原则
在1GB以下的小文件上工作正常。
嘿，它是一个数据库，所以可以在事务内完成保存，并在出现网络问题时回滚
Sharepoint和TFS将所有内容都存储在数据库中，并且工作得很好。 甚至大男孩做
安全性可以通过应用程序很容易控制，不涉及文件/文件夹的权限

缺点

吃掉分贝空间
潜在影响性能如果没有做好
如果总是存储大文件（> 1GB），那么这样做不是一个好主意，除非在SQ中使用Filestream L服务器2k8
要求你实施一个体面的缓存策略（尽管你可能会想要这个）
文件系统感觉比数据库更自然，更容易手动替换/查看文件。

我想当谈到你的情况，我会倾向于简单的存储在DB。

来源

2009-12-15 21:20:08

为了简化应用程序，我同意这一点。我绝对不会有超过1GB的文件......对于这个问题，任何超过25kb的文件的可能性很小（灰度超声图像压缩很好）。他们不可能在一年内使用1GB的数据。除此之外，性能不是一个大问题，因为会有很少的查询，其中大部分将在后台进行。 – 2009-12-15 21:57:43

如果我可以选择多个答案，我会，但这可能是我要去的。应用程序的简单性与任何数据的小尺寸相结合似乎并不能证明Web /图像服务器是合理的。如果表现是必要的，或者我有更多的数据，我可能会用pcampbell的方法去做，但Mark Ewer的经验似乎也指出这对我们的需求来说已经足够了。感谢大家。 – 2009-12-16 18:47:53

如果你可以使用SQL Server 2008，看看这个链接

Saving and Retrieving File Using FileStream SQL Server 2008

来源

2009-12-07 19:02:22

虽然还没有确定，但我认为他们倾向于MySQL，主要是由于成本。可能最多有两个人同时访问（读取或写入）数据库，可能有5-10台计算机连接到网络。 – 2009-12-07 19:26:27

多少图片，我们谈论？他们经常独特/更新吗？如果不是，你可以将图像打包到要分发给多台计算机的客户端上吗？

就我个人而言，我会避免将图像存储在数据库中，而是像您说的那样存储文件路径。

如果你已经完成了所有的其他类似的问题（This，this和this）读取，但都在问，如果这是一个好主意，那么也许你的问题很不同，这将是一个好主意。

来源

2009-12-07 19:10:10

图像是正在生成的测试结果的图像。在这个特定的应用中，它们是由正在测试的设备生成的超声波图像，因此图像必须存储在其他人查看测试结果时才能被其他人查看。所以是的，它们是独一无二的，许多图像可能会在应用程序的整个生命周期中添加。你可不可以详细说明如何在不存储本地图像的情况下使用“文件路径”方法，就像在我的应用程序中那样？ – 2009-12-07 19:14:59

我建议将这些文件保存在文件系统中的磁盘上，而不是数据库中。文件系统的文件，关系数据数据库等

通过Web服务交付

考虑通过宿主DB机器上的网络服务/应用程序提供这些图片到你的桌面应用程序。该应用程序的工作是只提供图像。使用ASP.NET应用程序在该机器上安装Web服务器。有一个.ashx处理请求并传输二进制映像。事情是这样的：

http://myserver/myapp/GetImage.ashx?CustomerID=123&ImageID=456

安全

如果内网安全是一个问题，这将是在那里你可以确保用户认证和授权的读取访问图像的点。审计线索也可以在这里实施。

文件系统的安全

关于对这些图像的安全性，考虑到NTFS为您提供了很多的措施，以确保只有那些谁被授权可以读/删除/放文件的要求。接下来的任务是定义这些角色并实现Windows安全组。

未来需要

这种方法可以让你安全地从Intranet上的任何地方消耗这些图像。也许这个应用程序在某个时候会被迁移到一个Web应用程序？客户在Web解决方案适合的情况下是否可以提供功能请求？

这可能听起来像是过度杀伤，而不是从数据库中读取blob，但从安全角度来看它很棒。考虑您的客户和患者对隐私和安全的期望。

<%@ WebHandler Language="C#" Class="Handler" %> 

public class Handler : IHttpHandler { 

public void ProcessRequest (HttpContext context) 
{ 
    //go to the DB and get the path for this ID. 
    string filePath = GetImagePath(context.Request.QueryString["ImageID"]); 

    //now you have the path on disk; read the file 
    byte[] imgBytes=GetBytesFromDisk(filePath); 

    // send back as byte[] 
    context.Response.BinaryWrite(imgBytes); 
}

来源

2009-12-09 19:32:21

我想过这种可能性，本质上是创建一个用于下载和上传图片的Web服务，只需确保所有引用与数据库保持同步即可。尽管如此，我仍然觉得这是一个更简单的解决方案，因为现在它增加了一个完整的Web服务器，而不是一个单独的数据库，以及只有Windows的可能需求。我不得不考虑的东西，谢谢你的想法。 – 2009-12-09 19:43:09

我没有得到安全性的说法。数据库中的安全性同样容易完成，并且通过您的应用程序实际上可以更容易地进行管理。如果我有一个图像垃圾负载，我不想管理文件存储上的文件权限。我希望我的应用程序能够处理安全性。我确实同意你的客户端应用程序不应该知道它是如何获取图像的，所以最好将它从物理上或逻辑层抽象出来。 – 2009-12-15 21:24:49

是否需要downvote？距离评论时间戳约1分钟。安全/日志记录/审计是答案中的一个特征。 – 2009-12-15 21:56:13

如果你正在寻找替代品，我的最爱之一是一个十行的HTTP POST文件上传处理器（PHP，.NET，Java等）+一个网络服务器。当脚本验证最大文件大小，并可能提取宽度为&高度时，它会在数据库中插入一行。检索不需要通过脚本。标准文件托管将起作用。这将需要你打开80端口。你不需要用SOAP或其他任何东西来复杂化。常规的上传处理程序可以完成这项工作。

接下来是WebDAV，沿着相同的路线。当然，用这种方法，你必须监视文件系统并相应地调整数据库。您可以使用轮询服务或挂接到文件系统事件。实际上，您也可以注入一个ISAPI筛选器或Apache处理程序来执行数据库更新。

您可以使用FTP。为ProFTPd添加一个扩展，它将更新数据库并保持所有内容同步。

很多避免将图像数据放入表格的方法。

如果您选择数据库解决方案，只需确保将BLOB分割为单独的表格。如果可以的话，单独的表空间/设备/分区。或者，使用Oracle并忽略我所说的一切。

来源

2009-12-11 01:32:37 pestilence669

幸运的是，没有用户需要删除1个条目，所以'DELETE FROM images'仍然不起作用。考虑到它是一小组使用该软件的测试人员，它更多的是防止意外事故而不是真正的安全，而不是直接对文件系统进行读/写访问。现在，他们没有服务器。没有Web应用程序。一切都在纸上，在这种方法中，仍然没有web应用程序，只将当前正在纸上的内容移动到数据库中，没有其他任何东西需要备份。因此，虽然我知道数据库中的图像不好，但我正在寻找如何防止它，而不是未来最糟糕的情况。 – 2009-12-11 16:17:52

我不认为这是图像存储的地方。选择最简单的方法即可。但是，如果证明是错误的，你应该有一个架构可以改变方法。

为了实现这个目标，我会将数据和图像存储都放在Web服务接口后面。选择一项技术 - 无所谓。所有对数据（和图像）的访问都是以同样的方式 - 通过Web服务。

通过这样做，您已将桌面应用程序的数据存储位置分开。桌面应用程序不在乎。它只知道某个地址的服务器可以获取数据。

然后将数据和图像存储在任何你想要的地方。为你选择最简单的事情。如果最终出现问题，那么（并且只有这样）才会增加额外的复杂性以解决问题。好消息是，额外的复杂性和工作完全不应该影响桌面应用程序。您可以在服务器上进行更改，而不必部署新版本的桌面应用程序。

来源

2009-12-11 17:00:02

从架构的角度来看，你会被拆分解决方案中获得最佳性能分为两个部分：数据库服务器，以及图像服务器。

这样做既可以保持较小的行大小，也可以将事务环境与内容分开。 SQL Server和mysql的关系数据库将支持大BLOB，但并未针对它们进行优化。

大多数人将“图像服务器”等同于“网络服务器”，因为它们在Web应用程序上工作，因此具有事实上的图像存储库（本地磁盘上的目录）。但是，这并不是就是。可以通过任何协议从任何位置提供图像。

您提到了C＃/ .NET平台和Intranet。我们可以假设一个Windows环境，可能是Active Directory？

如果是这样，普通的香草文件服务器可能是您的图像服务器。设置文件共享，为此应用程序的所有用户设置读取/创建（但不修改/删除）权限，将UNC路径存储在数据库的某处（因此，如果您决定重新部署应用程序，则不必重新部署应用程序重新定位它），并让您的客户端应用程序使用像Guid这样可靠的东西生成唯一的相对路径。

它不像Web服务那样优雅（这是我的首选方法），也不像纯数据库方法那样免维护，但是我对此主题的印象是您的预算紧张交付截止日期短，而且Windows或NFS文件服务器的设置和维护（包括备份）比成熟的Web服务器更便宜，更轻松，更快速，因此它可能正是您在此寻找的内容。

大多数企业已经有一个文件服务器，所以通常这不需要任何新的基础设施。但即使你不这样做，我也看到文件服务器在旧的翻新工作站上运行 - 这不是花哨的，但是在低流量的环境下它完成了工作。

如果您选择这种方法，我会建议在文件共享上使用某种目录结构来简化备份，归档等。例如：

\\ImageServer\MyAppRepository\yyyy-mm\{image-file-name-or-guid}.{ext}。

希望有所帮助。

来源

2009-12-12 00:16:54 Aaronaught

使用Amazon S3存储为您的图片

只是存储在数据库中

亚马逊的GUID或其他文件名是简单，快速，价格便宜。安全等等等等

它倍的罚款，并可以选择通过S3提供CDN像边缘服务直接

存储图像在DB似乎总是随着时间的推移变成一场噩梦

来源

2009-12-13 10:29:12 TFD

这些机器（包括服务器）都不能访问互联网，所以这似乎不是一种选择。 – 2009-12-14 00:10:23

在我看来，那是你想要做什么像Infovark做的事情。

他们用火鸟此，我给你一个链接火鸟storing image

来源

2009-12-14 22:28:45

我的公司开发了一个Windows窗体c＃应用程序，它将图像存储在数据库中，并且工作得非常好。自2003年以来，我们一直在积极使用它，并且在系统中拥有大约150个演出数据。

首先，让我说这不是最佳的性能架构。我们在保持数据库统计信息保持最新并保持索引正确调整方面遇到了一些问题。我们基本上不得不每月重新索引系统。您需要知道，大多数RDBMS服务器的内置优化系统未针对大型二进制对象集合进行设置。

我们选择将图像放入数据库的原因是因为数据库级复制。我们的系统分布在五个州的七个办事处，我需要将数据同步到每个站点。所以，我在每个站点和我们的公司办公室之间固定了一个VPN，并在数据库上设置了SQL合并复制。通过这种方式，我可以同时在办公室之间打开一个频道的同时同步数据和图像。所以，我想说在大多数情况下，数据库中的图像并不是最佳解决方案，但是它符合我们的要求。

来源

2009-12-16 15:41:21

你应该尝试MS SQl 2008，它带有一个Type：FileStream，它可以自动将blob存储在文件系统中。

来源

2009-12-16 15:43:51 Benny

储存影像 - 网络桌面应用

回答

相关问题