NYCPHP Meetup

[Tim Gales]

Brian D. wrote:
> Tim, I don't think I was clear.
> 
> We're differing on semantics here, but by "structure" I mean set
> fields, e.g., an "employees" table would have:
> 
> first name
> last name
> hired date
> etc.
I would argue that you should use the term 'attribute' and not
fields. An relational attribute is generally accepted to be an ordered
tuple like [ 'first name', 'varchar 20' ].
Now one of the key concepts of the relational model is that
a table(relation) is an *unordered* collection of attributes --
that is there is no need for a given attribute to be
conceptually next to another.

Different 'relational' database management systems get this
right to different degrees.

But when it comes time to exchange data from one table in a
database to another database -- even within the the same DBMS --
all bets about the "not-needing-to-be-next-to-another-attribute-ness"
are off. (e.g. as in a comma separated file)

> 
> An XML document doesn't have a field definition (unless you tell it
> to, of course, using any of the methods you described).
> 
No.
Valid XML documents must adhere to their DTD/Schema and to that
degree they have fields -- called 'elements'.
like
<customer>
   <first_name>Alfred</first_name>
   <last_name>Wilson</last_name>
   ...
</customer>

Of course you can get fancier and use 'XML attributes' like
<first_name nickname="Freddy">Alfred</first_name>


> I'm aware that XML has "structure" (in the sense it is well-formed).
> 
> A flat text file paired with grep doesn't have the same power because
> fields would not be defined. XML, at least, conveys information about
> the data contained in the field... 
My point exactly (see above about) XML elements.

But in XML, elements do not have to be ordered because
each element can carry with it its own semantics.
That is to say, each element in XML can carry with it
the same meaning which is conveyed in a relational model
by a 'relational attribute'.
(Of course you can require elements to be ordered in
XML if you want to)

Thus XML frees you from the confines of having to carefully
order your data when you want to exchange it.

Now if during the exchange of XML data it has to
stop on a system and be stored, it certainly makes sense
to put it into an XML database.

Or perhaps you want to avoid hitting and re-hitting some
data store in order to exchange data. There again it
would be a good idea to select a large amount of
data and put it in an XML database and parcel it
out later.

Now I am not suggesting that the value of XML is
confined to solely to exchanging data (though it
might be possible to defend such a position) --
I'm just trying to describe the difference between
XML 'structuring' and relational 'structuring' -- and to
highlight (at least one case) when XML can be the
superior choice.

But I stick by what I said earlier that XML documents
(and hence XML Databases) are not inherently
less structured or more capable of handling unstructured
data than a relational data model.


-- 

T. Gales & Associates
'Helping People Connect with Technology'

http://www.tgaconnect.com