I\'ve been searching stackoverflow for about an hour now and couldn\'t find any topics related, so I apologize if this is a duplicate question.
My inquiry is this. Is th
LOL our main db has over 700 tables, I haven't worked with a database so tiny it only had 40 tables in years and years.
As long as you have the tables you need and they are correclty normalized, you are fine.
I've seen more performance problems caused by too few tables than too many.
It seems like you're making your best effort to normalize your database. That's a good thing. Many times problems arise because there are not enough tables.
You may put all the data from your actual tables in one table. To the second table may hold just your 'table names', and the application will still work.
But this is not the point here.
Tables are some kind of organization structure. They are some kind of drawers.
Do I have too many drawers?
It depends…
There is such a thing as too many tables, but 40 is nothing like that number. And when people start butting into product limits, then it's usually the point when they need to rethink their design.
For SQL server, the maximum capacity limits tell you that a DB can contain ~2000000000 tables (if it contains nothing else, has no PKs or constraints of any kind, etc). Needless to say, if you hit this limit, then you're doing something wrong (e.g. you've decided to have 1 table per customer, and somehow you've actually gained a lot of customers)
Without knowing anything about your specific database, I'd say that no, you are not using too many tables. Real world problems and business needs can easily point to a schema that's at least as large as yours. I think the real question to ask is whether your design is right for your problem.
You should have exactly as many tables as you need; no more, no less.
One of the systems I'm working on these days has 143 tables - because that's exactly the number required to solve the problem.