Results 1 to 11 of 11
  1. #1
    Join Date
    Dec 2007
    Posts
    2

    What type of data should I not use RDBMS?

    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.

  2. #2
    Join Date
    Nov 2007
    Posts
    3
    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.

  3. #3
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    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.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  4. #4
    Join Date
    Dec 2007
    Posts
    2
    Thanks for the idea.

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

  5. #5
    Join Date
    May 2005
    Location
    San Antonio, Texas
    Posts
    134
    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.
    Vi veri veniversum vivus vici
    By the power of truth, I, a living man, have conquered the universe

  6. #6
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    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.
    Last edited by loquin; 12-03-07 at 14:40.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


  7. #7
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    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.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  8. #8
    Join Date
    May 2005
    Location
    San Antonio, Texas
    Posts
    134
    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.
    Vi veri veniversum vivus vici
    By the power of truth, I, a living man, have conquered the universe

  9. #9
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    there are no good reasons. sorry i was not clear.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  10. #10
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by amthomas
    but I would still appreciate reasons as to why it is good to store multimedia, specifically images, in a db.
    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.

  11. #11
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    Quote Originally Posted by sco08y
    ... my position that there are perfectly good reasons for storing binary data in the RDBMS is a minority position... 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.
    Well, it's also a position that the database vendors have a vested interested in supporting. They're not exactly unbiased.


    Quote Originally Posted by sco08y
    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.
    No, it's a file system. And, it's tuned to support file reads and writes.

    Quote Originally Posted by sco08y
    1. Interfacing with one DBMS is complicated enough. Interfacing with two adds more complexity, more limitations and more ways your application can fail.
    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.

    Quote Originally Posted by sco08y
    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.
    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...

    Quote Originally Posted by sco08y
    3. The only thing a file system is good at is copying files. And it's not generally even very good at that.
    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.

    Quote Originally Posted by sco08y
    6. Filesystems are designed for different parameters than DBMSs.
    Absolutely correct. They are designed for the efficient handling of files. Databases are not.

    Quote Originally Posted by sco08y
    6a. And let's also note that you can fine tune your DBMS far more than you can fine tune your filesystem.
    True. Although this has little bearing on the discussion.

    Quote Originally Posted by sco08y
    8. If you want your database to be stored on a partition, you have to guess how much space to reserve for the database
    true
    Quote Originally Posted by sco08y
    and the file system.
    also true.

    Quote Originally Posted by sco08y
    9. Scaling up your application becomes more complicated when you're scaling a DBMS and a file system.
    disagree

    Quote Originally Posted by sco08y
    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.
    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.
    Last edited by loquin; 12-18-07 at 18:03.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •