> The Pet Shop has a grand total of 13 tables. > > How well does this approach work with 90 tables? How does it handle > arbitrary queries that may join 1-6 tables, with conditionals and > sorting of arbitrary complexity?
Where I work we have over 90 tables and it works fine. We don't run a ticketing system or a huge e-commerce site but our servers are pretty busy and we have no performance problems. Our application layer does not contain a single line of SQL. The entire system is OO Perl and uses an OR-mapping system that entirely abstracts the tables and relationships between them. It works for us. Maybe it wouldn't for a bigger system, but I would also caution people to say that if you find yourself doing joins across up to 6 tables, you're almost certainly doing something wrong from the start and, basically, you're fooked because of shitty design, and O/R or R/O won't help you. > > We've found the O/R mapping to be an indispensable part of the > > system. Since all data is contained in objects, the views/widgets > > don't need to how the data is populated. They access all data > > through a single interface. This is how our system works too. Less code, fewer bugs (we hope!), faster development time. For us it's awesome; your mileage may vary. As for people claiming never to have seen an OR system that works, I suggest you check out EOF from NeXT/Apple. That puppy runs banks and insurance companies, and usually without needing a line of SQL. It's not perfect, but it's pretty friggin amazing. Each to his/her own. Kyle Dawkins Central Park Software
