There are many times that I wanted to save an image to an SQL Server. I have read some practices for saving images :
1) upload and save image to server, save the path inside the table
2) save image as binary
3) save image as base64 string
4) using BLOB(i haven't researched how it works)
Do you know which "way" is faster when you request from server an image?
Do you know which "way" is better so as not to make SQL server slower?
Do you know any other "way" which is better from the above?
Thanks!
Microsoft has done some research on this topic and has concluded that it depends on the size of your image. If most of your images are < 256Kb, you should probably use VARBINARY. On the other hand, if they are above 1Mb, then you should use a FILESTREAM (which is usually stored on the filesystem outside the database file).
If your images are linked to other data, it's often useful to separate the records itself from the images into different tables (i.e. create an Images table) so that the table with the data remains small and easy to manipulate.
Pls note that there is no “best” way universally but only the one that suits your specific need the most.
“Do you know which "way" is faster when you request from server an image?” – in this case #1 because you essentially store image in the file system and only retrieve image path from database.
“Do you know which "way" is better so as not to make SQL server slower?” – again #1 because it has to deal with less data. It’s easier for SQL Server to retrieve varchar representing path where image is stored than to retrieve the image itself in whatever form.
No.1 is the simplest and probably easiest to setup but pls note that there are disadvantages:
if some image is deleted from file system SQL Server doesn’t have a clue that this happened
When you delete row from SQL Server you also need to delete image from file system (if you want to keep things clear ;))
You also need to backup data from file system and not only SQL Server database
Related
Can anyone advise in detail what does the varbinary(max) value represent if say a BLOB file (.pdf) is stored in the file system through the filestream attribute in sql server?
And how does it get copied across databases on different servers by using the usual T-SQL queries?
Many thanks.
Best regards,
Storing BLOB data using a FILESTREAM setup enables you to store your documents on disk while keeping your document's reference information in the database. Sometimes it is advised to use this approach if your file storage solution is cheap while your database storage is not, but it really depends on your requirements.
If you are working with small BLOB files, it might be better to leave the FILESTREAM setup alone as it comes with some overhead configuring and maintaining this. For instance in your comment's example to copy over data from one server to another.
I am developing a system where I will be saving many images (approximately 100+). I researched and I've known that saving many images to the database will make the database's size grow immensely. So I am thinking of doing what many recommend which is to save the path or location of the image. But I'm afraid it is not applicable especially I am doing a thesis. What conflicts will I encounter if it is just the path that is being saved? Will I still be able to retrieve the image when I publish the system?
Thanks!
Heres an article on how to store images in an image field within a SQL Server database:
Insert Picture into SQL Server 2005 Image Field using only SQL
And heres an interesting article on why / why not store images in a DB:
Insert Picture into SQL Server 2005 Image Field using only SQL
I would suggest keeping these seperate though and accessing the image on a file system by only storing the path to the image in the DB, unless the images are sensitive. Easier to encapsulate images in a DB but then space increases and so does cost.
When saving the path to an object only, you are effectively disconnecting the object from the pointer to the object. So you can't use SQL to manage the lifecycle of the object and you would never be sure that the object exists on the file system till you tried to read it. If the object was stored within the database then you know it's present if the record is present.
There are many pros and cons to managing your objects inside or outside of the DB. You probably need to weigh up the estimated size of your objects.
Bill Karwin's SQL Antipatterns book has an excellent chapter on this exact design pattern.
So I was making a new connection to an MS SQL server using the wizard and realized I don't know REALLY why it has me save these ODC connection files.
So, what are they and why does Excel create them?
Further, what happens to these files once when I change the connection from just selecting a table, to a custom SQL statement I have created?
Does anything change in these ODC files? I know sometimes it complains that if I make a change it will no longer match what is stored in the file.
edit:
I decided to look into one of my ODC files and it is HTML combined with some XML tags and then even a little JavaScript. So that is interesting. Still not sure how Excel uses these files instead of just storing that data itself. I guess to provide connections to multiple workbooks.
I think the idea is that you can share these files. You could put an odc on a network share or on SharePoint, have multiple workbooks use the odc file, and if any updates were necessary (like the database moved), then you only have to change it in on place.
Also, if you double click the odc file, it will create a new workbook with that connection and a table. I guess that could be a lean way of sending a workbook that consists of only an external data table to someone with access to the same connection. I haven't used that myself, but, you know, theoretically...
Why did they choose this as the default? I don't know. I wouldn't have. I would have chosen to have the data stored in Excel, but still have the ability to Export an odc for those that want to go that route. I'll bet the vast majority of external data tables have an odc sitting in My Documents and the user isn't even aware of it.
But pre-tablet MS Office seemed to base their design decisions on what their biggest clients wanted. And since there really isn't a cost to the average user (other than warnings they may not understand), why not.
I have a requirement to store image data in SQL Server along with data sync with master database.
I explored few options on many blogs and most of them say it's always better to store an image URL instead of a full image. Even I agree with this as it reduces the load on SQL Server engine. But this approach is not easy if I need to do data sync regularly.
So I am thinking of storing the images as varbinary(max). Is that a good idea?
It is apparently true that IIS serves up images from the file system (ie from a URL) much faster than images can be retrieved from Sql Server and then rendered in code however it does work ok. We store images in a varbinary(max) column as we cannot store them in the file system for similar reasons to you.
I am using T-SQL and Microsoft Management Studio 2008 R2. I want to create a database in which I can store video files.
After google search and some reading I have learned that there is a option to use "File Stream Enable Database". It was said that this kind of database should be used only when your files are larger then 2MB. I want to store video files, so I think this is suitable for my goals.
Please, give me more information about the main difference in using BLOB and FileStream Enable database or just to store the files in a given directory and to save only the url in the database table column?
Thanks in advance.
Filestream was an interesting change when it came in for me; the bit that suprised me was Full Text Search was taken out of the operating system because it caused issues; but file stream put it back because Blobs caused issues.
Using Filestream is basically transparent to your application and it even backs the files up as if they were in the database - and thats the big benefit or cost over the save in database v save pointer in database.
You can insert files the same way as you did before and you can read them back in SQL in exactly the same way. The difference and benefit is that that SQL can take advantage of Windows system cache for reading and files saving its own resources to make other queries run quicker.
Please, give me more information about the main difference in using BLOB and FileStream Enable
database
The feature you call for is "FileStream" not "FileStream enable".
Some blogs are also around, like http://blogs.msdn.com/b/rdoherty/archive/2007/10/12/getting-traction-with-sql-server-2008-filestream.aspx
At kleast try reading the documentation before running around and have other people do your basic groundwork.