Examples of Interfaces in Databases?
A while back, I ranted about Defining The Interface In A Relational Database:
Visual FoxPro stores all of its forms and classes in tables. And it is INCREDIBLY ANNOYING - the VSS integration of VFP is not the best so we don't use it, but without it you can't do diffs between different versions of your forms and classes.
What I am trying to say is that if you are still trying to work out this architecture, and it is driving you insane (like it seems to be if you are still trying to work it out after all this time), you should probably look at changing your architecture.
In the past I have used an application called Remedy (remedy.com) which is used for ticketing applications, etc. The forms and all workflow are all stored as rows in the database. So, there is a table that represents all the fields on the form. Every field has attributes (position, size, etc.) that are stored in a meta-data table. Each form has attributes, etc. All workflow (such as event driven, trigger and timed actions) are again, all stored as data in various tables. All of this can be controlled by a nice GUI tool. It is pretty extreme example of how this architecture works... and works very well. Our install scaled to many thousands of users.
m, from what you described, it seems like the interface is still defined by using a GUI. But it just happens that they use the database for storage of those definitions, instead of the file system. Designers don't need to manually insert rows into the database, and the GUI doesn't force the designer to know about the organization or the database rows behind it.
As a developer in Visual Foxpro I can't say as its ever really been a problem to have the forms and classes in tables. VSS works as well with it as anything else.
Fog Creek Home