"big enterprise applications with 150 database tables"
Did you drop a zero or two? I hit 250-ish once on a relatively minor project by enterprise standards. (Built a small business on this table, so it wasn't a dinky thing either.) If you're normalizing anything like correctly, the table count grows fast. (Not to mention things like what I call "enumeration tables" that exist solely to provide foreign key checking on another table and make it so you don't have the same string showing up a bajillion times, instead just having a tinyint or smaller.)
If there was sufficient refactoring, you should be able to run most enterprises on a small-ish number of tables. Say 100-200 (not including lookups) I'd almost bet that you could go <100, but I'll hedge my bets a bit.
If you don't refactor, and most enterprises don't, then yes, you can run easily into the 1500-3000+ range. You can also get this big if you buy a one-size-fits-all data model, which has to be God's punishment to mankind for being able to draw boxes and lines. You can also grow fast in a hurry if you have a team who love "patterns" and are not afraid to plop them in everywhere.
Most enterprise problem domains do not require anywhere near the number of tables they use to do their business.
One of our custom applications that was started in the early 90's has about 750 tables and it only handles the order management and part of the manufacturing process for one division of our company. That doesn't include back office stuff like GL, AP, AR, Inventory, Payroll, etc.
Did you drop a zero or two? I hit 250-ish once on a relatively minor project by enterprise standards. (Built a small business on this table, so it wasn't a dinky thing either.) If you're normalizing anything like correctly, the table count grows fast. (Not to mention things like what I call "enumeration tables" that exist solely to provide foreign key checking on another table and make it so you don't have the same string showing up a bajillion times, instead just having a tinyint or smaller.)