Performance 具有二进制数据/图像的表中的性能

我做了一个人员维护屏幕。客户希望我将每个人的照片存储在数据库中，我做到了毫无问题。我有一个单独的图像表，有两个字段，Id_person和Image

我有点担心，因为这是我第一次在数据库中处理图像。当表增长超过1000/5000个图像时，是否会出现性能问题？我想每个图像的大小都会有所不同。我确信我需要控制用户不会在数据库中保存非常大的图像

什么是合适的尺寸限制？客户只需要脸部的照片，但我相信有人会尝试使用“最新型号”的全质量照相机拍摄照片；）

---

谢谢。

通常最好保留一个图像文件夹，数据库只引用该文件夹。理想情况下，每个人都有一个唯一的ID，“images”文件夹中的文件与该ID匹配

如果你真的想直接存储二进制数据，你可以用8KB的JPEG（大约250x250像素，质量为25%）得到一张质量合理的照片。当然，这对于打印来说是不可接受的，但是对于识别来说是可以接受的

---

只有您才能知道是否可以接受数据库服务器中每行额外的8KB。

如果您绝对必须这样做，我会说将其限制为每行仅几KB。然而，世界上的每个数据库管理员都可能会告诉您，将图像填充到数据库字段中是一个非常糟糕的主意。最值得注意的是，当数据库文件的大小超过2GB时，性能会急剧下降

我更愿意按照杰丁斯说的做，在一个文件夹中，每个人的ID都是文件名，然后在网络共享上使用标准的.jpg或其他东西，这样所有使用该应用的计算机都可以访问这些图像

有些人发现，如果照片需要删除或存档，简单地使用ID是不够的，在这种情况下，他们会将NVARCHAR（MAX）字段放入数据库，并存储图像的网络文件路径，而不是实际图像

---

如果您的客户绝对无法拥有网络共享路径，我只会对图像进行blob。只要它位于ID为的单独表中，blob-only就不会有任何性能问题，但另一方面，我更喜欢在DB中仅对hdd上的文件进行引用（如果它是唯一的用户照片，那就更好了，因为ID为1的用户访问/images/1.jpg，所以你不需要参考）

我完全同意您的意见……但客户希望将图片保存在DDBB服务器中。是的……我只是添加了一点文字来解决这个问题。我将使用jheddings参数和备选方案来说服客户。是的，您需要限制文件大小，以防止人们直接从服务器上传全尺寸图片ra.但是，在现代系统上的任何现代数据库上，大表/表空间都不是问题。事实上，微软研究院的一项研究表明，对于小于256KB的数据，最好让数据库管理存储，而不是文件系统（Research.Microsoft.com/pubs/64525/tr-2006-45.pdf）.即使他们的发现偏离了2个数量级，也就是64KB。