将图像上传到新数据库而不是使用应用程序的数据库

发布于 2024-10-24 06:52:16 字数 125 浏览 3 评论 0原文

我正在使用 SQL Server 2000。我需要在数据库中存储图像。我正在分析是否需要在应用程序的数据库中创建一个新表,或者是否需要创建一个仅用于图像上传的新数据库。如果我在同一个数据库中创建新表,性能会如何?会影响应用程序的性能吗?

I am using SQL Server 2000. I need to store an image in my database. I am in middle of my analysis that whether I need to create a new table in my application's database or I need to create a new database for image upload alone. If I create new table in the same database how the performance will be? Will it affect the application performance?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

一指流沙 2024-10-31 06:52:16

通常将图像存储在数据库中是一件坏事。您是否考虑过将图像存储在文件系统中并仅将其位置存储在数据库中?文件系统旨在存储文件,因此避开它们并使用数据库几乎没有什么优势。

Usually storing images in the database is a bad thing. Have you thought about storing the images within the file system and only storing its location within the database? File systems are designed to store files, so theres little advantage to side-stepping them and using the database.

谁把谁当真 2024-10-31 06:52:16

微软研究院有一篇非常好的论文,名为To Blob or Not To Blob。

他们经过大量性能测试和分析后得出的结论是:

  • 如果您的图片或文档大小通常低于 256K,将它们存储在数据库 IMAGE 列中效率更高(从 SQL 开始) Server 2005,IMAGE 已弃用 - 请改用 VARBINARY(MAX))

  • 如果您的图片或文档大小通常超过 1 MB,将它们存储在文件系统中效率更高

  • 在这两者之间,取决于您的使用,这有点难以抉择

如果您决定将图片放入 SQL Server 表中,我强烈建议使用单独的表来存储这些图片 - 不要将员工照片存储在员工表中 - 将它们保存在单独的表中。这样,假设您并不总是需要选择员工照片作为查询的一部分,那么 Employee 表就可以保持精简、简洁且非常高效。

对于文件组,请查看文件和文件组体系结构了解简介。基本上,您可以从一开始就为大型数据结构创建具有单独文件组的数据库,或者稍后添加其他文件组。我们称之为“LARGE_DATA”。

现在,每当您要创建一个需要存储 IMAGE 列的新表时,您都可以为大数据指定此文件组:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

查看有关文件组的 MSDN 介绍,并使用它!

There's a really good paper by Microsoft Research called To Blob or Not To Blob.

Their conclusion after a large number of performance tests and analysis is this:

  • if your pictures or document are typically below 256K in size, storing them in a database IMAGE column is more efficient (as of SQL Server 2005, IMAGE is deprecated - use VARBINARY(MAX) instead)

  • if your pictures or document are typically over 1 MB in size, storing them in the filesystem is more efficient

  • in between those two, it's a bit of a toss-up depending on your use

If you decide to put your pictures into a SQL Server table, I would strongly recommend using a separate table for storing those pictures - do not store the employee foto in the employee table - keep them in a separate table. That way, the Employee table can stay lean and mean and very efficient, assuming you don't always need to select the employee foto, too, as part of your queries.

For filegroups, check out Files and Filegroup Architecture for an intro. Basically, you would either create your database with a separate filegroup for large data structures right from the beginning, or add an additional filegroup later. Let's call it "LARGE_DATA".

Now, whenever you have a new table to create which needs to store IMAGE columns, you can specify this file group for the large data:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

Check out the MSDN intro on filegroups, and play around with it!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文