Database structure decision

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 :)

Message-ID: <1169763927.138077.147690@m58g2000cwm.googlegroups .com> from
Mikee Freedom contained the following:

>
>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.

A relational database management system is designed and optimised to
handle related data. And you want to split it up into separate
databases because you 'like the idea'?

Beats me why you think that might be a smart move.

And /please/ learn how to use the apostrophe.

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Mikee,

I would put all users in the same database. Less maintenance, less problems.
You can always scale up or out if the site is successful. With multiple
databases, the more successful the site, the more maintenance and headaches
you'll have.

BTW, don't store the photos in the database, store them in the file system.
Use a hive folder structure based upon parts of the file name.

A
--AA
--AB
----ABA
----ABB
----ABC

Also, make sure you have a good backup and recovery plan for the DB and file
system as well.

-- Bill


"Mikee Freedom" <mikeefreedom@gmail.com> wrote in message
news:1169763927.138077.147690@m58g2000cwm.googlegr oups.com...
> 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 :)
>

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
==================

On 26 Jan, 04:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> 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.
> jstuck...@attglobal.net
> ==================- Hide quoted text -- Show quoted text -
Hi Jerry,
something I've been wondering about for a while is how, if pictures are
all stored in a database, one would go about displaying them on a page.
Would they be written out to temporary files with unique names ina
directory somewhere and then <IMG... tags written out pointing to them?
If so, how would you know when it was safe to delete the temp files?

Captain Paralytic wrote:
>
> On 26 Jan, 04:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> 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.
>> jstuck...@attglobal.net
>> ==================- Hide quoted text -- Show quoted text -
> Hi Jerry,
> something I've been wondering about for a while is how, if pictures are
> all stored in a database, one would go about displaying them on a page.
> Would they be written out to temporary files with unique names ina
> directory somewhere and then <IMG... tags written out pointing to them?
> If so, how would you know when it was safe to delete the temp files?
>

Nope, just a small PHP program to retrieve the data, send the
appropriate header and then the file. Then the img statement just
refers to the PHP code.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 26 Jan, 12:47, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Captain Paralytic wrote:
>
> > On 26 Jan, 04:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> 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.
> >> jstuck...@attglobal.net
> >> ==================- Hide quoted text -- Show quoted text -
> > Hi Jerry,
> > something I've been wondering about for a while is how, if pictures are
> > all stored in a database, one would go about displaying them on a page.
> > Would they be written out to temporary files with unique names ina
> > directory somewhere and then <IMG... tags written out pointing to them?
> > If so, how would you know when it was safe to delete the temp files?Nope, just a small PHP program to retrieve the data, send the
> appropriate header and then the file. Then the img statement just
> refers to the PHP code.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================- Hide quoted text -- Show quoted text -

I'm au fait with doing this for file download, but I'd love to know how
you point the multiple img statements at PHP code and how multiple
pictures can get sent? Any chance of some examples?

On 26 Jan, 12:53, "Captain Paralytic" <paul_laut...@yahoo.com> wrote:
> On 26 Jan, 12:47, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
>
>
>
>
> > Captain Paralytic wrote:
>
> > > On 26 Jan, 04:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> > >> 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.
> > >> jstuck...@attglobal.net
> > >> ==================- Hide quoted text -- Show quoted text -
> > > Hi Jerry,
> > > something I've been wondering about for a while is how, if pictures are
> > > all stored in a database, one would go about displaying them on a page.
> > > Would they be written out to temporary files with unique names ina
> > > directory somewhere and then <IMG... tags written out pointing to them?
> > > If so, how would you know when it was safe to delete the temp files?Nope, just a small PHP program to retrieve the data, send the
> > appropriate header and then the file. Then the img statement just
> > refers to the PHP code.
>
> > --
> > ==================
> > Remove the "x" from my email address
> > Jerry Stuckle
> > JDS Computer Training Corp.
> > jstuck...@attglobal.net
> > ==================- Hide quoted text -- Show quoted text -I'm au fait with doing this for file download, but I'd love to know how
> you point the multiple img statements at PHP code and how multiple
> pictures can get sent? Any chance of some examples?- Hide quoted text -- Show quoted text -

Actually, I just took my own advice and found an excellent article on
it over on onlamp!

Captain Paralytic wrote:
>
> On 26 Jan, 12:47, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Captain Paralytic wrote:
>>
>>> On 26 Jan, 04:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> 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.
>>>> jstuck...@attglobal.net
>>>> ==================- Hide quoted text -- Show quoted text -
>>> Hi Jerry,
>>> something I've been wondering about for a while is how, if pictures are
>>> all stored in a database, one would go about displaying them on a page.
>>> Would they be written out to temporary files with unique names ina
>>> directory somewhere and then <IMG... tags written out pointing to them?
>>> If so, how would you know when it was safe to delete the temp files?Nope, just a small PHP program to retrieve the data, send the
>> appropriate header and then the file. Then the img statement just
>> refers to the PHP code.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================- Hide quoted text -- Show quoted text -
>
> I'm au fait with doing this for file download, but I'd love to know how
> you point the multiple img statements at PHP code and how multiple
> pictures can get sent? Any chance of some examples?
>

I think this is getting too far from MySQL for this group.
comp.lang.php has several posts in the archives. You can ask there
also, but some will tell you to search first :-)

But as a hint - you can pass parameters in the URL, also.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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
> ==================