Re: Resiliency To New Data Requirements

dawn wrote:
> erk wrote:
> > Probably true, but computing history, and probably math and logic too,
> > is filled with models and ideas for which no empirical evidence of
> > superiority exists.
>
> Yup, like that "earth is flat" and "sun goes around the earth"

I'm not sure I get your point, but mine was: computing has nothing vaguely related to the empiricism and experimentation of physical sciences. Experiments in various computing models would look like psychological and sociological ones, as humans are always involved.

> Have you ever seen people model lists by assigning numbers with gaps so
> that other items could fit "in between"? GL account structures are
> famous for that, but it is a rather pathetic "design pattern", don't
> you think?

Yes, I do.

> Worse than that, there are lists that would be good for the user, but
> that 1NF designers leave as single-valued just because it is too much
> work to jump from 1 to n. When something is a pain in the neck to do,
> developers can more easily justify not doing it.

If you don't have control of the data structures, then you run into this, although I've yet to ever see an attribute that was single-valued and later needed to be multivalued. Maybe it happens, but I've yet to encounter it. Converting something from 1 to N involves creating a new relation/table, a foreign key constraint, an insert statement, and a final alteration on the original table.

> > Most uses of lists that I see are simply inferior to sets
> > or relations. I find them hopelessly specialized for most purposes, and
> > introducing them into a relational data model involves tacking on a
> > specialized syntax and semantics for a data structure already subsumed
> > by relations (and with little work).
>
> Good party line there, erk

Da, komrade. Ignore the hordes of peasants starving for lists.

> > > In theory lists can now be defined with user-defined domains in the RM,
> > > but they are not integral to the RM "data model" and I want them in any
> > > "data model" I use for typical DB101 applications. Why not?
> >
> > "A designer knows he has achieved perfection not when there is nothing
> > left to add, but when there is nothing left to take away." - Antoine
> > de Saint-Exupery
>
> So I suppose my house would be better without the whirlpool tub?

Heh - I'd consider lists more like a rope ladder up to the second floor, hanging right next to the staircase and the elevator.

> We clearly have had different experiences.

Fair enough.

> > Even Pick is simply vaguely relation-flavored with
> > system-defined, syntactically significant 1 and 2 level lists as an
> > available attribute type. Even in MVDBs, you're not ditching the
> > Information Principle entirely, as the top-level container is still the
> > relation.
>
> I'm not at all opposed to modeling with relations, it is just that the
> IP requires exclusivity and I want the model to also "understand'
> lists, for example.

If that's the case, what other types does the model have to "understand"? Just lists? Sets too? The advantage to me is that relational treats all those the same way, thus hobbling no one, and keeping concerns separated.

• erk Apparatchik Number 1