我已经在PHP中构建了一个小型Web应用程序,用户必须首先登录.一旦登录,我打算在他们的"个人资料"中显示一个小缩略图.
我必须确保图像低于特定大小以节省空间,或确保它是特定分辨率,或两者兼而有之,或者甚至可能使用像magick这样的图像来缩小它.
不知道最好的方法是什么,欢迎任何想法.
此外,我一直在努力研究如果最好将图像users作为blob 存储在MySQL表中,或者可能是一个images具有唯一ID 的单独表,并且只需将相应的图像ID存储在users表中,或者只是保存服务器上的上传文件(也通过上传页面)并将文件另存为theUsersUniqueUsername.jpg.最佳选择？
我在这里找到了一个关于将图像保存到mysql的教程:http: //www.phpriot.com/articles/images-in-mysql
我只是一个业余爱好程序员,以前从未做过这样的事情,所以很多人都非常感谢你们的例子和/或很多细节.
总是依赖于上下文,但通常,我将文件系统上的用户图像存储在一个被调用的文件夹中,/content/user/{user_id}.jpg并尽可能少地打扰数据库.
我建议将图像存储为文件,然后在数据库中包含文件URI.如果将所有图像存储在数据库中,则可能会在以后进行缩放时遇到一些问题.
看看这个答案:
对于速度和大小,Microsoft对SQL Server的建议曾经是在数据库中使用链接将图像存储在文件系统中.我认为他们已经稍微软化了他们的偏好,但我仍然认为这对于大小来说肯定是一个更好的主意,因为它不会占用数据库中的空间.
使用BLOB的开销远远低于大多数人认为的开销,特别是如果你设置正确的话.如果您使用单独的服务器运行数据库来存储二进制文件,那么您实际上根本不使用文件系统,并避免文件系统的任何开销
这说最简单/最好的方法,除非你有几个服务器自己将它们存储在文件系统中
不要将文件的绝对URL存储在数据库中,只存储唯一的部分(可能是一两个文件夹),例如2009/uniqueImageName.jpg或者只是uniqueImageName.jpg.然后在您的页面中只需将主机和其他文件夹添加到前面,这样您就可以灵活地移动图像 - 您需要更改的是PHP/ASP.NET页面中的一行或两行.
为了安全起见,不需要在文档根目录之外存储 - .htaccess具有DENY FROM ALL 的文件将起作用并提供更大的灵活性
没有必要"分流"图片这么多的安全,只是有一个getImage.php网页或东西,然后,而不是在插入实际的URL src的image,使用类似getImage.php?file=uniqueImageName.jpg.然后该getImage.php文件可以检查用户是否被授权并抓取图像(或不是).
使用其被保证是唯一的名称(优选即主键的整数)存储时,某些文件系统(即,Windows)中是不区分大小写的,所以JoeBloggs.jpg和joebloggs.jpg是用于数据库中是唯一的,但不用于文件系统这样一个将覆盖另一个.
为图像使用单独的表,并将图像的主键存储在users表中.如果您希望在将来添加更多字段或进行更改,则会更容易 - 这也是一种很好的做法.
如果您担心搜索引擎优化等问题,请在上传时将图像的原始文件名存储在其他字段中,然后您可以在输出中使用它(例如在alt标记中).
当然它依赖于上下文,但我有一个非常大的应用程序,在MySQL数据库中存储了数千个图像和文档作为BLOBS(平均大小= 2MB),并且应用程序在具有256MB内存的服务器上运行良好.秘诀是正确的数据库结构.始终保留两个单独的表,其中一个表存储有关文件的基本信息,另一个表应该只包含blob以及用于访问它的主键.所有基本查询都将针对详细信息表运行,而另一个表仅在实际需要文件时访问,并且使用索引键访问它,因此性能非常好.
在数据库中存储文件的优点是多方面的:
由于您不需要备份文件系统,因此需要更简单的备份系统
控制文件安全性要容易得多,因为您可以在发布二进制文件之前进行验证(是的,您可以将文件存储在非公共目录中并读取脚本并重新调整文件,但性能不会明显加快.
(类似于#1)它清晰地分离了"用户内容"和"系统内容",使迁移和克隆更容易.
更容易管理文件,跟踪/存储版本更改等,因为您需要更少的脚本修改来添加版本控件.
如果性能是一个大问题而且安全性和备份不是(或者如果你有一个好的fs备份系统)那么你可以将它存储在FS中,但即使这样我经常在数据库中存储文件(如果是图像)并构建一个缓存脚本,在第一次使用它之后将其写入缓存文件夹(是的,这会使用更多的HD空间,但这几乎不是限制因素).
无论如何,显然FS在很多情况下运行良好,但我个人认为数据库管理更容易,更灵活,如果写得好,性能损失也非常小.
我们创建了一个在DB中存储图像的商店.它在开发过程中运行良好,但是一旦我们在生产服务器上测试它,页面加载时间就太高了,它给数据库服务器增加了不必要的负载.
虽然将二进制文件存储在数据库中似乎很有吸引力,但获取和操作它们会增加额外的复杂性,只需将文件保留在文件系统上并在数据库中存储路径/元数据即可避免这种复杂性.
这是一场永恒的辩论,双方都有很好的争论,但是为了我的钱,我会把图像远离数据库.
我最近看到了这个提示列表:http://www.ajaxline.com/32-tips-to-speed-up-your-mysql-queries
技巧17:对于您的Web应用程序,图像和其他二进制资产通常应存储为文件.也就是说,只存储对文件的引用而不是数据库中的文件本身.
所以只需将文件路径保存到图像:)
我在之前的项目中实现了两种解决方案(文件系统和数据库持久化映像).在我看来,您应该将图像存储在数据库中.原因如下:
当您的应用服务器进行群集时,文件系统存储会更加复杂.您必须拥有共享存储空间.即使您当前的环境没有群集,这也会使您在需要时进行扩展变得更加困难.
无论如何,您应该使用CDN作为静态内容,并将您的应用设置为原点.这意味着您的应用只会针对给定的图像被点击一次,然后它将被缓存在CDN上.CloudFront很便宜且设置简单......没有理由不使用它.为动态内容节省带宽.
开发数据库持久化图像要快得多(因此也更便宜)
您可以使用数据库持久映像获得参照完整性.如果要在文件系统上存储图像,则不可避免地会有没有匹配数据库记录的孤立文件,或者您将拥有包含损坏文件链接的数据库记录.这将发生......这只是时间问题.你必须写点东西来清理它们.
无论如何,我的两分钱.
京公网安备 11010802040832号 | 京ICP备19059560号-6 