Re: Early and late binding.

From: David Cressey <dcressey_at_verizon.net>
Date: Fri, 20 Jan 2006 20:00:54 GMT
Message-ID: <WjbAf.36$ur3.26_at_trndny07>


"x" <x_at_not-exists.org> wrote in message news:dqqftg$fnu$1_at_domitilla.aioe.org...

> Values and operators can also be typed.
>
> With a SQL DBMSs one is forced to separate DDL from DML which may or may
not
> be a good thing.
>

Good points.

To relate your last point back to binding, some people try to postpone binding in the SQL environment by one of two techniques:

The first is storing what is really metadata in user tables. That way they are able to revise and extend the data model on the fly, without waiting for the involvement of a DBA. Everybody is real happy, until they try to get the same outputs that they could easily get with a classical (relational) database, where the model is static between DDL transactions. Then they discover that they have to go through all the data management that they bypassed by dropping the DBA out of the loop.

The second is by resorting to dynamic DDL. Here, the fundamental process is not coded as DML, but as something else. That something else gets converted to SQL at runtime. The SQL may be dependent on DDL that was added to the database at a later point in time than the coding of what I called "something else". This is a really promising use of "late binding", provided it's done right. If it's done just to whitewash sloppy analysis and design, then it's the road to hell. Received on Fri Jan 20 2006 - 21:00:54 CET

Original text of this message