Registered: Sep, 2003
Re: Column-Oriented Databases
Posted: Dec 5, 2007 10:39 AM
> > in OO/XML one "walks the tree",
> this is no more a required way of programming to
> such data than it is with relational stores.
> People can choose to do navigational stuff with any data
> > in application
> > code written by the application programmer parsing the
> > live data structure. this is generally done in
> > application coded loops ...
> > one does not do that with the RM, or even SQL; to quote
> > Date: "what not how".
no one, that I know, is advocating building a GUI from DB2. although one could. UML/MDA, etc. advocate building user-facing stuff from a declarative store. there's no intellectual reason why RDBMS can't serve as well as XML for that. see Andromeda (Secure Data), or Little Steps. these use the catalog to store constraints, which get translated into UI rules. if you can stand VB, Chisholm wrote a book about business rules engines. off the mark a bit, but closer than most.
> seems to me I've seen an awful lot of application code
> that does exactly what you're talking about over the
> years, when people start needing to do something to expose
> the data to end users.
again, not apples to apples. see Chamberlin below.
> I agree that manipulating data can be done declaratively
> in SQL but could you please enlarge on how relational
> databases make it possible for an entire system to
> be developed without someone, somewhere writing loops and
> navigational code?
in terms of the read/write of the datastore, see Andromeda, above.
> > moreover, to the extent that that XML attempts to
> > implement "relations" with the ID/IDREF notation, it is
> > left to the application programmer to keep track.
> Now you're really lost me. ID consistency is mandated by
> the standard. The degree of support comes from your choice
> of given engine but an XML document shouldn't even
> validate if ID rules are broken.
unless there's been a recent change, the match is GLOBAL to the document. it is *not* a relational construct. it is surrogate key, sort of.
> > to put it concretely: if one had the BOM for a 777 in
> > there would be 13,457 nodes for a 1"x1/4"x20 stainless
> > steel screw. change the qualification of the steel, and
> > visit all 13,457 nodes. no thank you.
> I'm not denying that someone can do something that stupid
> with an XML document but it is certainly not an inherent
> characteristic of them.
it is of the implementations I've had to work with. YMMV.
> If you have a solid example as to how such a mass
> visitation is really a required activity on an XML
> store I'd love to be educated, seriously. Your statement,
> however, sounds like someone confusing a poor textual
> serialisation of an XML model with the actual infoset. I
> can write out relational databases with redundancies too
unless there's been a recent change, the match is GLOBAL to the document. it is *not* a relational construct.
for a discussion of the infoset, I'll defer to Pascal. it's readily available on the net. and if you willingly
"write out relational databases with redundancies", well...
> > put simply, the world is naturally relational, not
> > hierarchical. the world is naturally aggregate, not
> > inherited.
> the world is full of messy graphs, half-truths and
> Relational is a model which works very well until you
> start taking a very close look at the garbage values
> people put into the content to manipulate the system into
> letting them get their job done.
so, we should empower knuckleheads further?