|
|
Posted by Norman Peelman on 01/27/07 00:02
AlterEgo wrote:
> Jerry,
>
> Regarding storing images in the database:
>
> 1. If one is looking for quick and easy (as in a hobby application), then I
> totally agree - store them in the database. If one needs to keep a scalable
> product life-cycle in mind, then I would not keep them in the database.
Not sure that I agree with you on this point. You CAN overload a
filesystem with too many files in any one directory. You must then
employ a software storage scheme (layer) just to keep things managable.
> 2. If this is a commercial or community driven venture, then it will have to
> scale if it is successful. If it is not successful, then it really won't
> matter.
How does keeping them in the database not scale?
> 3. Transferring binary data from the native file system is way faster than
> any SQL database.
I think that also depends. How many files in that 'full' directory?
> 4. File systems are more easily scaled than databases.
Managability (backups, keeping the database and filesystem in sync)
can become quite a bear. Keeping it all in the database means one backup
operation results in a complete entity that can be re-created without
problems. And, they can be zipped up to save space. You can achieve
zipped archives approx. 12% of the original size (that's including the
image data).
> 5. Automated image management utilities (for creating thumbnails, converting
> image formats, reading image meta-data, etc.) love working with file
> systems, but hate working with databases.
I don't know of any that are designed to work with databases. That
being said, I can load an image from a database, resize/manipulate it
with GD (maybe even with imagick - magicwand api) and send it out with
no problem, all without touching the filesystem.
> 6. Its far easier to distribute images to the "edge of the web" with
> companies like Akamai or Digital Island hosting the content close to the
> users.
>
> I guess what it really boils down to is: thousands of pictures or millions
> of pictures? hi res, low res, thumbnails, etc.?
>
Thousands or millions for me personally, I wouldn't attempt to manage
what databases were designed to do for me.
> -- Bill
>
>
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:w6OdnbneO9eyGyTYnZ2dnUVZ_uKknZ2d@comcast.com...
>> Mikee Freedom wrote:
>>> Good Morning all,
>>>
>>> New member to the list, hoping you might be able to give me some much
>>> needed advice.
>>>
>>> Basically, I have a client who would like to offer the ability for his
>>> users to have their own independent website at his domain. It is not as
>>> clear cut as that but as a generic description it will do.
>>>
>>> I know such services exist and I'm by no means emulating there's in any
>>> way. the specific purpose of the individual user sites is fairly
>>> specific, hence why he needs to get us to create it for him.
>>>
>>> In a nutshell, people will be able to sign up, make some configuration
>>> decisions, add some content, and have a website of their own that they
>>> will be able to upload photo's to. Lot's of photo's.
>>>
>>> The decision I was looking at making, was whether or not to create
>>> individual databases for each of the new users. If this was going to be
>>> a good idea or bad, or if it was dependent a little on further factors.
>>>
>>> I've only begun to plan the site but this idea popped in to my head and
>>> I was hoping someone could either say - "you ass, what are you
>>> thinking?"; or indicate it may be beneficial.
>>>
>>> My alternate option is to relate all content, photo's, albums, etc to
>>> individual users. This is cool I guess, but liked the idea of complete
>>> seperation.
>>>
>>> One specific question I had was, if I needed to search for a particular
>>> value in multiple databases is this going to be a pain in the ass, a
>>> terrible load on the server... or anything else that I may be
>>> overlooking.
>>>
>>> Conclusion :
>>>
>>> I like the idea of it, is it a good one?
>>> Are there considerations?
>>>
>>> Thanks everyone,
>>> Mikee
>>>
>>> p.s. if any of what I've written doesn't make sense please feel free to
>>> berate or ask for further explanation :)
>>>
>> One thing to consider here - the users. They'll be uploading their own
>> content. Does this include server-side scripts like PHP, Perl, etc.? Will
>> they need to create their own tables for anything? Will different users
>> have vastly different requirements?
>>
>> If so, I think you should go with separate databases for each user for
>> security purposes. Give each user their own userid and password and only
>> allow them access to their own database.
>>
>> As for storing pictures in the database - I do it regularly. MySQL
>> handles it quite well. I use mainly the InnoDB engine, so I also have
>> foreign key restraints, which I set up to not allow a picture to be
>> deleted as long as it's still being referenced. It also makes it easier
>> to reference the pictures - you don't need a filename. I just keep the
>> pictures in their own table for performance reasons and don't worry about
>> it any more.
>>
>> Not to mention making backups easier.
>>
I agree with Jerry completely. Although I use MyISAM tables normally.
I'm not a wizard at databases things at all. And Jerry hit on one point
that I think alot of people miss... keeping the images/binary data in
separate tables from the other data... very, very important. Using a
blob type field in any table definition automatically (and silently
mostly) converts all other fixed length fields to variable length fields
(at least in MySQL 4.?). ie: CHARS become VARCHARS.
Norm
Navigation:
[Reply to this message]
|