|
|
Posted by AlterEgo on 01/26/07 20:44
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.
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.
3. Transferring binary data from the native file system is way faster than
any SQL database.
4. File systems are more easily scaled than databases.
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.
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.?
-- 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.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstucklex@attglobal.net
> ==================
Navigation:
[Reply to this message]
|