I am creating a solution with many interconnecting DBs. For neatness it would be easier to divide the main directory of files into sub-directories. Is this advisable, I can see no reason why not but I have made the mistake before of putting files into completely different directories.

If it would cause a problem the next question is why?

You've told us absolutely nothing about your solution, it's kind of hard to speculate if this structure is correct for you. It's kind of like saying "I've built my solution in English, is this ok", well maybe not if it is to be distributed in Peru. How about a hint?

-bd

Simply put the solution has 60+ files and growing. In the sales side I will have at least 20. It is easier to work with a smaller number of files when creating joins etc. as there is less chance of making mistakes.

Basically there will be four modules in total (foreseeable) it would be handy if I could break them all up into one main directory and 3 sub directories.

I think you need to balance the advantages of tidiness in your sub-directories against the potential for inflexibility and/or the hazards of broken paths if your files are ever moved around at a later date.

The underlying question here is how important or necessary to the user will the 'tidiness' of the directory be - and if it is important, are there other ways to achieve a similar or even a better outcome?

For example, it may be appropriate to consider creating a master 'opener' file which has a highly organised index of the other files and buttons/menus to allow the user to navigate to the appropriate files. You could set an open script in every other file that points to the Master opener so that no matter where a user starts, he/she will end up in your grand entrance lobby (which can be made to be more intuitive, informative, organised and welcoming than any bunch of sub-directories?!