In my previous job we have separate databases for Lookup tables, Support tables. We also splitted data by state, e.g. we have MA.dbc, RI.dbc, CT.dbc and NH.dbc

At my current work we have one huge database with lots of tables. Even stage tables are included into the same database. I would probably separate stage tables from the work tables to different databases.

>>I was wondering if it could be a good idea to work with two distinct database, one containing the set tables the other one dedicated to the work files, this for limiting the number of tables inside the database.
>>What's your opinion about this idea ?
>
>Having read the rest of the thread so far, I think (and may be wrong there) that you think about lookup tables and transactional tables. The lookup tables would contain names, addresses, descriptions etc of various entities (customers, items, units of measure etc) that don't change daily, while transactional ones would be where you track what happened with the entities.
>
>Generally, I think they still belong to the same database, because they do contain the same general set of data; the data that your application works with.
>
>You may want to have a separate database for two other things: metadata and views, if you use any of these. The metadata would be data about data - data dictionary, security level definitions, class factory, menu (for data driven menus) etc, if you have any such tables.
>
>Also, if you use views a lot, you may find that a separate dbc containing only views is handy, and easy to recreate from code when needed.