Re: foundations of relational theory?

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<bn62u5$1gv4$1_at_gazette.almaden.ibm.com>... [big snip]
> Can you list all the parts of the MV model?
>
> The relational model has relations and relational algebra. You equivalent of
> relations, FILEs, are more complex than relations. So unless your
> manipulative part is a lot less complex, I think you will find that our
> whole is less complex than yours.
>
I think there are folks who could give a better answer than I, but at a high level, MV has as its parts: key strings, value strings & delimiters

Modeling: Take sentences with values to be persisted, drop the words that do not add information for our purposes, identify a possible unique key string for this proposition, and stick delimiters in (maybe use <metadata> </metadata> when modeling data these days) -- the delimiters are different for file marks, record/item marks, value marks, and sub-value marks. Which mark to use depends on the function of the values within the language -- if you can diagram sentences from grade school, you can likely figure this out.

The mathematics of diagramming sentences could be more complex than the mathematics of relations, but our brains can do it handily once we know language. Since we are persisting language (ignoring video, graphics, etc in this discussion), we don't need to try to translate it to mathematics in order to persist it and then apply another translation in order to retrieve it. If you stick with language for your modeling of propositions, you streamline the process, it seems -- no popping from language to mathematics and back again.

[snip]

>>Starting in an RDBMS with relation-valued attributes will

How about -- "Based on my experiences, I do not think that starting in an RDBMS with relation-valued attributes will be as easy to migrate from as starting in an MV". I have only used lists in MV and in Postgresql (and IMS and every language in which I have coded software).

My reason for suggesting that an RDBMS with added relations within relations would be less agile is due to the whole issue of how/where one encodes constraints.

I actually think we agree on much of this, but with me coming down to using a language like Java for all typing/constraints and you having a not-yet-established or proprietary language in mind. It sounds like we both have as a tactic to get the entire "system" (all applications) in a single language. I think Java is a good languaqge from which to build our components to make this happen.

> Fundamentally Dawn, you confuse personal experience with implementations
> with knowledge of what benefits/limitations different logical models impose
> on any possible implementations that are built upon them.

I'll accept that criticism. One reason for studying both RDBMS's and PICK in that past couple of years is that my experience does not synch up with the theory I've learned. So, I have a theory that is well-accepted in the industry that suggests normalizing data (for example) and experience that suggests that almost all data persistence mechanisms that came about prior to relational theories were more agile both for development and maintenance purposes and cost companies a lot less dollars (short and long-term).

I'd be more content to have my experience and theory align and one tact I'm taking with that is to examine the relational theory and see where there are holes. The biggest one I've found is the statement about how we wouldn't want to make the mathematics of data persistence less simple than relations -- that is a religious statement, not a mathematical one, so that is what I'm tackling first.

[snip]
>
> I'm not really interested (here) in what the industry currently backs.
>
> I'm looking forward, maybe to a time a long way off. For that, Tutorial-D is
> one possible beginning.
>

Why not start with Java? What is missing in the language that cannot be built from the existing components? I'll take a look at Tutorial-D, however, since I'm ignorant on that point (as on many others, admittedly). --dawn Received on Wed Oct 22 2003 - 21:39:00 CEST