Re: Database schema for univesal usage

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 25 May 2005 09:38:50 -0400
Message-Id: <3sbem2-am2.ln1@pluto.downsfam.net>

lauri.pietarinen_at_atbusiness.com wrote:

> Kenneth Downs wrote:

>> lauri.pietarinen_at_atbusiness.com wrote:
>> >
>> > What I am saying is that there are many degrees of flexibility that can
>> > be built into the schema.  Maybe we currently need only two different
>> > kinds of phone nubmers, but we suspect that the situation might change
>> > in the future.  Should we go for the flexible schema now or just add
>> > new columns into the table when we happen to need them?  How will the
>> > application programs be affected? How will the queries be affected?
>> > Will generalising now unnecessarily complicate queries?
>>
>> As I said above, if you know that your toolkit does not handle schema
>> changes well, then you are in trouble no matter what.  If you provide
>> extra stuff you have to constrain its use, and then you work harder
>> making a UI
>> for a structure that may not even be necessary.  Balance this against the
>> expense of adding things after the fact and they usually come out even in
>> practice.
>>
>> What solves all of these cases is the ability to modify structure and
>> corresponding code at low cost as the system evolves.  Then you can have
>> everything fit all of the time.

>
> I actually agree with your viewpoint and I personally tend to design
> databases that are tightly fit. And it might indeed be the "app
> environment tail" wagging the "database model dog" that makes companies
> consider generic schemas (I am still calling them generic as opposed to
> spesific). If it costs $$$ to add a new column to a table then you
> propably start thinking in those terms.
> I recently attended a Dama meeting where Len Silverston gave a
> presentation on his "Universal Data Models", which tend towards generic
> solutions. I confronted him on the issue of the database losing
> meaning via generalisation and he said that one of the motivations was
> indeed the expence of, say, adding a new column to an existing system.
> His presentation was well given and very informative and he does
> deserve to be listened to.
>
> Being an advocate of tight db-models I have aquainted my self with
> Dataphor and Versata, both which take a slightly different approach to
> the application generation problem directly from the db-schema. Have I
> understood correctly that you have created some kind of similar product
> or in-house solution?
>

Yes, we have created an in-house solution that we intend to release as open source, mostly likely GPL.

The foundation principle is that an application of arbitrary complexity can be described entirely in data. The only time you need human judgement is to work out the database design, everything else should follow from that (and is therefore automatable). We work out that claim in this whitepaper:

http://www.secdat.com/dev/atomic.html

I should note that the "chains" feature is given "honorable mention" in the whitepaper, but has since been implemented.

A more detailed description of our data dictionary syntax and abilities can be found here (there is no link to this page on the site, you have to know the document name):

http://www.secdat.com/dev/androspec.html

We have not published downloadable code yet, but we'd be happy to send a tarball to any interested developer. Our reference implementation runs on Linux using Apache, PHP, and PostgreSQL. If you want to send emails from the system, you also need an outgoing SMTP server running, we use exim.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Wed May 25 2005 - 08:38:50 CDT