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.
Related
I am writing a new application at the moment and certain entities in the application have images (just used for display purposes on the website).
I want to host my application on azure later and I am trying to figure out whether it would be better to use Azure Blob storage to store all images or just store them in the DB?
What is better performance wise when loading the images on the website?
SQL: Controller -> DB -> VIEW
Azure Blob: Controller -> Webcall to Azure DB -> VIEW
Could someone please explain benefits of either solution to me so that I can make up my mind?
How you design your database storage scheme is subjective, but there are objective things to consider in your scenario. I'll address those, and leave the "which should I choose" to you...
Azure Storage blobs are designed for bulk "block" data (such as documents, images, etc). Something like SQL Database is designed for metadata (stuff you search/index/query).
Everything can be done via SQL Database, and you would only need to worry about SQL queries (and it sounds like that's something you're already familiar with). SQL Server (and SQL Database) have always had the ability to store binary content via its BLOB type.
While you can store your images in SQL Database, you will find that your database size increases considerably, vs just storing queryable metadata. And while SQL Database service allows you to scale your storage, you'll find larger scale in blob storage (up to 500TB) at a lower cost than SQL Database service. If you run SQL Server in a VM, then you'll still have storage cost (attached disks) equivalent to blobs, along with VM costs.
Storage blobs, by themselves, don't provide a query language - you will need to know the container and/or blob name. So, for optimum searching, you'll want a queryable database with your metadata (e.g. SQL Database).
If you store your images in blobs, and reference them via URI in your database, you will be able to query against your database, find the image's URI, and then read from blob storage appropriately.
Also note: With blobs, you'll be able to provide direct image URI access to, say, a browser or an app (even if the blob is marked as private), which allows you to then bypass your app tier when delivering binary (image) content to the end-user. Blobs may also be cached in the CDN, which you cannot do with SQL Database.
Which you choose is ultimately up to you; I simply provided the objective reasons to use each.
Much cheaper in BLOB.
You are also probably going the get faster transfer as BLOB. Now the initial lookup may be a little faster with SQL but for a large image I think BLOB would win. SQL is just plain not optimized for big stuff and BLOB is.
And you keep SQL free to serve up short stuff.
For every row which represents clients data (name, phone etc) need to save also 3 images. Is it better saving images to ftp or in sql db?
Images will be shown in bootstrap carousel.
(I'll use asp5-mvc6 with ms sql db)
I would say that if you have a very good infraestructure, save in the DB is better, and here is why I think that:
You can access it in the same way that your other data
No extra setups for serving the media
If you have multiple servers, your sync is done with the DB
But if you have a small app, with small server, putting the media in a folder and keep in the db a reference to the file is not the end of world, but if you have more than one server, remember you will have to replicate the file in the other servers as well.
I would say you should try both ways before making a decision.
Whats the advantage/disadvantage between storing files as a byte array in a SQL table and using something like Amazon S3 to store them? Whats the advantage of S3 that makes it so I should use that instead of SQL?
Pros for storing files in the database:
transactional consistency
security (assuming you need it and that your database isn't wide open anyway)
Cons for storing files in the database:
much larger database files + backups (which can be costly if you are hosting on someone else's storage)
much more difficult to debug (you can't say "SELECT doc FROM table" in Management Studio and have Word pop up)
more difficult to present the documents to users (and allow them to upload) - instead of just presenting a link to a file on the file system, you must build an app that takes the file and stores it in the database, and pulls the file from the database to present it to the user.
typically, database file storage and I/O are charged at a much higher premium that flat file storage
I need to get large data (~100MB) from sql server into app's sqlite once a day wirelessly.
App has json/restful webservice for other things, but figured this isn't possible as 100MB loaded into memory via json object would cause memory crash when I try to write json to sqlite.
I am now considering retrieving a file from url and saving it locally. That way data isn't loaded into memory.
The part I get fuzzy on is best way to get data, ie download a .sqlite compressed file or download a text file with prepared insert statements to an existing sqlite. Pretty sure the prior is best choice, but not DB savy enough to know what's possible on the sql server. Is it possible for a sql server to select data subsets and create a sqlite file? maybe it just needs to be scripted.
One thing to consider is the structrue of data on the sql server. I need subsets of data from several tables, not the entire tables. Example: SQL server houses 100 physical sites data, app is at site X today, just load site X data.
Am I on the right track or did a I miss an obvious solution?
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.