>>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?
>
>For one VFP application I would probably use just one database. However, there may be situations when we need multiple databases, say, one database is used for the actual data and another (or even few) is used to describe meta-data (such as VPM does).

I thought about that too. I have also seen one case where one database contains views to DBFs, a different version of the database may contain views to a database server. This should make it easy to swap between local data and a C/S system.

And in Bata/Bolivia, we at least three versions of the database. A programmer's version of the database, for testing purposes; the actual production database; and an empty database (zero records in all tables) where the original changes were made (this allowed easily updating the other databases, basically with an APPEND FROM for every table).

However, this is a different situation; I was talking about only the production data (or only the test data, whatever) being divided into multiple databases. No different versions of a database; no metadata.

By the way, the system was designed with VPM.