Re: In an RDBMS, what does "Data" mean?

From: Marshall Spight <mspight_at_dnai.com>
Date: Sat, 10 Jul 2004 01:41:22 GMT
Message-ID: <6PHHc.42573$JR4.12952_at_attbi_s54>


"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:33BjwOOKvy7AFwni_at_thewolery.demon.co.uk...
> In message <j6CDc.101024$2i5.34223_at_attbi_s52>, Marshall Spight
> <mspight_at_dnai.com> writes
> >> Let's put a new element 'N' into
> >> the list, right after the 'B':
> >>
> >> The new list is [A, B, N, C].
> >> Now what is the set?
> >>
> >> is it UC1: { (1, A), (2, B), (3, C), (2.5, N) } or
> >> is it UC2: { (1, A), (2, B), (4, C), (3, N) } ?
> >
> >It's UC2.
> >
> Why? (Okay, I do agree with you. But why?) I think it's because your
> ordering column is actually "list position" which by definition must be
> a sequential integer.

Exactly.

> >> In the case of UC2 every insert causes updates to
> >> all elements that should be after the new element.
> >
> >Let us also consider the two other common implementations
> >of lists: linked lists and arrays.
> >
> >In UC2, an insert requires O(N) time: every index above
> >the one inserted requires updating. In a linked list, an insert
> >requires O(1) time, but locating an item in order to insert in
> >front of it is O(N). In an array, an insert requires O(N) time,
> >because you have to move all the higher elements up.
> >
> >The issue here is not performance, it's interface. Using SQL
> >to manipulate ordered data *where the ordering is positional*
> >and *not by any logical component of the data* is just way
> >too hard.
>
> Is it "way too hard" or is it simply because the underlying relational
> model has no concept of order?

It's too hard because SQL doesn't have primitives that make it easy. If it did, it would be easy.

> >"Lists are very common, and SQL doesn't handle them well at all.
> >RM doesn't handle them well either."
>
> :-)

I figured we'd agree on that point.

> >Let me expand on what I mean by "handle," and to do so,
> >I'll use the "structure, integrity, manipulation" definition of
> >a DBMS.
>
> Of a DBMS, or the relational version of that definition?

It's a definition of DBMS; it's independent of whether the DBMS is relational or not.

Marshall Received on Sat Jul 10 2004 - 03:41:22 CEST

Original text of this message