How resource intensive it is depends a lot on how much data you have and what you're doing with it. You want to reduce the number of connections and disconnects, since those are really intensive, but if everything is on the same server, you can do cross database queries. As for the table size exceeding the OS limit, that'd take quite a bit of data to do. With proper database design, that shouldn't be too much of an issue. If you have 2+gb of data in a single table, that's one monster table. Some info here about table size restrictions for MySQL: http://dev.mysql.com/doc/refman/4.1/en/full-table.html You could create a table and stuff it full of thousands of records and try to check the physical file size of that table's file and see how tricky it would be to actually 'fill' a table. Ideally, for your 'customer' table would contain just the data that was unique to that customer. Typically data that all your customers are going to have a single entry for so you don't have a lot of empty spots. Anything that you have multiple entries for or are unique to a single customer, you could put in another table as meta data (additional information that didn't fit in the main table). You probably want to ignore my original parent/child threading idea. I was just illustrating a way that you COULD do it. What you may want to do is have a 'customers' table, which contain your customers, then another table for the base information for your customer's customers with an ID field that matches the entry in your 'customers' table. For additional tables in the database, you could do something like you meantioned... have "custname1_tablename1" and use a code in your "customers" table to indicate the table prefix. This kind of thing is used a lot in systems like phpBB, Gallery, etc so you can have multiple copies installed on the same server. It'd be the same idea when dealing with multiple customers. Just make sure that the prefix you use for a customer doesn't use characters that are bad for table names. What kind of data are you thinking about storing for your customers and your customer's customers? And what other data do you need to store for whatever your webapp does? -TG ----- Original Message ----- From: nhadie <nhadie@xxxxxxxxxxx> To: php-db@xxxxxxxxxxxxx Date: Fri, 28 Sep 2007 23:49:23 +0800 Subject: Re: newbie help > Thanks for your reply, which solution would be faster and not put too > much load on the resources of the server? single or multiple database? > If i use a single database, would i be having same tables for each > customer, e.g. if i have customerinfo table for customers of A, > would i also have customerinfo table on customer 1 and 2 and so on, but > changing the name by prefixing something to the table name e.g > cust1_customerinfo. > i'm thinking if i use only a single table for, then i might have > problems on the file size limit of the OS, would i have that problem? > > thanks again for your help, i really,really appreciate it. > > regards, > nhadie > > > > > TG wrote: > > You could do separate databases if you want. It all depends on how you > want > > to organize your data (keeping in mind data backup strategies and stuff). > > > > Using separate databases on the same server, you might have another > database > > for the 'common' data. Any variables you store in the database that > don't > > really change and are common to all databases. Or if you log anything > and > > want to keep the log data in one central location, you could put it in > the > > 'common' database. > > > > > > If you wanted to store all the data in one database, you could use > something > > like forum threading techniques to show a parent/child relationship for > the > > customers. > > > > > > id name parent > > 1 customerA NULL > > 2 cust1 1 > > 3 cust2 1 > > 4 custB 2 > > 5 custC 2 > > 6 custD 3 > > > > > > Then it's just a matter of drilling down, collecting a list of ID's for > that > > customer and the sub-customers. > > > > Lotsof ways to tackle this problem. > > > > -TG > > > > > > > > ----- Original Message ----- > > From: nhadie <nhadie@xxxxxxxxxxx> > > To: php-db@xxxxxxxxxxxxx > > Date: Fri, 28 Sep 2007 11:30:42 +0800 > > Subject: newbie help > > > > > >> Hi All, > >> > >> I would like to setup a system something like this > >> > >> > >> customer A > >> > >> / \ > >> > > >> > >> cust 1 cust 2 > >> > > >> > >> / \ \ > >> > >> cust B cust C cust D > >> > >> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc. > >> what i'm after is when a customer user logs in he can only see record > >> of its customer, e.g cust A logs in, it can only see records of cust 1 > and > >> cust 2, > >> if cust 2 is login it can only see cust D and so on > >> > >> how would i approach this? should every customer have it's own database, > >> consisting of all tables i need e.g customer detail table, > >> and i will use the database name as session variable, so that when they > >> add records it be inserted on table under that database? > >> > >> sorry if my questions are confusing, hope anyone can help me, i just > >> need help on how to approach it at the beginning so it will not be messy > >> later on. Thank you. > >> > >> Regards, > >> Nhadie > >> > >> -- > >> PHP Database Mailing List (http://www.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >> > > > > > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
