[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
[[
As Uche aptly pointed out, people with a programming background
typically have a notion of types is derived from how they are treated in
programming languages and other aspects of Computer Science, not from
freshman philosophy classes.
]]
Perhaps an analogy to SQL will be more understandable.
Consider an SQL table as a class. Each column is a property of the class.
Constraints are also properties of the class. Each row is an instance of the
class.
A "SELECT" statement defines a sub class of the table class whose members
are returned by the statement etc. One can get a bit more complicated
considering joins etc, but this is naturally modeled by composing the tables
and views involved in the join.
I am sure there are nice tools that allow SQL statements to be modelled in a
graph format.
What I am saying is that _how_ the database keeps its integrity is not
usually a concern of the DB programmer, rather the programmer specifies the
constraints and expects the system to do the right thing. Consider the
constraints and the table structure (i.e. the DDL) to be the 'type system'.
Consider the database engine to be the validator.
Fundamentally I don't think XML is any different, which of course is why one
can store XML in a relational database and why, I presume, one can implement
XQuery on top of a relational database. I am purposefully trying to make
this simple. The details are in the implementation as always.
Really, I am just trying to suggest that this is a straightforward and
natural, particularly for the SQL DB person, way to model things.
Jonathan
|
