Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: 3vl 2vl and NULL

Re: 3vl 2vl and NULL

From: dawn <>
Date: 15 Feb 2006 18:06:05 -0800
Message-ID: <>

Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> > <snip>
> >
> >>>Now you are preaching my sermons. I definitely care about scalability.
> >>
> >>Who doesn't? However you seem to be more significantly more concerned
> >>with flexibility. This is strongly evidenced in your writings and has
> >>IMO resulted in an incorrect balance derived from inflating the apparent
> >>(as you see them) detractions of RM whilst discounting any possible
> >>slurs on the MV sphere (which you know and lurve).
> >
> > I realize I come across that way. I suspect that over the past decade,
> > I have identified and talked about more things wrong with MV than with
> > RDBMS's.
> For my benefit can you identify the top 5 (in your opinion)?

  1. The query language has no corresponding update language ever put into production
  2. The DataBASIC language often used in MV solutions at least as the language for the equivalent of stored procedures is a great procedural language and is loved by many (and I have not coded much in it), but it isn't quite the state of the art in programming languages in 2006 that the pretty-much exact same language was in 1976. It has not had 30 years worth of keeping up, but the good news is that it is reasonably standard across vendors (with zero standards bodies).
  3. In some ways, it would be as if you had a SQL language without the ability to specify a join within the statement. For many (not all) of the MV vendors, every attribute required for a query in the query language must be defined as the vocabulary of a single logical view of the data. Some tools are better than others in being able to navigate (I know that word trips buttons) via foreign keys. The flip side on this is that it is easy for end-users to write queries since they only have the option of writing the query against a single logical view (which can, of course, span files).
  4. There is no standard across vendors for a data source definition. There is no standard for client-server connectivity. This gives third parties the floor to write products like the jBASE mv.NET product that works with many different flavors of MV.
  5. Third-party products for Business Intelligence and practically everything else speak ODBC often with direct access to SQL databases, but SQL is a second language (at best) for MV solutions and not the best way to access the data since you take a flexible model and constrain it with SQL (which adds fixed lengths, for example). This lack of being able to play easily with the SQL industry is one of the biggest reasons that many companies have moved or attempted to move to SQL Server or other SQL-based solutions over the years.

I'm not sure these are my top 5, but they are 5 of the top issues I have with MV.

> > When talking about data modeling, however, that is one area
> > where I cannot leave MV behind unless I can find a better data model.
> > That was frustrating given that it is the data model part of the RDBMS
> > that was touted from the start and the reason it was supposed to be so
> > far superior to other databases. It is less of a mystery to me now
> > than when I came here, however.
> OK - but to summarise our discussion to date your problem with the RM is
> the inherent constraints prevent you from having a visually aligned data
> model that correlates exactly with the user view of the data model as
> particularly expressed by the UI.
> Is this a (relatively) succinct statement of your view?

I don't think so because I think your defs sound different from mine. By "correlates exactly with the user view" it sounds like you think I want the data from a single screen to be stored as a single entity or something like that. I would not look for the logical data model of UI screen to be identical to the logical data model of the database. Surely one screen might collect data that updates multiple entities.

I also do not claim that the data model (abstraction of the language) of the user interface must be the same as the data model of the database. Clear that is not the case. My claim is that the data model of the user interface cannot be the RM (as it stands today)

> [..]
> > There is some risk you can eliminate, but I'm not sure the risks, for
> > example, of bad data or poor programmers (or good programmers sometimes
> > producing poor code) can be eliminated with reasonable cost. I do
> > think that the lock-down vs. enough-rope-to-hang-themselves approaches
> > each have different risks.
> Definitely - I prefer the former because it increases transparency by
> reducing the possibility of a clever type obfuscating the true situation
> by insisting you "never mind the quality, just feel the length". Yet
> again a dailywtf demonstrates this sad trait is alive and kicking in the
> industry.


> >>>>Getting the union is the trick. Where I see the RM
> >>>>playing a part is in assisting in retention of the union even as
> >>>>evolution occurs.
> >
> > Is this intrinsic in the RM or part of the lock-down approach? If you
> > were to add in ordered lists as a viable type (which I think some SQL
> > tools might do?), thereby ignoring the Information Principle and no
> > longer using RM, would you lose the feature you want?
> RM is to the extent ppl accept and use it is a "lock down" approach. I
> recall the latest SQL standard does have sets as a domain type - but I'm
> not sure they are ordered.

Yes, I did a little dance of joy when I learned that a while back. There is no consistency in vendors implementing this, however. I played with PostgreSQL at one point and liked their implementation of parent and child tables. IIRC, you could do select * and get all attributes from parent and child.

> Regardless, as you imply, to adopt features
> like those you tendered does weaken the outcome. My response is not to
> throw out the baby, but prohibit the use of these non compliant features
> in my shop. Anybody report who thinks differently would find it career
> limiting first and sayonara soon thereafter!
> For the record my pet hates at the moment (but not a comprehensive list
> at all) are:
> a) on delete set null

good call

> b) CLR

Are these both SQL Server only? I don't know what the downside of CLR is.

> >>>I think that many people who employ the RM think they are optimizing
> >>>the cost of ownership over time where I don't think that is the case
> >>>(but I don't know how to prove or disprove it inexpensively).
> >>
> >>Perhaps because you would use a MV style of thinking in the analysis.
> >
> > Perhaps, but doubtful. Examples I have given in the past are related to
> > changes in the conceptual model for increasing the cardinality or arity
> > of an attribute require few changes in schema or applications using an
> > MV or XML data model, for example, while they require much more
> > significant changes to the RM model and related applications.
> I would hold that if such an act proved difficult under the RM then I
> would first seriously question the requirement in its own right. For
> instance a business request to support recording of a text value "NIL"
> in the Balance when it is currently a numeric attribute, simply so it
> could be reported as that (rather than 0.00) on a statement is surely
> fatuous. This is a rather obvious example, but less clear cut cases the
> RM acts like a canary in a coal mine! This nature survives your (sic)
> initial project activities and your continued involvement unlike an MV
> situation where the sum of the cults of the individuals will accrete.
> Of course this negative trait can be mitigated by skillful management,
> however the Peter and Dilbert Principals will prevent this arising.
> >>Given its propensity to allow the mind to wander where ever it likes
> >>perhaps the analysis would never be convinced it is at a conclusion?
> >
> > It seems the opposite. Because you can rather easily change things
> > later, there is more inclination to "jump in" so it works very well
> > with an agile methodology. I recall when a CMM (capability maturity
> > model) methodology person came into a PICK shop (of ~200 developers) at
> > a high level and did some applecart upset, but didn't last long.
> This simply confirms what Canute discovered. His goal may be correct
> but his method not. That doesn't mean it is unachievable as the Dutch
> have showed.

Unless you are talking about King Canute and the Dutch holding back the sea? That is the only thing that comes to mind, otherwise I'm clueless on the allusion.

> > MV developers are inclined to prototype in the target environment and
> > then migrate that into the solution. I recall this being a no-no from
> > at least the early 80's so I was surprised to find this happening in
> > '89 when I landed as a manager in a PICK shop and even more surprised
> > to find I was encouraging it in no time. This flexibility carries on
> > even once deployed. Is it possible to get the features you are looking
> > for along with this type of flexibility?
> Yes - but it must be self imposed.

Hmmm. It seems like the changes required if you were to add cardinality alone would make it hard to do iterative prototyping and take it all the way into production. I haven't worked with SQL Server, however, and the toolset might be good enough to make this feasible if managed well. Cheers! --dawn Received on Wed Feb 15 2006 - 20:06:05 CST

Original text of this message