Re: Resiliency To New Data Requirements

JOG wrote:
> dawn wrote:
> > [snippage]
> > I'm OK if relational theory doesn't cover working with lists as long as
> > relational theory is not all that is employed. We can use set
> > processing for some things and pull in the list processing for others.
> > It is only when relational operators demand exclusivity at some level
> > that I have a problem with it.
>
> Relational operators only demand exclusivity at the bottom level.

Yes (or the "top level" depending on your perspective). There really is only one additional construct I'm looking to be supported at that level -- the list.

> Anything you want you can layer on top. From your posts I figure that's
> good enough for you ;)

I have such great retorts for that, but I think I better hold my tongue.

> > [snippage]
> > > I have personal friendships with some of the most influential people in
> > > hypertext and the internet. To a man they all loathe the hideous mess
> > > that is the web
> >
> > And all of the women in software development in my county (OK, there
> > might be another one somewhere) think it is beautiful in its
> > usefulness, simplicity (well, maybe not, I can't believe how hard it
> > was to make css and xhtml work in both IE and FF)
>
> Quite. The www is only a dog compared to what it could be like. Its
> still pretty damn useful as it is.

Agreed.

> > > It is a publishing medium (and a poor shadow of what it
> > > could have been at that),
> >
> > Wouldn't it be better to say "could be"?
>
> No, I think the web is too entrenched now. It'd take a revolution not
> an evolution.

Like some ignorant, moronic girl trying to move the industry away from SQL, right?

I remember someone telling me that we would still be running gopher ten years from now because there was so much there ('92 or '93). But, yes, a migration over time - we are not going to swap out either current www nor current sql-based solutions in an instant.

> > > but can hardly be processed as a data model.
> > > I'm guessing that your reference to www was tongue in cheek.
> >
> > It was a counter-example. Your words were "information handling" so it
> > worked.
>
> But you knew what I meant dawn, and were just being polemic.

Maybe a little, but the www is still a very large distributed database of sorts. It has structured data (in spite of what others might call it), persisted on secondary storage devices, accessed by people. There isn't a great query langauge, I'll grant. The requirements are not identical to those of a DBMS, but the model for the data ought to be taken seriously and moved forward accordingly.

> Paper
> holds information, but its not gonna be too hot for data modelling.

I do understand your point, but again, there doesn't need to be such a huge difference between those who would draft what we once called a "data entry form" on paper (which we still end up filling out often in life) for filing in a paper database and those modeling data for a computerized database. There is quite a bit of commonality, even if some differences.

> > [snippage]
> > > and hey we know from irreducible tuples,
> > > that a lot of information _cannot_ be broken down into binary form.
> > > Thats exactly why graph databases and the Semantic Web are such a load
> > > of tosh.
> >
> > I just deleted a clever response here, but the upshot is that I've read
> > quite a bit of the semantic web stuff and I'm not a believer yet
> > either.
>
> There is no clever response that can't be refuted when it comes to the
> semantic web ;) It's a dead man walking because of RDF's ternary nature
> (although it may be a long walk).

Agreed, oddly enough.

> > [snippage]
> > And I do like Tutorial-D's group and ungroup that at least gets at some
> > of what I want. Add in a few more features for list handling at the top
> > level, permit synonyms (of different types), and a bunch of other
> > features and we just might be able to combine a good theory with good
> > practice.
>
> Well that's certainly a change in standpoint.

I've learned a lot from you guys. I came here to learn and I have. I have learned more about human nature than I really wanted to learn, but ah well.

> (I have a great deal of
> respect for those who can change their opinions after doing the
> research, especially after being on the wrong end of a lot of stick)

I'm still pretty much on the unpopular side of most related discussions, but I can see a little better how my requirements should not be too far fetched for relational theorists (many already accept my 2VL approach, so they just need to dump the information principle and adopt lists ;-), even if still a ways from RM implementations.

> Nothing wrong with layers on top of RM

If lists are in the data model employed by designers, developers, maintainers of software, then it is not "on top of the RM" it is a new model. So, we still differ on terminology.

> and I agree group/ungroup normal
> form is very interesting.
>
> > Pick is practical in a big bang for the buck way.
> > Relational theory is elegant in a mathematical way. I don't want to
> > cheat on either theory or practice, but if they aren't going to align,
> > I'm stickin' with practical and flexible.
> > Cheers! --dawn
>
> I'm a firm believer that we can, in the end, get everything we want
> from building up theory without resorting to diving in headfirst with
> ad-hoc models.

That would please me. If I thought ad-hoc was the best way to go for the long haul, I wouldn't be reading cdt. But neither do I think the "look, there's a mathematical theory, let's go there" approach served the industry well.

> Its always just a case of clarifying and iterating
> theory to get there. (i.e. Codd's legacy is certainly not dead).

I agree with the last statement. But I would add to the first statement something about how we need to refine our practices as well and not accept theory without testing it out to understand in terms of resources and quality just what we gain with any given theory before we ditch known best practices and jump on theory bandwagons. A theory, like relational theory, might be tight mathematically, but that is no proof that it is the best way to model propositions, for example. I might not have said that well, but I'm clicking to send anyway. Cheers! --dawn

Thanks for the dialog, jog. --dawn Received on Wed Aug 16 2006 - 03:51:56 CEST