Is there such a thing as too many tables?

I've been searching 开发者_Go百科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 there a point at which there are too many tables in a database? Even if the structure is well organized, thought out, and perfectly facilitates the design intent? I have a database that is quickly approaching 40 tables - about 10 main ones, and over 30 ancillary tables (junction tables, 'enumeration' tables, etc).

Am I just a bad developer - or should I be trying something different? It seems like so many to me, I'm really afraid at how it will impact the performance of the project. I have done a lot of condensing where possible, grouped similar things where possible, etc.

The database is built in SQL Server 2008.

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.

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.

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.

It really depends on the complexity of the application you're trying to implement. Things such as accounting systems are pretty intense had easily reach 40+ tables.

2147483648 tables or more might be problematic with some engines. 9223372036854775808 tables or more might be problematic with certain others.

(But if your question meant whether there exists a certain number n such that a database design with >n tables must necessarily be flawed, then no.)

In my own job i have about 60 tables and it seems not much) I think that main thing is how datastore organized (relations beetween tables, etc..), how much queries you need to retrieve needed information and how simple you data can be represent as buisness objects in your application.

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…