Re: sql views for denomalizing

"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1122962575.281533.294820_at_g49g2000cwa.googlegroups.com...

> I agree that there are problems with the current situation, in which
> much of the value of static (not "strong") typing is thrown away
> because we generate the sql in strings at runtime, instead of
> checking them statically at compile time. But this is not sql's
> fault, per se; it's a problem with the "embedded data language"
> approach. Also I don't see how this issue means that the dbms
> should not have a powerful static type system.
>

This is a whole new discussion. How much is known at compile time? I've seen systems that use dynamic query generation, not because they really need to, but as a sleazy way around change management issues. They usually end up creating more problems than they solve by using this technique.

> To my way of thinking, the type system is the most important
> component. It is *the* central component of the system, and its
> design will have a huge impact on every other part of the system.

This is a major key point. It's probably a different discussion. To me, the biggest single difference between Oracle and DEC Rdb/VMS is the way the types were designed in the two database systems. In Oracle, the types were designed to be unbound to any particular environment, ensuring portability (except for porting away from Oracle).

In Rdb/VMS on the other hand, the types were for the most part patterned after the types defined in the VAX architecture. This meant that programmers in Fortran, PL/1, Basic, Pascal, COBOL, or what have you could deal with (a subset) of these types, just fine. And the SQL to programming language type barrier was practically non existent.

It resulted in more rapid and sound application development, but you weren't going to port the result away from VAX (or Alpha). There's more, but it belongs in a separate discussion. Received on Thu Aug 04 2005 - 11:25:54 CEST