Datasheet

</world>
...
</populationInThousands>
From a purely programming perspective, it could be stated that attributes should not be used because of
the following reasons:
Elements help to define structure and attributes do not.
Attributes are not allowed to have multiple values whereas elements can.
Programming is more complex using attributes.
Attributes are more difficult to alter in XML documents at a later stage.
As already stated, the preceding reasons are all sensible from a purely programming perspective. From a
database perspective, and XML in databases, the preceding points need some refinement and perhaps
even some contradiction:
Elements define structure and attributes do not. I prefer not to put too much structure into
data, particularly in a database environment because the overall architecture of data can become
too complex to manage and maintain, both for administrators and the database software engine.
Performance can become completely disastrous if a database gets large because there is simply
too much structure to deal with.
Attributes are not allowed multiple values. If attributes need to have multiple values then
those attributes should probably become child elements anyway. This book is after all about
XML databases (and XML in databases). Therefore it makes sense to say that an attribute with
multiple values is effectively a one-to-many relationship.
You send many invoices to your customers. There is a one-to-many relationship between each customer
and all of their respective invoices. A one-to-many relationship is also known as a master-detail rela-
tionship. In this case the customer is the master, and the invoices are the detail structural element. The
many sides of this relationship are also known as a collection, or even an array, in object methodology
parlance.
Attributes make programming more complex. Programming is more complex when accessing
attributes because code has to select specific values. Converting attributes to multiple contained
elements allows programming to scan through array or collection structures. Once again, per-
formance should always be considered as a factor. Scrolling through a multitude of elements
contained within an array or collection is much less efficient than searching for exact attributes,
which are within exact elements. It is much faster to find a single piece of data, rather than
searching through lots of elements, when you do not even know if the element exists or not.
An XML document can contain an element, which can be empty, or the element can simply
not exist at all. From a database performance perspective, avoiding use of attributes in favor of
contained, unreferenced collections (which are what a multitude of same named elements is)/is
suicidal for your applications if your database gets even to a reasonable size. It will just be too
slow.
21
What Is XML?
04_791202 ch01.qxp 10/6/06 10:59 AM Page 21