Re: Should an application ever be allowed to change a schema?

Karen Sundquist wrote:

> mAsterdam wrote:

>>Karen Sundquist wrote:
>>>Imagine a database that is only accessed by a server application. 
>>...This effectively reduces the meaning of the word 'database' to
>>'deluxe filesystem'. No problem, many use the word in that sense.
>>The implication it is that part of the server application may be
>>busy taking care of contraints which would have to be guarded by the 
>>dbms if there would be other applications. Typically, developers
>>*will* implement some of the more complicated contraints in
>>the server application. This severely limits the chance of the
>>data ever being shared. 'Import' and 'export' facilities
>>become crucial to the success of the application.

No, not at all.

In writing there is only a small
difference between the singular 'a server application' from your first post, and the plural 'server applications' from your second post.

However, to your architecture it matters a lot.

In the singular case you can protect your data wherever you see fit. In the plural case you had better put all constraints which protect your data in the database. A few weeks ago there
was a thread about the redundancy in the constraint specification caused by this.

> As you know, many databases these days are accessed directly only by
> the superuser and by a number of middleware server applications that
> marshal end user queries. Data is shared by these separate
> applications. Critical constraints are included in the database that
> are common to all users of the data. The middleware applications may
> impose their own local constraints which are not critical to the
> integrity of the data.

Who is responsible for the constraints imposed by the middleware? Which data do these constraints protect? Why would middleware protect data?
My take is:
Use the middleware to store and forward messages. That is what it is designed for. Received on Sat Apr 17 2004 - 21:17:16 CEST