[
Lists Home |
Date Index |
Thread Index
]
Hi Mike,
> Hmmmm ... it's certainly not a *relational* DBMS, maybe a giant
CODASYL-like
> DBMS ... but I've been wondering about Date's vehement objection to
> "pointers" in the context of XML too. I think he's probably onto
something,
> and having some way of "JOIN-ing" web resources based on value comparisons
> rather than chasing pointers will probably add a lot of value ... someday.
What would happen if we were to further refine the expressed notion that the
entities/representations being passed around under REST in fact be XML
trees - and instead require that they be "relation"s (as per Date's
definition of that term) or possibly sets of interrelated relations. Such
entities may still be _physically_ encoded in XML, possibly using some sort
of canonical transformation between sets_of_relations and trees (assuming
such a thing is possible, as I believe it is, given a compatible
interpretation and treatment of NULL values). Tables in such entities would
thus need to describe their own table schemas, including candidate keys and
the column domains ("types") used, in addition to the actual data rows
themselves.
> BTW, could you elaborate on "the success of CGI systems" ... not sure
> how that relates.
It probably doesn't. <g> My (quite possibly mistaken) notion was that
(some) CGI systems use URIs (or extensions thereof) as "connect_and_query"
command strings into "legacy" DBMS systems.
> - Date is rather adamant that the computer/database industry has limited
> itself by hacking on a failed database model (hierarchical/network) and
> grafting on faddish OO notions rather than fully implementing and
> appreciating the relational model. The obvious rejoinder is that
> the industry builds on what actually works in practice, and the market
> weeds out those who can't make their ideas generate actual economic
> value for their customers. I sometimes wonder if Date's
> canonical rant isn't analogous to someone channeling Turing and saying
> that we should all stick to the conceptual model of an infinite tape
> that reads and writes marks and moves forward or backward .... since
> that is elegant, provably correct and universal.
My own take on this is that Date is quite clearly focusing on DBMS systems
which place a clear level of abstraction (the logical data model) and
isolation (the DBMS)between applications and the data they manipulate,
thereby allowing the applications and the physical database to safely evolve
independantly of each other. In many (most?) circumstances, "application"
programmers don't take kindly to the limitations the DBMS notion imposes.
In general they (we!) much prefer to balkanize the thing into lots of
separate applications, each operating against it's own private data store.
This give the impression at least of faster progress in development,
turnarounds etc., as well as more creative freedom in finding solutions for
the application developers themselves. Whether this is a correct impression
or not I don't know. How one could evaluate the long-term costs of such an
approach cf the DBMS approach I also don't know. Again, there are possibly
parallels here between the REST / DBMS approach and the RPC /
standalone_applications approach.
> - I'm not sure what the practical limit on the number of tables that
> current RDBMs can JOIN across, but it is quite a few orders of magnitude
> less than the number of "resources" on the internet. The Web,
> hack though it may be, actually WORKS!
Are JOINs really an issue here? Any JOINing required to produce an entity /
representation must surely be considered out-of-scope - yes? If the
delivered entities were in fact self describing sets of relations (as per
the above) then there may potentially be some JOINing going on at the
client - but presumably such datasets could be expected to be reasonably
small, and also the number of tables involved.
> - Could a DBMS the size of the Web apply Date's principles and/or
> DBMS best practice without solving the "type" problem?
No, I don't think so.
> A pointer
> doesn't care what it points to, but a JOIN implies some congruence
> of the values being joined ... not to mention the foreign/primary
> key constraints, right?
Absolutely. Date is right to insist that the data model be strongly-typed
(albeit dynamically so). We (er.. I ) already use RelaxNG and the XML
Schemas Datataypes for dynamically defining domains in our DBMS, over and
above for the "typing" of XML elements. I think there is great potential
there for a unified typed data model embracing both relations (RDBMS) and
trees (XML). Whether this data model could be usefully deployed generically
within REST is what I am trying to explore here.
> - I do think that the "use RDBMS theory and best practice" could indeed
> apply to metadata management more than current practice indicates.
> I can't sit through an RDF presentation without thinking very similar
> thoughts to those that Gary Stephenson posted ..."Hmmm, this sounds
> a lot like the stuff that Date rails against ... mightn't these folks
> learn a lot from studying the relational model and improving on its
> limitations rather than inventing network databases over again?"
Yes - except that I think it may be that Relational - vs - Hierarchical -
vs - Network models might be in some ways a distraction from the underlying
simpler notion of DBMS as a method of imposing _some_ sort of disciplined
"data model" and "management system" over the underlying resources/data.
> The best "here's why not" answer I've gotten to this (I remember it
> was from Michael Kay) is that RDF itself is normalizeable into relational
> form but SQL can't practically handle the recursive queries it would
> take to answer any interesting questions about the knowledge the
> RDF represents. Date, not surprisingly, implies that this is
> a limitation of SQL, not the relational model, and that the way
> forward lies in actually implementing a relational database as
> Codd defined it.
yup! Except that he'd actually like us to implement a relational database
the way _Date_ defined it! <g> This has always been my big problem with the
Third Manifesto stuff, as also with RDBMS systems in general. It would
seem that they are in fact impossible to implement! If not, then why hasn't
anyone - including Date and Fabian Pascal - yet done so?
cheers,
gary
|
