Is there a standard development approach to layouts for dbs?

Normally when I design dbs I design layouts to go with each db. For example, on a client db there would be layouts for entering new clients, searching, displaying search results, editing single records and the like. This is a typical FM approach, at least insofar as the books are concerned. Some layouts would have self-joins and/or other relationships and portals other would have subsummary and trailing summary reports. Essentially if the layout items were of direct concern to the information stored in the db it would stay with the db.

I've begun to question the logic of this approach. I wonder if it would be better for the user to have one file strictly for layouts and would contain all layouts for the entire solution (ie clients, sales, ordering, invoicing) and use relationships and scripts to connect the relevant dbs. In essence, using the above example, there would be a fifth db called user_interface. The user would never have to jump to different dbs/tables but would stay in the same db all the time.

Thoughts? Pros, cons? Is this stating the obvious?

thanks

phil courterelle

There is a forum here called "Seperation Model" that dedicated to this very question

Select the "Forums" link at the center top of any page and you'll see the forum listings.