Re: Re: how to display images stored in DB
| From: | Børge Holen | Date: | Fri, 02 Mar 2007 23:30:27 +0000 |
| Subject: | Re: Re: how to display images stored in DB | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-249749@lists.php.net to get a copy of this message | ||
On Saturday 03 March 2007 00:00, Roman Neuhauser wrote:
> # borge@arivene.net / 2007-03-02 21:37:48 +0100:
> > However... 6000 small files (and a sub if obliged) I cannot see one heck
> > of a good reason NOT to hold storage in a database... Imagine the rotten
> > backup cyclus.
>
> I cannot imagine it. What was the problem?
No problem... Just ugliness... and some afterthought. The complete dataset
spread out over more than 6000 files instead of one. Using tar and bunzip2 on
the amount of files and at the same time.. also do a sqldump of all the rest
of the information... glue together and send it off to backup storage...
Just seems so .... someone put in a word.
If something happens now, I just rollback, no fuzz. Backup is scheduled once a
day and gives me all the safety needed to keep it live'n kicking.
Last time this "case" was up for discussion, I got the lecture from Richard,
whereas he gave me quite a few good pointers on the file storage subject,
witch I've implemented in my present and future project (Thanks Richard), but
see absolutely no reason to rollback over the previously mentioned project
with the images. It just doesn't fit the task at hand.
Use the tool fitted for the task and databases is _A_ tool, and a good one at
that, but even I can see many ways to missuse it, and the reason is simple;
The first thing one find if searching for many php file storage topics is
easy and even easier solutions to store images in a blob rather than the
filesystem witch actually requires some thinking.
So one should probably STRONGLY suggest otherwise if someone asks, but one
should not ban it, cuz is has its moments
--
---
Børge
Kennel Arivene
http://www.arivene.net
---