Taco - There are quite a few Enterprise level CMS / Document Management Solutions that store binary files within the database itself.
I know for a fact that Stellent does, and I'm pretty sure LiveLink does as well. Obviously for images in a CMS it's a tad of an overkill, but when you start handling some serious document management, it's a good idea. Obviously as well, you'd be looking at only Enterprise level DBs, so Oracle, SQL Server (pref. Ent) etc. It's not all that complicated to get stuff out - it's just a bit more low level than alot of developers tend to get. Mark ------------------------------------------------------------------ E: [EMAIL PROTECTED] W: www.compoundtheory.com ICQ: 3094740 Quoting Taco Fleur <[EMAIL PROTECTED]>: > > Hi Brett, > > I guess images was a bit of a bad example, even if it was now "not so bad" to > store images in the db it certainly would not be a good idea to store images > in the db that are used in a websites design and serve them upon each > request, my question was more in general (and excluding this scenario). > > -----Original Message----- > From: Brett Payne-Rhodes [mailto:[EMAIL PROTECTED] > Sent: Thursday, 17 June 2004 1:29 PM > To: CFAussie Mailing List > Subject: [cfaussie] Re: Storing binary data in the database > > > Hi Taco, > > Fom the little I understand, part of the problem is the underlying issue > of what the DBMS does in terms of diskspace management. Traditionally > records were made up of lots of small elements like numbers, dates, and > strings, and the space management routines were designed with this in > mind. Once you start adding blobs and large text fields it is difficult, > if not impossible, for a DMBS to keep the data elements for each record > together in one place so that they can all be read in one disk 'read'. > > Now, I did say 'traditionally'. Maybe things have moved on with DBMSs so > that they can cleverly manage the impact of blobs, and lets face it the > speed of servers now is such that the issue may not be worth > considering. I haven't really kept up... But my gut feeling would be > that for a busy website with lots of pages and images and lots of hits > you wouldn't want your images in the database unless you had a *very* > good reason to do so. > > HTH > > Brett > B) > > > Taco Fleur wrote: > > I have always read that storing images/binary data in the db is bad - I > > always believed it, but is it really bad? > > Did it maybe get a bad reputation because it is a complicated subject? > > Was it true for Access and pre MS SQL 2000 only? > > > > Has anyone done any benchmarking to see how much slower it is to > > retrieve the image from the db instead of the filesystem? > > > > Are there any other disadvantages in storing it in the db? > > - Slower than the filesystem ? > > > > What are the advantages? > > - Full-text searches on the documents > > - Central repository > > - More secure > > - etc. > > > > --- > > 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/ > > > > Register now for the 3rd National Conference on Tourism Futures, being held > in Townsville, North Queensland 4-7 August - www.tq.com.au/tfconf > > > > > -- > Brett Payne-Rhodes > Eaglehawk Computing > t: +61 (0)8 9371-0471 > f: +61 (0)8 9371-0470 > m: +61 (0)414 371 047 > e: [EMAIL PROTECTED] > w: www.ehc.net.au > > > --- > 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/ > > Register now for the 3rd National Conference on Tourism Futures, being held > in Townsville, North Queensland 4-7 August - www.tq.com.au/tfconf > > --- > 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/ > > > --- 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/
