当前位置：文江博客话题详情

SQL 中存储视频文件的 BLOB

发布于 2024-12-07 14:13:55 字数 107 浏览 0 评论 0原文

我希望有人能解释如何使用 BLOB。我发现 BLOB 可以用来存储视频文件。我的问题是为什么人们会将视频文件存储在 SQL 数据库的 BLOB 中？与存储指向视频文件位置的指针相比，有哪些优点和缺点？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

小…楫夜泊 2024-12-14 14:13:55

有几个不同的原因。

如果您在磁盘上存储指向文件的指针（大概使用 BFILE 数据类型），则必须确保每当文件在磁盘上移动、重命名或删除时数据库都会更新。当您存储这样的数据时，随着时间的推移，您的数据库与文件系统不同步，并且最终会出现损坏的链接和孤立的内容，这是相对常见的情况。

如果您在磁盘上存储指向文件的指针，则在处理多媒体时将无法使用事务语义。由于您无法执行诸如针对文件系统发出回滚之类的操作，因此您要么必须处理这样的事实，即您将遇到文件系统上的数据与数据库中的数据不匹配的情况（即有人将视频上传到文件系统，但在数据库中创建作者和标题的事务失败，反之亦然），或者您必须向文件上传添加额外的步骤以模拟事务语义（即上传第二个<>_done .txt 文件仅包含数量。

对于许多应用程序来说，如果您想避免向用户提供数据，那么让数据库提供数据是最简单的方法指向文件的直接 FTP URL，因为他们可以使用它来绕过某些应用程序级安全性，最简单的选择是使用数据库支持的应用程序来检索数据，数据库从文件系统中读取数据，然后将其返回到然后发送数据的中间层给客户。如果每次检索数据时都必须将数据读入数据库，那么将数据直接存储在数据库中并在用户请求时让数据库从其数据文件中读取数据通常更有意义为了它。

最后，像 Oracle 这样的数据库提供了额外的实用程序来处理数据库中的多媒体数据。例如，Oracle interMedia 提供了丰富的与数据库中存储的视频数据进行交互的一组对象 - 您可以轻松标记场景开始或结束的位置、讨论各种主题的位置、视频录制时间、录制者等。您可以将该搜索功能与针对所有关系数据的搜索集成。当然，您可以在数据库之上编写一个应用程序来完成所有这些事情，但是您要么编写大量代码，要么在应用程序中使用另一个框架。利用数据库功能通常要容易得多。

A few different reasons.

If you store a pointer to a file on disk (presumably using the BFILE data type), you have to ensure that your database is updated whenever files are moved, renamed, or deleted on disk. It's relatively common when you store data like this that over time your database gets out of sync with the file system and you end up with broken links and orphaned content.

If you store a pointer to a file on disk, you cannot use transactional semantics when you're dealing with multimedia. Since you can't do something like issue a rollback against a file system, you either have to deal with the fact that you're going to have situations where the data on the file system doesn't match the data in the database (i.e. someone uploaded a video to the file system but the transaction that created the author and title in the database failed or vice versa) or you have to add additional steps to the file upload to simulate transactional semantics (i.e. upload a second <>_done.txt file that just contains the number of bytes in the actual file that was uploaded. That's cumbersome and error-prone and may create usability issues.

For many applications, having the database serve up data is the easiest way to provide it to a user. If you want to avoid giving a user a direct FTP URL to your files because they could use that to bypass some application-level security, the easiest option is to have a database-backed application where to retrieve the data, the database reads it from the file system and then returns it to the middle tier which then sends the data to the client. If you're going to have to read the data into the database every time the data is retrieved, it often makes more sense to just store the data directly in the database and to let the database read it from its data files when the user asks for it.

Finally, databases like Oracle provide additional utilities for working with multimedia data in the database. Oracle interMedia, for example, provides a rich set of objects to interact with video data stored in the database-- you can easily tag where scenes begin or end, tag where various subjects are discussed, when the video was recorded, who recorded it, etc. And you can integrate that search functionality with searches against all your relational data. Of course, you could write an application on top of the database that did all those things as well but then you're either writing a lot of code or using another framework in your app. It's often much easier to leverage the database functionality.

回复收藏 0 原文