I am using AppHarbor for hosting my website and currently it offers only 20MB free space. I want to store PDF files using SQL Server's FileStream column. Would using FileStream increase the database size because FileStream basically stores on hard disk as I know.
Any help would be appreciated.
Because the FILESTREAM data becomes part of the database, in the sense that it has its own FILEGROUP(s) and can (should be) be backed up through SQL backups - I would answer yes.
No it does not increase the size of the database as the files are not stored in the Database.
Please read the following "FILESTREAM Design and Implementation Considerations" --google is your best friend
Related
I'm extremely confused, so I've created an SQL Database in Windows Azure, created a "video table" with a "video_file" column as "varbinary(max)" because I want to upload a video file into that field, however Azure offers no "Upload" option like say, PHPMyAdmin does where you can hit "browse" and upload a video directly into the field. Can anyone guide me as to how to actually upload a file into a Windows Azure SQL Database so it can be read as a varbinary type? Can it be done within the Azure management portal? Or does it require some sort of external program/service?
To answer your question, the functionality to upload files directly into SQL Azure Database does not exist. This is something you have to do on your own.
Can anyone guide me as to how to actually upload a file into a Windows
Azure SQL Database so it can be read as a varbinary type?
Do a search for uploading files in SQL Server and you will find plenty of examples on how to do that. Take a look at this link for example: http://www.codeproject.com/Articles/225446/Uploading-and-downloading-files-to-from-a-SQL-Serv
Can it be done within the Azure management portal? Or does it require some sort of external program/service?
No. This functionality does not exist in Azure Management Portal. As mentioned above, you would need to write some code to do so.
A little bit off-topic comment:
May I suggest that instead of saving the image files in the database you save them in Blob Storage and store the URL of the blob in your table. There're some advantages I could see in this:
Compared to SQL Database, Azure Blob Storage is much cheaper. If you store video files (or in other words large files) in the database, you will end up with large database and thus end up paying more money.
You will be choking the database when reading this large data from the database which will impact the performance of your application.
I have a webpage that stores Scanned PDF files. At the moment I store it in the Sql Database with as a varbinary.
I am redesigning everything from scratch and was thinking it may be more efficient to store the PDF's on the hard drive and just have a path..
The PDF collection, potentionally could get to 500gig+..
which is more efficient and what are the advantages either way?
Look into using FILESTREAM to store the files in a database-accessible way on the file system: Using FILESTREAM to Store BLOBs in the NTFS File System in SQL Server 2008
I would use a persistent store such as AmazonS3. It's cheap, replicated, and if you change your database technology at some point in the future, it will be fairly easy. Instead of storing the files directly in your database, store the URL of the PDF on your AmazonS3 storage.
I am about to create an ASP.NET MVC app which will have over 2000 products and each products will approx 20 photos. The app will be asp.net mvc app and
I am using sql server 2008 r2 to manage my data. which way is the better approcah here;
Uploading pictures to a path and
storing their file names to database
in order to be able to make a
relation to each other.
Storing pictures inside the database
as byte as well and retreive them
from there when needded.
definitely in the filesystem (store path) is better, i have done both in the past.
Against SQL server to store images
A) betting data in and out can be more difficult as have to used blob type objects and some ORMs don't really cater for this
B) your data base is much bigger so effects your backup/restore policy. The more frequently you backup the better but space will be increased. Storing in file, yep you still need to backup but backing up filesystem is easy.
C) when you run out of storage space you just add another NAS drive / server and start storing images there, so scales horizontally
The common perception is not as good as data stored in two places but for me its better as the type of data in stored in the best storage medium for the data types ..
Definitely storing as a path rather than the byte array. This means you can easily change the actual image itself without having to alter any code or muck around in SQL (as long s the new file has the same name as the old one).
Hope this helps.
In the database using FILESTREAM which combines the 2 ideas (file and database)
FILESTREAM integrates the SQL Server Database Engine with an NTFS file system by storing varbinary(max) binary large object (BLOB) data as files on the file system. Transact-SQL statements can insert, update, query, search, and back up FILESTREAM data. Win32 file system interfaces provide streaming access to the data.
This changes the file vs database arguments
If you want to store paths only, then you'll have to accept the fact that images and database will get out of synch over time.
Can anybody help me in understanding how to upload large files in SQL azure using block.
I am not able to find any good implementation of Blocks to upload files in SQL azure.
Thanks,
Ashwani
You may want to look at storing large files in Azure BLOB Storage. You will end up running out of size in your SQL Azure database, or put yourself into a more expensive SQL Azure price point, by storing files in your relational database. You can always store the pointer to your BLOB in your relational database.
how big (binary(xy)) should I make my table column in SQL database if I want to store there pictures taken by camera - that means variable size up to.. I don't know.. 7MB? But if I should rather limit the size up to 2MB or something, I would. Whats your opinion?
EDIT
Or where else should I store them? I am building a web gallery using asp.net mvc.
What you're talking about is a varbinary column. Of course, if you make varbinary greater than 8000, it immediately converts it into a varbinary(max) column, meaning it can store up to 2GB. This has to do with how SQL Server stores rows (8k per page).
Therefore, each row stores the column as a pointer to the bits, anyway. So, what I would do, if I were me, would be to store the images on the file system, and store the location of those files inside the database.
If you want to store images in SQL Server then use the varbinary(max) column type. It permits up to 2Gb (if I recall).
Also, as you are using SQL Server 2008 (I don't know about the express edition tho') you could use the new filestream data type.
Of course the big advantage of storing this in the database is that you only have one thing to back up and you don't have issues with the file system and database getting out of sync. The new filestream type is an interesting development because it can help alleviate these problems.
The disadvantage of storing this data in the database is that you put additional strain on the database, especially if the bandwidth between your database and webserver is already strained.
As others have already stated in comments (which BTW you guys should have been answers despite the pendantic police) you really have to have some killer reason to store images in the database. Otherwise just place them in the file system.
Especially this is true in the case where the images are delivered from a web server. The web server is way more effecient at delivering images from the file system than your code will be extracting them from a database.