Thanks to All who suggested solutions or pointed errors in my existing
approach.
Most seem to suggest having 1 database and 1-2 tables. So let me confirm:

1 table with million records are ok. But what of the size of the table?

10,000 * 10 MB = 100 GB!

If the upload limit is to be notched up 100 times - typical of public mail
servers, a table would expand to 10 TB.

Someone suggested :

The one-database-for all method increases risk that an SQL error will
"leak" information from one client to another.

But with 1 table and a million records, what would be the chances of this
"leak"?

My idea is,

For every 100 users, make a new database. That is 100 tables, each of max.
10MB * 100 = 1GB.

For the 101th user, make a new database. So for 10000 users -> 100
databases.

100 databases and 100 tables don't look bad to me. What say?

Thanks
Antonio

On 6/11/06, Anthony Ettinger <[EMAIL PROTECTED]> wrote:

On 6/9/06, Antonio Bassinger <[EMAIL PROTECTED]> wrote:
> Hi gang,
>
> Situation:
>
> I've a HTTP server. I intend to run a file upload service. There could
be up
> to 10000 subscribers. Each saving files up to 10 MB.
>
> I made a proof-of-concept service using PHP & MySQL, where there is a
single
> database, but many tables - a unique table for each subscriber. But I
> realize that I may land in trouble with such a huge database. Would it
be
> better to have a separate database for each subscriber?
>
> Which approach is better, many tables in 1 database, or many databases
with
> 1 or max 2 tables?
>
> Kindly suggest with pros and cons of each.

you might want to consider storing the files outside of the database
as well, and just a pointer to it's path in the table.

with respect to table vs. databases per user, neither.


--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html

Reply via email to