More on lists and sets

We've discussed how a set (or pizza toppings) might be stored in a list, for the sake of convenience, but the retrieve dand used as if it were a set. We've also discussed how a set of tuples, with one attribute thrown in for sequencing purposes, can, for all intents and purposes, be treated as if if were a list.

I want to turn my attention to the discussion of lists and sets from the logical and or physical design perspective. Marshall Spight recently said that nearly all programming languages offer support, in one way or another, for lists. Support for sets in much more spotty. Marshall figures that a good language will have to allow for both. Without disputing that conjecture, I want to turn my attention to facilities that can convert easily beck and forth between sets and lists.

In particular, if you look at SQL as a prototype for some future interface language, it's useful to look at views and cursors. A view is basically a named query declared in the context of the database, that can be invoked to play the role of a table. A cursor is a named query, declared in the context of a user process (program), that can be invoked to play the role of a list. I haven't seen cursors discussed as if they were lists, but it seems to make an eminent amount of sense to me.

If you'll allow me to stretch the concept just a bit, it seems to me that you can look at both a Pascal file type, and a unix pipe as a list (of file elements). And a cursor seems to do the same thing. I don't know how I would express going the other way. That is, how to declare a list, load it with data as if it were a list, and then turn around and deliver it to the database as if it were a table. What I'd like is some kind of compromise between unix pipes and the concpets behind Oracle's SQL*loader. Something that would look like an output file, but really be a pipeline into the database for bulk loading in a single transaction.

What do you think? Received on Mon Mar 20 2006 - 19:48:37 CET