Rex,

I'm not sure what the "best practices" is, but the issues I've noticed -- or made me wish I had split the databases -- are Recovery, Transactions and Replication and storage issues. Security, backup issues and collation would probably also apply. I'm sure there are more I'm not listing.

For instance, I have some very large lookup tables which are better in a seperate database, since they do not need to be backed-up and when I want to update them I don't need or want any transaction logging. Setting up replication is probably a lot easier/safer is all replicated tables are in the same database. I think it's possible, but requires extra work, to have changes to multiple databases commit/fail in the same transaction (depending on version, I think. If some tables do not require the same backup or recovery model, a seperate database would be nice.

I think I would keeping everything on one database unless there was a specific reason to keep some tables seperate.



>Hi all,
>
>In rewriting software that encompasses several areas (customers, employees, workflow, accounting...). What is the guideline for creating databases. Should all of the tables be in one database or should there be several and just use triggers for relations? Any opinions?
>
>Thanks,