Re: sql views for denomalizing

dawn wrote:
> Marshall Spight wrote:
>
> > pick better than SQL:
> > nested relations. This seems big to me
>
> yes, also the 2VL

Good point! I also count this as big.

> > pick worse than SQL:
> > no static typing (but SQL's type system is fairly weak anyway)
>
> while I think there are significant benefits to strong typing, the
> typical SQL type system provides the stick without the carrot, it
> seems, so weak typing in the dbms is better. I'm still pretty
> wishy-washy on typing, I realize.

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.

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.

> > only one key
> It doesn't really turn out that way. The key may be multiple parts,
> each of which can have a separate name, but together are tossed into
> the ID for the record as well (under the default name for the key in
> the given implementation)
>
> And one can access data through alternate keys, of course.

If you can have multiple keys, that's great. I still don't understand the apparent significance of the primary key in pick. This may be a complete non-issue; simply a matter of cultural emphasis.

> If there is some reason that a data repository requires an API that is
> used by more than one top level organization, then that API needs more
> constraint handling than a pick CRUD API has. If all applications using
> the dbms api for crud are owned by the same top level company, then the
> company has the ability to manage that, with more flexibility than if
> it were a sql-dbms. That flexibility has trade-offs.

I don't believe it is sufficient to say "within a single company." It seems limited by the size of the dev organization, and it strikes me that above, I dunno, 5 or 10 or so, you can't manage integrity effectively in applications. Not if integrity is really important. If it's not so important, then go ahead. Seriously; I've seen applications where they are happy with most-rows-correct.

> > I'm still not clear on how pick handles many-to-many.
>
> multivalued lists of foreign keys in each file.

But this leads to duplication of data, does it not? Unless there is some virtual-field-trick in here somehow. If it actually does require the data to be duplicated, then I'd count this as a significant advantage to SQL. SQL's many-to-many handling is ... just ... beautiful. Better than anything OOP has, for example.  

Marshall Received on Tue Aug 02 2005 - 08:02:55 CEST