Re: Why not many2one with pk array type

David Portas wrote:
> Sandy.Pittendrigh_at_gmail.com wrote:
>
> > I disagree. Relational design is inescapably subjective.
> > Normalization rules are not rules, they are guidelines.
> > No two programmers model the same complex data problem the same way.
>
> There are subjective design decisions to be made in hierarchical models
> too of course,

agreed

> but RM has enormous and proven advantages over the
> hierarchical ones.

I have looked for these proofs. I can see trade-offs where one approach has advantages over another approach, but can you point me to something that nets it out and really proves that the RM had advantages over any other model?

> I'm not necessarily endorsing your claims, but if
> they are true then I would look for different solutions than the one
> you have proposed. On the whole, developer time costs much less than
> the value of data integrity, data independence, guaranteed access, etc.
> To compromise those relational principles for the sake of faster UI
> development seems like a poor trade-off, especially given that the data
> (not necessarily the data model but certainly the data) will usually
> have a life and a value way beyond the application that serves it.
>
>
> > Hierarchical databases have other problems, but GUI mapping is not
> > among them. A program can read a hierarchy and then generate a matching
> > data entry form that works, without intervention by a programmer.
> > Same for data query.

Yes. If you would like to work with an open source database that permits lists, including lists of foreign keys, you can check out openqm.com. I mentioned it and showed an example of a list in my blog (www.tincat-group.com/mewsings)

In your example of a list of foreign keys, you typically also have a foreign key on each target for these foreign keys. These have been called "return links" not unlike return links on a web page. This means there is redundant stored data. I taught SQL to people who use the multivalue model and one of the aha moments was if they finally figured out that you always had to think from the many to the one, due to the 1NF restriction. When you work with embedded lists, you think from the one to the many much more often. That is often how you want the UI to think too.

> >
> > That is now and never will be possible with relational systems.
>
> An RDBMS can or could expose exactly as much metadata for a GUI mapping
> tool as a hierarchical one can - for example through business rule
> constraints exposed in catalogue views. Are you claiming that there is
> metadata inherent in a hierarchical database that cannot be represented
> relationally? That would seem like a startling claim. Can you
> substantiate it with an example? If not, it seems that your program
> must have exactly the same opportunity to map a GUI from both
> relational and hierarchical systems.

I suspect this has more to do with the available operations than with whether the data could be mapped. cheers! --dawn

> --
> David Portas
Received on Mon Jan 30 2006 - 00:50:31 CET