Re: Un Structured Data -- Sore In Side Database or Out Side Database?

  • From: Carel-Jan Engel <careljan@xxxxxxxxxx>
  • To: mssql_2002@xxxxxxxxx
  • Date: Tue, 06 Nov 2007 17:40:38 +0100

Bob,

A customer of mine had all their scanned documents stored in a directory
hierarchy on an NTFS filesystem.
At some time they tested a restore. Just restoring the directory
structure took over a week. They skipped restoring the data itself, it
was simply not feasable within a reasonable timeframe. I must say that
every doc was identified by a so called GUID. The GUID was cut into 8
parts, and those 8 parts formed an 8-level hierarchy in the directory
structure.
 
The 'metadata' of the docs was stored in an Oracle database. After
endless debates the software vendor agreed on a conversion from FS-based
to DB-based storage.
>From the start on it was a huge relief, much more scaleable, big
performance gains, better manageability, better restorability, no more
headaches about divergency between metadata and documents stored (no
more orphan docs, no more childless metadata rows).

Just one example, but good enough for me to at least consider  storing
inside the database.

Mind that a filesystem (directory structure) is not built/designed for
scaleable access of thousands (millions) of files by many, many
concurrent sessions. Espcially the write operations (insert) have a very
poor scaleability.

Just my EUR. 0.02,

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok)
===

On Tue, 2007-11-06 at 08:01 -0800, Bob Robert wrote:

> Gurus
> 
> Is there any best practice where to store unstructured data? Is it
> inside of the database or our side of the database? I know keeping in
> side DB would force to increase DB size very rapidly. Please comment
> based no your experience
> 
> Thanks
> Bob
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> --
> //www.freelists.org/webpage/oracle-l
> 
> 



Other related posts: