I would probably concur on this one.

I've been around Oracle doing it, and I would be happy in that
situtaion, but I've never had any experience with SQL Server storing
data in the DB on a large scale project - so, maybe not. (So check it
out with someone who knows SQL Server)

That being said - you could do something like a combo -

For your workflow issues, store it in the db - but for distribution to
the wider audience, 'publish' it somewhere, so they can download it.

Also comes down to development time.  Doing it on a file directory
could be alot easier.

Just some thoughts.

Mark

On Fri, 23 Jul 2004 16:41:52 +1000, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> On Fri, Jul 23, 2004 at 04:07:34PM +1000, Carl wrote:
> 
> > Just having some interesting conversations...
> >
> > Use a directory structure or store it into the database?
> >
> > Just want to get some input on what is better, safer, easier to code,
> > and easier to manage (just thinking of the cost of getting more db space
> > compared to disk space, as some of the videos are 4mb a piece and there
> > is normally 25 per customer, and there can be up to 500 customers or
> > more at any one time)?
> >
> > We have PDF docs and videos that get embedded into pages (pdf directory
> > sits below webRoot and video sits above webRoot), some say that having a
> > directory structure is better, but others say put it all into the DB as
> > this is more secure, but others say this is slower...
> 
> There are databases specifically designed for storage and retrieval of
> files. They're called filesystems. NTFS. Fat. EXT. XFS. etc.
> 
> Storing files in tables is usually a bad idea for various reasons.
> 
> - can the DB accept a binary file without converting it to a text
> structure? if not you've got significant overhead both in conversion
> time and size bloat
> 
> - dbs often store large data blobs in external files, ergo more
> overhead
> 
> - how does the db handle reclaiming deleted space? At least one
> db I'm aware of won't reclaim deleted blobbed items without
> an exclusive table lock. *not* pleasant on a 24x7 system.
> and if you've got heavy updates (ie: insert, change, delete)
> the disk usage is going to go balistic. Trust me on this one... ;)
> 
> I'm sure there are good and valid reasons for storing binary
> files in databases. But I haven't yet seen any that overcome
> the problems.
> 
> Cheers
> 
> Paul Haddon
> Technical Services Manager
> Formstar Print Technologies
> 
> 
> 
> 
> ---
> You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to [EMAIL PROTECTED]
> Aussie Macromedia Developers: http://lists.daemon.com.au/
> 


-- 
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740

---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to