In the real world, network administrators are going to tell you where your application components are going to be stored. In addition to Ed's valid points, sometimes backup considerations will cause an app to be on a "static" volume (backed up infrequently) and its data on a "dynamic" volume (backed up frequently).

So, it's better to anticipate these requirements and be ready for them, rather than have to hastily retrofit your app to handle separated data.

Another basic concept is, on a network it is desirable to have the app local, for improved speed and reduced network load. This pretty much guarantees that your app and its data will be in different locations.

>Yup, those could be the "compelling reasons not to." However, I find that applications that are not "developed and deployed in the same place" have no trouble finding their data. As long as the DBC and files are present in the same place as the app, everything is hunky-dory.
>
>>I disagree here; the issues of finding the data and fixing up database refs during the process of opening the tables are virtually identical whether everything is in a single directory or several. Unless the application and DBC are developed and deployed in the same place, or the DBC is created programmatically at the site, either using a tool like SDT or code that came from something like GENDBC, the database references have to be fixed up. Learning to store a path in the registry or a local configuration file and read it at runtime are just not that tough to do, and not be locked into a single location buys you a lot:
>>
>>(1) The application can move to a different location and the mechanism for handling the new location already exists in the code.
>>(2) You can deploy more than one data set by having each dataset in a separate folder.
>>(3) The performance hits from a directory with too many file entries are minimized.
>>(4) The operating system requirements to have multiple security requirements for different files are reuced - for example, you can deploy on a file system with folder-level granularity rather than file level granularity and not be forced to grant the maximum set of file access requirements on all files.