Well let me try and describe a simplified version of what I am doing. I work for a group of analysts, and they analyse technical products. Each products has about 300+ fields associated with it, and each product is vastly different from the other. Let's say the product "foo" has a table "fields" associated with it, which describes each field in foo (its name, description, type[float,boolean,text], order) and another table called "data_foo" which is 300+ fields in length. Each record in "data_foo" represents the technical specfiications of a single company/manufacturer. So if there are 200+ companies, there will be at least one data_foo record associated with it (in reality there is a one to many association between a company and the number of technical specifications they have defined).There are many different applications designed around the tables "foo" and "data_foo", and course the relationships are slightly more involved, but I digress. Each new product specification requires that I create a new table to hold that data, and with new product specifications being created every month, you see that the N number of tables will increase. If I store that data in the "fields" table or create a table that has 1-many relationship with it, I endup with thousands and thousands of records (Remember, each product has 300+ fields associated with it, and each company has at least on product specfication, and the N number of products continues to increase). Any ideas?
"Miles Thompson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Christian, > > A red flag is flying. > > Usually, when people start talking about how the number of tables will > multiply in an application, there is a problem with the design of data > structures. If that's the case, now is the time to fix it. > > Miles > > At 05:35 PM 1/15/2004 +0000, Christian Calloway wrote: > >Hey, > > > >Sorry to post a mysql question here, but I wanted an answer from a PHP > >perspective. I am currently working on a database (for work) which contains > >40 tables, and will continue to expand. The reason for expansion of tables > >is to obscure to get into, but the relationships all do make sence. I have > >never worked on anything over like 50 tables, and I was wondering if I > >should expect a performance hit, when say, I have 100 tables, 200 tables, > >etc. Would it be wiser to break up the logical sections into there own > >databases? Wouldn't that cause a bigger hit (to performance) with multiple > >tables from multiple databases being opened on every user query? Thanks in > >advance > > > >Christian > > > >-- > >PHP General Mailing List (http://www.php.net/) > >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
