Re: Re: how to display images stored in DB*

> On Fri, 2007-03-02 at 22:53 -0500, markw@mohawksoft.com wrote: >> > On Fri, 2007-03-02 at 17:31 -0500, markw@mohawksoft.com wrote: >> >> > Your claim is that in ALL cases using a file system to store images >> >> > is preferable to using a database. As such, you claim that using a >> dB >> >> > for storing images is "bad" practice. >> >> >> >> That is fairly close to my professional opinion, yes. There is, of >> >> course, >> >> always the exception to any rule, but in general, I would call >> storing >> >> bitmaps in a database without a damn good reason, a bad practice, >> yes. >> > >> > Ah, you've changed your tune. Thanks for coming out. >> >> I haven't changed any tune what so ever. > > Uhm, ooooookaaaaaay dooookaaaaaaaay then. I guess it's a good thing that > the archives tell the real story... not to mention the readers of the > list don't exactly have short memories. > > Cheers, > Rob. Two things: First, I do want to apologize for being kind of a wise ass, I was just trying to be funny, but some of it proably came out as insulting. Anyway, to re-use an analogy. Using a wrench as a hammer is never the correct use of a wrench. Does that mean that I've never used a wrench as a hammer? No of course not. The same goes for the bitmap data in the database, I can't come up with a single valid engineering reason to do it, but there are exceptions that are still not good engineering solutions but given time constraints may be expedient. That being said, a good engineer will acknowledge that it is a sub-optimal implementation and fix it in the next rev. At its core, a lot of web guys don't understand "databases" or SQL in general. Using a database is different from designing one. Don't take this as a slam or an insult, fields of expertise force us all to specialize. Take me for instance, I know the HTML RFC, I know the PHP internals. (I've written a few extensions including a serializer), but the actual web code is something I'm not good at. I spend more time looking up function references than actually coding. I know a bit about what I'm talking about. SQL databases have some appalling behaviors under a highly active and dynamic data (a pretty low insert/update ratio) environment. As a rule, you should keep what ever does not need to be in a database out of the database. I've stated a good few reasons in the various postings. Take my advice or not, but rather than argue about it, take a good look at the internals of a database and really get to understand it, you'll come to the same conclusions.