Database with many tables or multiple databases with lesser tables

SQL Apprentice Question
We are building a large application (a financial system) that, after
normalization, would approximately need 1500 or so tables. The question is
should we build this as one database or should we separate it out into
multiple databases.
There is a case for separating out into 5 or so databases based on
functional modules within the financial system (GL, AP, AR etc.) . Problem
though is they are related to one another in some way.
In a single database case, some standard tables (like U.S. States, Notes
etc.) can be a single table. Also it avoids cross database talks so ease of
development is more.
What are the performance advantages/disadvantages of one way or the other?
Does SQL Server performance get affected if the number of tables is large, as
in my case? Any inputs, suggestions?

Celko Answers
>> We are building a large application (a financial system) that, after normalization, would approximately need 1500 or so tables. <<


We have to take your word for it, but I have found that a bit larger
than most Fortune 500 systems. But who cares, if the data model is
right. And if they are part of the same data model, they should be in
one DB -- would put male employees in one schema and female employess
in a second schema?

With various products, you can partition the tables, do some indexing
tricks, etc. but that is implementation and not design.



>> The question is should we build this as one database or should we separate it out into


multiple databases. <<

Unh? Is it one data model or many different universes of discourse?



>> There is a case for separating out into 5 or so databases based on functional modules within the financial system (GL, AP, AR etc.) . <<


"functional modules within the financial system" -- Like a 1950's
COBOL system! Nothing like an RDBMS at all! No concept of a universe
of discourse at all.


>> though is they are related to one another in some way. In a single database case, some standard tables (like U.S. States, Notes etc.) can be a single table. <<


NO, THEY CANNOT!! A table a set of entities or relationships of the
same kind. Were the kid on dope in the back of my database class?
Look up the OTLT or MUCK design flaw.


>> Also it avoids cross database talks so ease of development is more. <<


Ease of developement is not the important thing. Data quality,
maintainabilty and those other things they told you about in the
Software Engineering course you should have taken are ORDERS OF
MAGNITUDE more important (literally -- did you ever read Boehm's
research, etc.?).