Last post Dec 29, 2010 03:24 AM by Stuart G
Dec 10, 2010 08:40 PM|showme18187|LINK
Hi every Body ,
this is my first Post ..
Which is better and why ??! preformance wise
-save image to table in database.
-save image to folder in my server.
what are advantages and disadvantages of using any of them? including (performance, size).
what are the cases and i which cases i should use one of them?
save image to database or folder (preformance Issu)
Dec 10, 2010 09:26 PM|DigiMortal|LINK
Saving image to database means that it is easier to backup your site content. But it is costs more in means of performance. If you are beginner then I strongly recommend you to keep your images on hard drive. Although I can handle site performance problems
I still don't want to keep files in database. You have to take care about queries and you must very carefully handle these files, their reads and updates. The larger the file the more it impacts server performance. Keep files on hard drive and live happy life
Dec 11, 2010 09:36 AM|sachingusain|LINK
I would say that you must not save any content (files) in database. It will definitely hit your database performance in the long run.
Managing content can be done through professional s/w packages like IBM FileNet, EMC documentum, MS Sharepoint, Opentext, Drupal, Alfresco etc. If your organization can afford it then go and implement it.
Dec 12, 2010 05:28 AM|DigiMortal|LINK
There is one situation where you may need some central storage for images - if you have more than one server for web front-end. This is why SharePoint keeps everything in database - there is one database that is used by all web front-ends that serve same
site. You can still use file system in this case but then it is time to start working out your own solution that scales.
Dec 12, 2010 08:01 AM|huttye3|LINK
Images in the database is really not a good option. I would suggest using the power of an operating system to capitalize on storing images as files in the file system. I have something very similar and was debating on database vs. file system and with all the
time invested I found out that storing them as files are the best.
if you are dealing with a lot of image files, you can have a dedicated class or a function in your application that generates path of the file where the image file needs to be stored and you can store this path as index in your database for fast access.
There are various ways you can structure the folders, alphabetically, or folder names starting from 00 to 99 etc.
Hope this helps!
Dec 29, 2010 03:24 AM|Stuart G|LINK
Pros and cons to both that go beyond performance.
- Can backup easily. Your data is still all in 1 place. If your images are considered "data" then it helps in disaster recovery to have them in the same place
- Update, insert and delete scenarios are managed in a single query. You don't have to worry about transactions to wrap disk writes and DB inserts as they can be in the same operation
- If your number of images gets very very big, then lookups will actually be faster in the database than on disk. (see below that loading image data will be slower).
- Auditing is possible to a point in time. If you restore a DB for an audit, you will also have the image at that point in time.
- Your database will get a LOT bigger. If the images are raw or large, this might even require partitioning or a seperate database to make it managable
- Performance to load an image will be slower. This can be countered with caching if you are in a product type scenario where some images are requested a lot more than others
- Database backup processes will take longer and be larger files
- If you're using earlier than SQL 2005, managing blob data can be painful
I have actually done both a lot. If the images are small (like a forum avatar for a user), then I will use the database and caching to make it work really well. I've also had transactional limitations in the past in a scenario like prescriptions for purchase
of drugs where it is essential that any disaster recovery or rollback be absolutely concurrent. Can't roll back or audit the data a week before if the prescriptions stay current. That was actually a legal requirement.
Privacy reasons can also mean that an image should be deleted when a user record is deleted which is a good argument for using the DB. Even facebook had problems with this lately by using disk storage meant that the image was visible long after the user
had deleted reference to it.
Make sure if you are using the database you counter performance loss with caching if you expect high traffic. Also avoid putting the binary data for the image in your model or store it in a seperate table so it is not being queried every time the parent
record is. This will be extra important if you are using Entity framework or linq 2 sql. You will also put an extra load on the DB backup process, so make sure you know what you are doing for your disaster recovery.
There's a lot more to it than just performance. Hope that all helps.