Re: Ping: dawn, some mvl questions

Kenneth Downs wrote:
> Dawn,
>
> One of my practical objections to MVL is that it obscures data. I'd like to
> know what you might offer to that objection.

I'm not sure what MVL is, but I'm guessing the MV part is the Pick MV (multivalue). Is the L for list? language? If so, which language?

> I am in the school of thought that says that if you need a list, make a
> table,

How 'bout if you need a list, make a list?

> that's what the RM is for. Then if you need to manipulate that
> list, use SQL.

Been there.

> All common patterns, such as header-child for orders, lists
> of flags or dates, and so forth can all be done with child tables.

Yes.

> When an MVL comes, which is fully supported in the PostgreSQL database that
> I use,

PostgreSQL seems to have a good implementation of parent-child, although using sets (lacking lists).

> I notice you end up needing a different word for everything. You
> can't just query a child table, you need new operators like "ANY OF {field}
> = " or something along those lines.

"Any of" is the default, while "EVERY" would need to be specified. Write an SQL statement analogous to the MV statement

LIST STUDENTS WITH EVERY MAJOR != 'MATH' That will give you an idea of the charm of the queries in MV.

> This is where my objection comes up. Now I need an alternative syntax. But
> what if the values in that list come from a table,

You could create a logical list that is populated by elements of a set, ordered however you like. The key to success with MV is to think in terms of language. What terms do I need and how do I define them? So, there are a lot of "virtual fields" (derived data, computed columns) in the metadata of most MV systems (not all). This gives you an opportunity to describe the same data in many different ways using different terms. If an XYZ date is stored, but the month is frequently "referred to" (in reports), then make a new dictionary entry for XYZ_MONTH, for example. If a date is stored and we do not need to "talk about" the month separately, then don't make such a dictionary entry.

> how do make foreign key,

The same way you do in any system. Think of the model being like an XML document model with only XML entities (called attributes) and not attributes. Add in an attribute for a foreign key. You can also add in a multivalued attribute for a foreign key to a child table.

> and what if I want to populate a cross-reference?

What is the problem you perceive with that? Perhaps an example would help.

> When does it end? How
> much alternative syntax will I need?

The MV query language does not have the same goals as SQL. There is no goal that you can ask any question without ever adding to the vocabulary in your dictionaries, for example. XQuery has more of the same goals as SQL, so you could look there to compare syntax and see "where it ends." The MV query language is very elegant in one way, while ugly in that you might have to define new vocabulary before you ask a new question (typically you do not, but you might).

> The question becomes, what do I gain that I don't get from a child table
> that is worth the price of a "different word for everything" when I deal
> with these lists?

Having child tables implemented as in PostgreSQL (where you ask SELECT * FROM PARENT; and you get all child entries too) is a big advance over what most implementations have or at least what most developers use. Permit the child table to be a child list and you get the added benefit of a library of list functions in the dbms. I mentioned the approach sometimes used of providing an attribute with a numeric value where you spread the values out so you can insert between them. I saw that recommended in a book or article a while back. Sure, accountants do that with GL numbers, but that is really a poor approach to providing an order to a list so as to avoid insert (and renumber) and delete (and renumber) routines when a list is specified as a set. That is just one of the maintenance issue with data and systems that arises when a list (or array) is not a standard type.

Let me know if that did not make sense. Thanks. --dawn Received on Sun May 21 2006 - 04:36:41 CEST