Re: Implementation of boolean types.
Date: 22 Jul 2005 06:46:46 -0700
Message-ID: <1122040006.937879.29460_at_z14g2000cwz.googlegroups.com>
Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> > > dawn wrote:
> > > > Marshall Spight wrote:
> > > >
> > > > This is one of several features where those attempting to implement
> > > > relational theory took what was working in databases in the 70's (such
> > > > as 2VL) and mucked it up, contributing to greater cost of ownership for
> > > > data-centric applications.
> > >
> > > Hmmm. I detect that perhaps you are trying to identify this issue
> > > as being somehow a consequence of RM? If so I would not agree;
> > > the issues are independent.
> >
> > Even if current RM theory accomodates 2VL, is it historically
> > inaccurate for me to suggest that before Oracle and other SQL-DBMS
> > products became popular most developers working with stored data were
> > using 2VL, putting ^000 or low-values or some such in "empty" fields?
> > I admit that I did not research it, I just lived it and certainly not
> > all of it. I think of SQL as bringing the 3VL into popularity, but I
> > could be wrong. Attempts to implement the RM have been almost
> > exclusively with SQL-DBMS's, so practically speaking it is the products
> > that stem from the RM that have brought this on, whether they needed to
> > (and we know they didn't) or not.
>
> If you're proposing that SQL is the thing that popularized 3VL,
> I won't disagree.
Yes, that is the point.
> (I don't have any particular information on
> this topic.) But if you're proposing that any RM-based system
> will necessarily have 3VL, then I disagree.
I did not intend that. The RM need not be used in connection with a 3VL.
> It's entirely
> possible to have a relational system with vanilla 2VL.
And likely wise too.
>> >
> > > I don't think I'd agree with this either. SQL needs to be replaced,
> > > not fixed,
> > Complete agreement on that point.
>
> Whee!
> >> > I agree with that too. In fact, all models and all products are
> > > and the XML-family of technologies are fundamentally
> > > flawed.
> >
> > 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 don't think any "data management" system that doesn't
> > > have a type system or a schema in version one is going to go anywhere.
> > I think you might have to eat those words, but we shall see.
>
> You're anti-static typing then? Don't tell me you're anti-schema?!
Absolutely not. I am definitely a fan of static typing, although perhaps not with the same type of implementations as prevelent today. See next comment.
> (Gasp!) Seriously, though, looking back at my original wording,
> I suppose I should have said "anywhere useful." I find it hard
> to imagine how anyone can advocate data management without a
> type system and without a schema.
>
> > > 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?
> > 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. 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). 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.
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 ...
>> > with one end connected to the SQL-DBMS and the other to XML, but some
> > > 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
> > 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.
>> > to add their own new attributes (having just read the other thread on
> > Somewhere between the SQL-RDBMS and the Semantic Web, exclusive, lies a
> > model and implementations thereof that will do a big-bang-for-the-buck
> > job and developers will flock to it -- perhaps a hosted database with
> > an intuitive interface and constraint-handling that permits end-users
> > that).
>
> Meh, I dunno. Just because something becomes popular doesn't mean
> it's good, or even the right tool for doing data management.
I've been saying that related to another big buzz word in data management that hit hard in the 80's and is still king of the hill today ;-)
> MySQL
> is about the worst SQL-DBMS for managing data integrity,
> and it's
> also the most popular. Maybe its popularity has more to do with
> the price
Price, sure. But I suspect that the fact that considerably less constraint logic is encoded in the DBMS is also a feature. Software developers want systems that can be maintained and the SQL-DBMS implementations have not provided the most flexible sandboxes.
> than with the suckiness. All the good SQL-DBMSs cost
> big quatloos.
Not all. ;-) Cheers! --dawn
>
> Marshall
Received on Fri Jul 22 2005 - 15:46:46 CEST