Re: More on lists and sets

From: David Cressey <dcressey_at_verizon.net>
Date: Thu, 23 Mar 2006 13:21:19 GMT
Message-ID: <jhxUf.5689$8G2.2014_at_trndny01>


"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:j%tUf.49721$F_3.48160_at_newssvr29.news.prodigy.net... >

> If order is unimportant, then transformation back and forth between a list
> and a bag is trivial.

It's trivial in the sense that no non trivial information is lost. But it may not be non trivial in the sense of affecting programmer productivity.

According to the MV enthusiasts, their data structure is more conducive to presenting data "the way people think". I'm not convinced, when it comes to the interface between the database and the programs that manipulate data. However, there is another context, where NFNF data is clearly easier on the eye than 1NF data.

Here it is: It's a window with three frames inside it. The first frame is fixed, displaying the data that occurs once per entity. Each of the two remaining frames shows a scrolling list, for related data that can occur multiple times.

I'm kind of sick of pizza right now, so here's my example:

The window is of applicants for a job. The first subframe is for data like First Name, Last Name, SSN, etc. that occurs once per applicant.

The first list is for skills the applicant possesses, with data about number of months of experience, and certification (yes or no). Each skill occupies a line in the frame. If there are more skills than fit in the frame, scrolling happens.

The second list is for previous jobs the applicant has held. (Start date, end date, job title, etc.). There's one line for each job. Again, if the whole list won't fit in the frame, scrolling happens.

If the applicant is still employed the last "end date" is left blank (Hah! Take THAT D&D!)

Clearly the two lists can expand arbitrarily. (while the relationship between skills and previous employers might exist, it might not be relevant for this screen.)

In this case, I'm interested in storing the data in relational tables (because of the power described by Codd Date & Darwen, etc), but I think a programmer is legitimately interested in viewing the data as if it were a hierarchy. (I'm treating HDM and MVDM as equivalent for purposes of this illustration).

So I'm interested in a sublanguage that can SELECT the data using relational operators to join data from at least 3 tables, but can DELIVER the data to the program in NFNF (see Dawn's blog). That transfom is, as you pointed out, trivial from an information perspective.

But it's not very easy from a programming perspective. And programmers would be more productive if it were easy.

This is my version of "have your cake and eat it too". Mike Preece and others set forth the value of "the programmer can do anything he wants". Yeah sure, if the data is in working storage. Even if the data is in a private file that nobody else uses. But if it's in a "large, shared database" then you can't do anything you want, because that leads to chaos. The interests of all the stakeholders in the large shared database have to be balanced. The larger and more widely shard the database is, the larger the community of interests to be balanced.

And that to me is the difference between a "file" and a "database" in a nutshell. Received on Thu Mar 23 2006 - 14:21:19 CET

Original text of this message