Re: Declarative constraints in practical terms

ralphbecket_at_gmail.com wrote:

> dawn wrote:
> >
> > If the database services are used by application developers, then
> > couldn't inside-the-database constraints be botched up by developers
> > (e.g. dba's) just like outside-the-database services could be bothed up
> > by developers (e.g. database service/infrastructure programmers)? As
> > long as applications use whatever framework is in place for maintaining
> > the database, then the constraints will be applied. In either case
> > someone has the ability to botch things up, whether via the dbms
> > specifications or database services code.
>
> I think you're asking what is the difference between
>
> (a) posting the constraints in the DBMS and having applications
> interact directly with the DBMS and
>
> (b) coding the constraints in a wrapper around the DBMS and
> having all applications interact indirectly via the wrapper?

Yes.

> I can think of several reasons why (a) is preferable to (b):
>
> CORRECTNESS
> In (a) the constraints can be expressed declaratively
> and directly (i.e., ideally with nothing more than a syntactic
> reformulation of the specification of the constraints) to the
> DBMS, whereas in (b) the constraint specification must be
> converted into some (probably non-declarative) programming
> language.

This is something I don't yet "get." If you were to think in terms of declarations, then using a language in which you can code a declaration means less translation. If you were to think in terms of functions, then using a language in which you can code functions means less translation. Is it more natural to think in one than the other? I don't have a problem thinking in terms of "given this input (and pre-conditions), what is the output?" Do coders who write constraints declaratively code more accurately and more quickly? Does it code an organization less if all constraints throughout software are coded in a declarative language? I gather that some think the answer to that is "yes" but I don't know of any evidence of that. Do you?

> This is an extra opportunity to introduce bugs,
> design errors, and performance problems that simply cannot
> arise in (a).

I don't see why not. If a function arises in my the requirements and I have to translate it into a declaration, wouldn't we have a similar scenario?

> EFFICIENCY
> In (a) the DBMS can optimise the checking of constraints
> in a way that cannot be done by (b), which must treat the
> DBMS as a black box.

This makes sense to me. It brings me to the question I'm not supposed to ask about whether there is any data to support a conclusion that constraints specified to a DBMS provide better performance in the final solution than those specified in other code.

> DEVELOPMENT AND MAINTENANCE
> Option (b) necessarily means
> trying to write high performance parallel code, which is
> notoriously hard to get right (not to mention dealing with
> replication, distribution, recoverability, and so forth).

I hear you on this one too. OK, so the DBMS software is written once to address threading and such no matter what constraint parms are passed to it. Otherwise someone has to write a framework that addresses these in its interactions with the dbms. Once that was written, however, we would be in the same position in either case, however in one case the solution came from the dbms vendor who, presumably, will know what changes they are making better than if this software came from a third-party or were homegrown. Good point here.

> The
> DBMS code, on the other hand, has already solved these
> problems in a generic fashion and been well tested.

Yup.

> TRUST
> The constraint language used in the DBMS (a) is going to
> have seen much more testing and use than the code developed
> in the roll-your-own approach in (b).

I would agree there are likely more lines of code in (b) but constraints are code too, and often not that easy to verify and debug, I would think, especially if handled in a separate process than other code written to handle whatever new requirements are being addressed.

> APPLICATIONS
> Application programmers will be coding to an industry
> standard interface in (a). I expect it would also be much easier
> to interface other tools and products using (a) rather than (b).

I can imagine that in a given scenario there might be more tools related to SQL than libraries in Java, but I'm not sold on this one.

> > I have not worked in a shop that fully utilized SQL constraint
> > handling, but presumably constraints need to be added, changed,
> > removed. This would introduce a risk that would be tested before being
> > deployed, right? That is what my question was about. I don't know if
> > new builds of the software run through regression tests for the dbms
> > constraints as well as application code or not, typically (of course
> > I'm sure there is variety).
>
> There is no way to fully protect against human error, the best one can
> do is try to minimise the number that go undetected. The trouble with
> plan (b) is that it has so many more sources of trouble than (a).

With (a) you also have that there are often two or more separate groups of developers required to implement changes in an application, using multiple languages, where there can be a corporate culture that is not particularly conducive to communication among them. This can introduce more problems than it solves.

> If
> you
> like, (a) has fewer moving parts.

It seems to me that it has the same number, but fewer that are not delivered, tested, etc by the DBMS provider. Thanks, this was a very helpful list. --dawn Received on Thu Feb 23 2006 - 22:02:24 CET