Examples of Interfaces in Databases?

A while back, I ranted about Defining The Interface In A Relational Database:

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=27467&ixReplies=29

I am curious, does anyone know of any good resources,  a book, code examples or a tool, that illustrates this concept and maybe explains it in more detail (i.e. including building the appropriate maintenance tools).

Dave B.
Wednesday, October 22, 2003

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.

That is one of the reasons why we are going to switch to a development environment that allows forms to be stored in plain text files but still have designer ability (VS.Net and C# for example).

Honestly, if you are still trying to figure out how to do this, I think that should be a sign that you probably shouldn't do it?

ChrisO
Wednesday, October 22, 2003

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.

Is there any reason why your forms are all defined in tables? Like are users supposed to be able to modify the layouts? or was it just a "brilliant" bit of architecture thought up by a "smart" uni graduate?

ChrisO
Wednesday, October 22, 2003

ChrisO:

I am simply curious if any books or other resources advocate the method and if they do how do they approach it.  Obviously (according to the previous thread), I do not advocate such an approach.  On the other hand I think it would be interesting to see a system that successfully implements it.

The application spoken about in the previous thread and the one you refer to were written by a self-taught programmer turned consultant (during the boom).

Dave B.
Wednesday, October 22, 2003

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
Thursday, October 23, 2003

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.

Whereas with that old discussion, the designer had to go through the tables and decide what to update/insert/delete in order to change a layout or field.

T. Norman
Thursday, October 23, 2003

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.

Simon Lucy
Thursday, October 23, 2003

  Recent Topics

  Fog Creek Home