Re: Implementation of boolean types.

dawn wrote:
> Marshall Spight wrote:
> > It's entirely
> > possible to have a relational system with vanilla 2VL.
>
> And likely wise too.

We agree on this point.

> > > I agree with that too. In fact, all models and all products are
> > > flawed, but some are more useful than others, right?
> >
> > Sure, I guess. Maybe "limited" is a better word than flawed here.
>
> This might be a matter of defining terms. In that the RM is a
> mathematical model and the mathematics underlying it have been defined
> in a formal system, etc, we could call the RM correct. The flaws with
> the RM are introduced in the mapping from "reality" to the model.
> These flaws limit the usefulness of the model. A model is a
> mathematical metaphor, so it doesn't tell the entire story accurately.
> It is flawed in that regard. And then there is the implementation of
> the model, which is a model of the model, introducing more flaws.

I would say 'abstraction' rather than 'metaphor'. And I don't think the word 'flawed' is quite right. For example, the mathematical abstraction of addition can be used to make prediction about how many of something you'll have when you combine two groups. It is always accurate; you never put together two apples and two apples and get five apples. It it true that addition doesn't tell the whole story, but since it does not claim to I don't see how you could call it 'flawed.' 'Incomplete' maybe.

> Where and how should types and schema be defined; where/when should
> problems be identified during the construction and maintenance
> processes; and when a change is needed, what does it take to make
> various types of changes and where do such changes need to be made? I
> think that as an industry we could do much better than we do now.

I'm not sure I understand what all you're trying to get at, but I can pick out schema migration issues from you're saying. I agree that that, and software versioning are areas for improvement.

> > You can't retrofit these things; they have to be designed in from
> > the start.
>
> From a statement like that, which seems so right when you hear it, what
> would you conclude about the implications and cost of changing
> requirements?

Uh, that it sucks? every project I've ever been on has had requirement changes. Wait, maybe that's what you're saying. We should design systems
that accept change well, yes? I'd certainly agree there. But I don't see anything specific to RM here. If anything, I would propose that having a good formal foundation would enable us to define better how change management should take place.

> > > Certainly preferred and there will definitely always be flaws, but I
> > > don't think we are too far off from significant changes in the database
> > > world and XML will surely play I roll.
> >
> > It'll be sad if it does.
>
> There are several things about it that are not at all sad. SQL-DBMS's
> can make for overly costly software development and maintenance. I
> know that we can do better and this could give us a means to do that.

I really don't see how. Just because there are limitations of the current best model doesn't mean that any other model we come up with is going to be any better. And in particular the xml model is much worse,
lacking even the most basic of data management features.

> Taking the industry from thinking of data in terms of graphs and paths
> to making it a no-no to think of data in any form other than sets was a
> "throw the baby out with the bath water" approach (terrible metaphor
> that one is).

I don't agree. Manual navigation is an inferior technique to using content-based addressing.

> Without taking everything we have done with SQL-DBMS's,
> but what we have learned about working with sets and set operators, and
> adding back what we have learned about navigating around data, marking
> up data that are not best captured in smaller pieces, using a 2VL,
> working with collection types such as lists, etc, we ought to be able
> to make significant improvements. Then answer some of the questions I
> put up front regarding typing (and other constraints) in a different
> way than we do with the SQL-DBMS's, or at least providing options, and
> we could get to something much better than what we have today.

Could you be explicit about what these questions are?

> > But you may be right.
>
> of course I am ;-)
>
> >
> > > > (Yes, I know XML now has various ways to specify schema,
> > > > with at least DTD and XMLSchema. [Does anyone anywhere think they
> > > > are good?]
> > >
> > > Not I, brother.
> > >
> > > > Reminds me of the old saw about a man with two watches.)
> > >
> > > I must be too young to know that one, so feel free to fill it in
> >
> > "A man with one watch knows what time it is; a man with two
> > watches knows nothing."
>
> love it
>
> > --> XML has two different systems
> > for specifying schema. And despite the fact that XML is the
> > perfect universal format for storing everything, one of them
> > isn't formatted in XML!
>
> I just prepared an xhtml page that points to the transitional .dtd and
> uses a .css for the style. And then that way cool Javascript ...
>
> >
> > > > Anyway, XML doesn't address data management; it's a document
> > > > management system.
> > >
> > > Sure XML is just a format. But is a format that doesn't play nice with
> > > SQL-DBMS's (and, yes, I know of everybody and his brothers adapters
> > > with one end connected to the SQL-DBMS and the other to XML, but some
> > > folks like me will want that unnecessary component out of there).
> >
> > Somehow I missed the end of that sentence.
>
> Nope, I did. Because XML and SQL-DBMS's don't play nice, we need to
> have those way-too-prevalent connectors. If software can be written
> where the data structures persisted in memory can be the same
> structures stored on the disk or any other media, we can avoid some
> costs and gain qualtiy, I suspect.

If you mean the *logical* structure, then yes. I note that Other than the bare rm, I haven't really seen alyone attempt to come up with a framework for talking about logical data structures. Say, something that accounted for different kinds of logical trees.

> I'm not a MySQL fan by any stretch, but recognize that it is the entire
> system as a whole that needs to manage data integrity. There is more
> than one way to partition a system and placing all constraint logic in
> the DBMS tool (either in addition to or instead of elsewhere) might not
> yield the best overall solutions.

we've had this conversation before!

> Price, sure. But I suspect that the fact that considerably less
> constraint logic is encoded in the DBMS is also a feature.

Ugh. Strongly disagree here. Although it may be true that this approach appeals to novices and those who don't know any better. I am soorry if that sounds harsh, but application-enforced integrity is just not the answer to anything.

Marshall Received on Sun Jul 24 2005 - 22:33:12 CEST