Re: Declarative constraints in practical terms

In article <1140555731.823399.160020_at_g44g2000cwa.googlegroups.com>, dawnwolthuis_at_gmail.com says...
> 3) The functions for validation of data can be used anywhere within an
> application if packaged outside of the dbms, otherwise most of them
> need to be coded at least twice -- once for the dbms and once for use
> in a UI or web service.

...or you can ditch SQL and use Dataphor. It puts the constraints in the UI for you. No duplication. It even builds the UI for you; no duplication there either. :)

By the way, do you consider maintenance of constraints in your metadata+code approach? When the schema changes, some constraints will need to change too, and that seems much easier and less error-prone when they are part of the schema instead of independent programs. When you put the constraints in the DBMS, it will tell you which ones are affected by a schema change.

> I lean toward not duplicating constraints, coding and maintaining them
> in multiple places and languages, but I understand that someone else
> might choose the other strategy. Whatever choice, it doesn't look
> obvious to me that declarative constraints are better as I gather it
> appears to many others.

Based on your points above? I honestly can't see how the "metadata+code" approach comes out on top in any of them---except possibly for your point three, which however is addressed by the most relational of the commercial systems out there.

> This relates to the fact that the RM is not sufficient for writing
> software

Whoever said it was? It's just a theory of data. But please don't confuse SQL and the RM! I know we keep harping on it to (or beyond) the point of annoyance, but to have issues with SQL is NOT the same as to have issues with the RM. Quite the contrary, in many cases. :)

> Is there a way to get the best of both worlds on this one? This issue
> is really bothering me

I come late to this discussion, but I would find it easier if you could state more clearly the advantages of "your" approach. Just yesterday I met with a programmer who is developing the same kind of database system I'm developing (health surveys / biobanks), who used Oracle with no constraints whatsoever---just VB application code. When I showed him my system, with constraints all over the place, he just shrugged and said something along the lines of "Sure, in your database inconsistencies cannot occur, but it's very simple for me to code a program to check if there are any errors in my database if there is any need for it". For him, it was just a matter of taste! I don't mean to imply that's your position---but I would like to know if you find this developer's attitude as outrageous as I do. :)

-- 
Jon