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 <aettinger@xxxxxxxxxxxxxx> wrote:
On 6/9/06, Antonio Bassinger <antonio.bassinger@xxxxxxxxx> 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
