Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1mimq$40n$1_at_news.netins.net...
> The
> question of whether OO code (those OO types don't like to be called
> "procedural") or declarative code or whatever language is employed to
"spec"
> the constraints is somewhat a matter of taste and efficiency.

It shouldn't be. Declarative is better for many things, including constraints. It's easier for the developer, though may not appear so in the short run.

> I prefer
> removal of all declarative code because it is data specified to a specific
> database implementation.

There are many declarative languages other than SQL dialects, and many tools through which you can create your own (e.g. use Ruby with ERb to generate code from templates and DBs or config files). Declarative is a state of mind (sort of).

> While there is some similarlity with the various
> flavors of SQL, when we talk about the language used to code constraints
in
> Oracle and those for SQL Server or DB2, we are not really talking about
the
> same language.

Unfortunately, you're right in the current climate. Hopefully D4 / Tutorial D will inspire many implementations of one standard, and we can be done with SQL and all of its nonsense.

> This is only feasible if the validation logic (combination of the specs &
> the DBMS's use of the specs) is not tightly coupled with the storage &
> retrieval functions of the DBMS. I haven't seen RDBMS's that attempt
> anything like this, have you?

Dataphor.

> That's not what I intended to say -- my point was that the UI needs to
have
> knowledge of validation information, such as T/F, radio button or check
box
> data, etc It is critical that this be there -- the user needs the best,
> most-likely-to-produce-accurate-data-entry information it can get.

True, although the fact that other users are changing data at the same time means you need some sort of back-end validation anyway. What if Fred removed the account record Melvin is editing? I realize there are transaction scope issues here as well, but "rules" tend to "operate" on sets of data, and in a shared environment, that data is changing.

> I am in complete agreement that
> it should not be hosted by clients -- I agere it should be centralized. I
> just don't see the proprietary DBMS with its proprietary version of SQL
and
> its proprietary engine for applying constraint logic and such moving out
to
> the front of OS-independent and database independent applications and
> addressing this.

Agreed that SQL sucks, although you can do some degree of "constraint automation" with it. We need better DBMSs, clearly. But that should be the goal, not a call to abandon hope of ever having a non-proprietary language and RDBMS.

> Have you seen anyone try to do this?

I think Alphora is doing this, and yes, there are many "generator toolkits". Every vendor has one (or more than one).

> Do they end up with OS-independent
> applicaxtions? DB-independent?

To some degree. I can generate JSPs (OS- and container-independent) which talk to my servlets (also OS/container independent) and EJBs (same), and then use a declarative persistence mapping tool like TopLink or JAXB to map to a variety of databases.

However, this is all much harder than it needs to be, and there's still the pesky limitations of O-O. But at least if you generate your Java objects (e.g. via Castor or Oracle's tools), you don't have the work of keeping annoying O-O navigation hierarchies in sync with the DBMS.

This would all be so much easier if we just had a relational language that could be used across tiers... non-proprietary, of course.

> How do they do that? I'm not grasping the
> solution to this that includes only one set of validation specifications
and
> hosts those in a proprietary database engine with a proprietary SQL
> implementation. It seems that any such solution would make the
application
> tightly coupled with the database implementation, right?

Not the implementation, just the SQL dialect.

• erk