>I came across a system which used several databases; it seems the original designer had grouped "functional groups" of tables into databases or something. About 10 different databases; several tables have their own databases.
>
>Since all tables are part of the same application, I would have used a single database. Implementing Referential Integrity in such a system is sheer madness - it would have to be redesigned (so that all tables go into the same database). The application in question doesn't use RI, as far as I know; to be more precise, it doesn't use the built-in RI-options provided by Visual FoxPro.
>
>I don't have contact with the original programmers, to listen to their reasoning, but it seems to me this is just a beginner's mistake. Or is there any real benefit in thus dividing tables for an application into several databases?

Two cases where this may be justified: when there are third party components which use their own databases, and when you actually have a suite of apps where each dbc is then shared among them, but not each dbc by each app. So each app would open only what it really uses. But I guess there must be simpler ways to do this - specially if all of a sudden you need to have a view joining tables from two dbcs which is stored in a third... no more grey hairs because even a caveman would go bald juggling that.