Re: Data Redundancy

dawn wrote:
> Marshall Spight wrote:
> > Jan Hidders wrote:
> > >
> > > Just out of curiosity, in which MV DBMSs would it be possible to specify
> > > a declarative integrity constraint that said that one relationship
>
> There are no declarative constraints in MV. What does it matter if
> they are declarative, procedural, OO, functional or whatever type of
> constraints?

Step 1:
Whatever your application is, you first have to specify what the constraints are, formally enough to be unambiguous.

Step 2, for "procedural, OO, functional or whatever" Now you have to manually take the formal specification and turn it in to code. For the constraint to work 100% of the time, it cannot have any bugs or missteps in the translation from step 1. If you have multiple application languages updating the data, you have to recode the constraints in each language, being sure to keep them in sync forever. If you have multiple places in application code where the data can be updated, you have to be sure to identify every one, and apply the appropriate checks at each update site, and keep this up to date forever.

Step 2, for "declarative"
There is no step 2 for declarative.

That's why it matters.

> > > (emp->dept) is the inverse of the other relationship (dept->emp)? Or how
> > > else would you prevent inconsistency in your database?
>
> Just as it is prevented in other systems -- with hand-coded software
> associated with these data. In the case of an RDBMS that might be
> written by a dba using a declarative language, where with MV, it would
> be written by the software developers in services used for updating the
> database. An application developer would then write code using these
> services rather than directly accessing the database.

How do I say this? That, my dear, is a *terrible* answer. Judges subtract 1000 points from the MV player, who will now not be allowed to advance to the bonus round.

> Oddly enough, this services approach is becoming popular now
> even when using an RDBMS.

Yes, they are becoming popular. I have spoken with many people advocating and building these kind of services, and I haven't met one yet who had any experience with declarative integrity constraints. You can't make a reasoned decision between alternatives when you've only heard of one of them.

> These "return links" (which are admittedly redundant data) are very
> common, incredibly common. I'm guessing there are times when problems
> occur that toss things out of whack where a repair routine would need
> to be run, but no such issues ever bubbled up to me as I recall. I
> never worried that payroll would not go out or students would not get
> registered because the return-links were out of synch, for example.

If you work only on smallish or highly heterogeneous projects, this sort of approach will mostly work. It doesn't scale, though. At least not in my experience.

> > To my mind,
> > SQL handles this case just about perfectly. It was exactly the
> > example that made me want to investigate SQL in the first place,
> > after I had been pointing at it and laughing for quite some time.
>
> And here I went the other direction, assumed it deserved my respect
> (and it does) and promoted it then experienced that it just wasn't
> quite up to par on some important fronts like developer productivity
> and cost of ownership.

Perhaps that explains our relative positions. I had to be convinced; you trusted. You got burned. Now instead of trusting, you've moved to the opposite extreme.

New idea: have you considered the possibility that the teams you worked with just weren't any good with SQL?

Marshall Received on Fri Feb 17 2006 - 05:59:28 CET