Re: Ideas for World Hierarchy Example

Neo wrote:
> > It is easier to implement n:m relationships between "entities" using the data
> > modeling approaches for non-1NF dbms's than for 1NF, right?
>
> My 2X, electric can opener is in hand, so why not.
> Suppose ball1 has three colors: red, blue, green.
>
> RMDB Solution #1
> toy colors
> ball1 red, blue, green
>
> RMDB Solution #2
> toy color1 color2 color3
> ball1 red blue green
>
> RMDB Solution #3 (do you like my pointy notation?)
> ->ball1 ->red
> ->ball1 ->blue
> ->ball1 ->green
>
> RM purists usually go for third gear with two extra tables to boot.
>
> Is MV similar to RMDB's solution #1 (not sure).

Sortof, I guess. I'll use [ ] to show a list.

toy=ball1
colors=[red,blue,green]

An aside, Although one lists records across the page (if desired) with column headers and the like, when looking at a record in MV, compared to looking at a computer punch card, the values in a record are typically looked at in a list like above with field numbers (instead of toy it might be 0 and instead of colors it might be 1.

> And some type of
> separator allows multiple values

Yes, although this is misleading as in MV "some type of separator" also allows for multiple records in a file and multiple attributes in a record. That is one reason it is not quite like someone sticking comma delimiters in an RDBMS field value.

> and its SQL-equivalent manages with
> it.

Yes, when it comes to queries, but I do not think of MV having a SQL-equivalent as it takes a different approach to queries and doesn't have a similar update language

[huge history on that and it was Dick Pick's pet project to implement something at one point, which is referred to as "the update processor."  This tool was/is not quite a language in the same way as SQL or the MV query language, but rather a tool for both easy and complex updates (maybe thinking in terms of updatable views helps to understand the added complexity addressed with update than query). It was even demonstrated with a chair that had a foot pedal that could be used instead of pressing the control key, so you entered your commands into the update processor by stepping on the pedal and typing a character. When people say "show me exactly how this or that compared to SQL" I am not sure how many ways to say "apples and oranges"]

> Both solve the same problem in slightly different ways. BOTH
> SOLUTIONS ARE slightly FLAWED (in terms of redundancy/systematicness),

I would say that both are more than slightly flawed. In the case of Pick, I'd suggest that the data model today is better than its implememtations. In the case of the RDM, I'd suggest that the products are better than the data model. There are flaws all around, however, I'm sure.

> so I can't grasp why all the ruckus in cdt over this iddy biddy issue
> ???

If not here, then where? People who are interested in a particular area have different details about which they care.

> > But I have worked with both [RMDBs and non] and there is a decided
> > difference, where I know what the clear favorite is for me, even if you
> > have a different preference.
>
> Could this qualify as empirical evidence :)

If all anecdotal evidence and individual preferences could be classified as such, then sure.
cheers! --dawn Received on Sat Jan 13 2007 - 00:52:57 CET