PHP 与MYSQL - 我应该如何处理我的图像数据？
我正在创建一个博客，每篇文章都有一个特色图片。我陷入困境，我不确定如何处理我的图像数据...
我应该使用 BLOB 将图像数据插入到我的 MYSQL 数据库中吗？
或者我应该创建一个上传程序，在用户图像文件夹中创建一个目录并以这种方式上传照片...然后在添加博客文章时直接在图像字段中引用它？
有没有标准化的方法？
亲切的问候， 亚当
I'm creating a blog with a featured image on each post. I have a dilemma, I'm unsure what to do with my image data...
Should I insert image data into my MYSQL database using BLOB?
Or should I just create an uploader which makes a directory into the users images folder and upload the photo that way...then just reference it directly in the image field when adding a Blog Post?
Is there a standardised way?
Kind regards,
adam
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
将文件上传到您的服务器并将文件的位置保存在数据库中。对数据库的压力较小，并且 HTTP 守护进程比 MySQL 更能提供图像服务。
Upload the files to your server and save the location of the file in your database. Less strain on your DB and your HTTP daemon is better at serving images than MySQL.
一般的方法是不要将文件存储在数据库中，除非您明白为什么需要将其存储在那里。因此，由于您不确定，因此将它们存储在上传文件夹中要简单得多。
但是，万一您决定需要在数据库中存储文件（无论是图像还是其他文件），您必须声明 BLOB 字段，然后使用某种支持 BLOB 的数据库机制保存它。 'PHP 的 MySQLi 扩展：存储和检索 blob' 是一个很好的示例，说明了它是如何实现的制成
The general approach is not to store files in DB, unless you understand why do you need it to be stored there. So, since you are not sure, it's much simplier storing them in upload folder.
But, just in case you decide you need storing files (no matter images or some other) in DB, you have to declare BLOB field and then save it using some BLOB-supporting DB mechanism. 'PHP's MySQLi extension: Storing and retrieving blobs' is a good example of how it can be made
您应该将图像存储在文件夹中。单击下面的链接，您可以从中了解如何裁剪不同尺寸的图像并将图像名称存储到数据库表中：
如何以普通插入形式上传图像（MySql）？上传后图像应该有不同尺寸和不同名称的三个版本
You should store images in folder. Click on below link from where you can get idea how to crop different-different size images and store images name in to database table:
How can I upload images in a normal insert form (MySql)? after upload the image should have three versions of different sizes and different names
将图像数据转换为 base64。这可以在 PHP 中完成：
将图像存储在数据库中对于安全图像来说是一个好主意。
convert the image data to base64. This can be done within PHP:
<?$image=file_get_contents("image.png");
$image=base64_encode($image);
?>
Storing images in a DB is a good idea for secure images.
始终将图像、音乐文件等存储在磁盘上的系统文件中，然后将它们的 URL 存储在数据库中。这将使它
1) 更快
2) 更容易配置安全设置
3) 在我能想象的任何方面都更好
缺点
如果文件系统损坏，您将很难恢复。
您还可以使用第三方图像托管站点，可以使用 Amazon S3 或 Mosso Cloud Files。
文件系统的问题是难以扩展。
Facebook 使用 cassandra 来存储图像。
由于它是博客，因此您可以将图像存储在文件系统中。
Always store images, music files etc in system files on disk, and then store the urls to them in the database. That will make it
1) faster
2) easier to configure security settings
3) better in any ways I can imagine
Disadvantage
If file system is corrupted you will have hard time recovering.
You can also use third party Image hosting sites too, you can use Amazon S3 or Mosso Cloud Files.
Problem with file system is it is difficult to scale.
Facebook uses
cassandrato store images.Since it is blog you can store images in filesystem.
两者都是有效的方法。
它们有不同的优点/缺点。
将其存储在数据库中意味着您需要添加额外的代码来将图像更改为适合 INSERT/UPDATE 语句的表示形式（base64 是一种方法，并且需要等效的解码，但您可以只使用 mysql_real_escape_string()）。虽然您无法直接查询图像（除了查找精确匹配），但与在数据库中查找路径然后检索文件相比，它可能会减少检索数据所需的查找和 I/O 操作的数量。
如果您在多个节点上运行，则与设置数据库和文件系统的复制相比，设置数据库的复制要简单得多。还有保持文件系统和数据库备份同步的问题。
OTOH，使用文件系统可以使您的数据表变得更小，因此可以更快地检索记录。
您当然不希望允许用户将内容直接上传到您的网络服务器的文档树中 - 无论您采用哪条路线，数据都应该存储在网络服务器无法直接访问的位置，但通过您的代码可以访问。
Both are valid approaches.
They have different advantages/disadvantages.
Storing it in the database means you need to add extra code to change the image to a representation which will fit inside a INSERT/UPDATE statement (base64 is one approach, and requires equivalent decode, but you could just use mysql_real_escape_string()). Although you can't query the image directly (other than finding exact matches) it may reduce the number of seek and I/O operations required to retrieve the data compared with looking up the path in the database then retrieving the file.
It's also a lot simpler to set up replication of a database compared with setting up replication of the database AND the filesystem if you run on multiple nodes. And there's the issue og keeping filesystem and database backups synchronized.
OTOH, using a filesystem makes your data tables much smaller, and therefore faster to retrieve records from.
You certainly don't want to allow users to upload content directly into your webserver's document tree - regardless of which route you take, the data should be stored in a location not directly accessible by the webserver but accessible by your code.