All the books tell me why Database is better than file processing approach. It also tells me why relational database is better than other database. But in reverse, it did not tell me when should I not use RDBMS.
It sounds like RDBMS is always good. Any idea where I can get the information? Thanks.

RDBMS is used for databases that are going to be complex in future.They will use to make that simple.

if your database is so small and it has no complexcity then such kind of databases are not required to use RDBMS softwares.

I hope you got the answer if not post it more precisely, so that i can get your point.

Generally, any data can be stored in an RDBMS. The only "best practices" exception I can think of is that storing image data in an RDBMS is discouraged. Instead, the image is stored as a file on a drive and the location of the file is stored in the RDBMS.

Thanks for the idea.

I can understand the small database part, but why not image? Thanks.

databases are good at searching and retrieving information. You can combine and play with information to get what you want. This is all value data.. names, dates, number that all directly something that is referencable. (is that a word? hehe)

although you can store picture attributes (name, creator, size, colors...), storing the picture itself isn't very searchable.

are you ever going to do a query for the bits in an image?

01010111010101010010100101001010100101001010101001 0

Its just a 'thing' that you want to tuck away and retrieve. Although it is data, its not something you really index or search for. You can't search for 'pictures with carrots in them' unless you have stored text tags into the database. No system can recognize carrots in pictures and do a search.

I think some databases probably handle blobs pretty well, but each admin has to decide how to handle that for their circumstances.

Also, ref this thread from a VB sister site. Although slanted towards Visual Basic, the comments are generally applicable, no matter what front-end is used.

images in the database? lots of reasons. trust me.

I also had a situation recently were i did not need to persist a small amount of data for longer than 5 minutes and we did not have a sql server available. We used an in memory XML data store and had the current data dump written to a file.

rather than just 'trust'.. could you give examples. I don't mess with multimedia much so its new stuff to me, but I haven't run across reasons to do so. I have no done an extensive search of course since I don't need to store tons of data like that.. but I would still appreciate reasons as to why it is good to store multimedia, specifically images, in a db.

there are no good reasons. sorry i was not clear.

Well, everyone claims that there are no good reasons for storing images and such in the RDBMS. So I guess my position that there are perfectly good reasons for storing binary data in the RDBMS is a minority position.

Mind you, it's a position that every single DBMS vendor happens to agree with, given that they all took the time to add BLOB support. And I guess the developers of the SQL standard also agree with me, since they wrote up the BLOB specs.

All of the reasons to put images and such in the DBMS boil down to one fact: the filesystem is also a DBMS (technically, a network DBMS) and it sucks.

1. Interfacing with one DBMS is complicated enough. Interfacing with two adds more complexity, more limitations and more ways your application can fail.

2. Keeping two DBMSs in synch, especially when one of them has no built in capabilities for synchronizing with anything, adds more complexity to your application. You have to write code to find "orphans" and your code has to work around the fact that a file might mysteriously disappear.

3. The only thing a file system is good at is copying files. And it's not generally even very good at that. For example, it's easy to use JDBC to send a database request over a proxy without the application even caring. You can probably do that with your filesystem, but at the expense of more code complexity and you're going to have to configure two transports.

4. Filesystems are notoriously bad at locking. Unix, for example, has "advisory" locks. And if you want to integrate file system locking with DBMS locking, you get more code complexity.

5. Journaling is considered an advanced feature on file systems, and generally only applies to metadata.

5a. Speaking of which, the filesystem metadata is almost invariably useless baggage as far as you're concerned. And if you rely on it, for example, last modified dates, you get more code complexity.

6. Filesystems are designed for different parameters than DBMSs. For example, if you format a hard disk with NTFS, you expect that you can plug it in to another computer and it just works. It might have to share its on disk structures with drivers running on a different operating system written by someone else entirely. A DBMS can optimize its structures for one server written by one group running on one operating system using one binary layout.

6a. And let's also note that you can fine tune your DBMS far more than you can fine tune your filesystem. And if you're fine tuning your file system, you're doubling your work again.

7. A DBMS generally has utilities to handle backups. Now that you're using the filesystem, you have to synchronize two backup operations.

8. If you want your database to be stored on a partition, you have to guess how much space to reserve for the database and the file system.

9. Scaling up your application becomes more complicated when you're scaling a DBMS and a file system.

It certainly sounds easier to stash stuff in the filesystem, and for a quick and dirty solution, it often is. I've done it. Many times you really don't care too much if multimedia for a web site is kept in synch properly; you can write a quick script to delete orphans and if a web server doesn't find an image for whatever reason it fails gracefully.

But if you are concerned with the sorts of things people who use DBMSs are concerned with then a filesystem has all the weaknesses of a crappy DBMS.

Well, it's also a position that the database vendors have a vested interested in supporting. They're not exactly unbiased.


No, it's a file system. And, it's tuned to support file reads and writes.

No one is claiming that you end up with a less complex system. Although, from a front-end/coding viewpoint, it is often less complicated than assembling chunks of data and sending them to the database to store the blob, or the reverse when retrieving the blob.

Properly setting permissions on the file system can resolve most of these issues. I have worked with a proprietary system that adds a service which KEEPS the file system folders assigned to store the files set with the proper permissions...

Actually, it's very good at that. However, the database server has to cut the file up into chunks to even handle it internally, and it adds another layer, both of which slows down file access substantially. Adding a third party caching app CAN help here, albeit at the expense of system cost and complexity. (plus, the caching app will probably be storing the files locally as ... files ... using the ... file system.

Absolutely correct. They are designed for the efficient handling of files. Databases are not.

True. Although this has little bearing on the discussion.

truealso true.

disagree

Again, the two are apples and oranges. They are designed for two separate purposes. Although a database CAN be used to store files, that does NOT make it the best choice for that purpose. Weigh out the advantages and disadvantages of each, and make your own decision. If the files will be small, under the internal buffer size of the database in question, then there won't be much of a performance hit involved in storing/retrieving the file if it's stored inside the file system. If it's larger, you'll need to weigh the inefficiencies against the benefits for each approach.