On Mon, 30 Aug 2010, markspace wrote:
On 8/29/2010 2:06 PM, Tom Anderson wrote:
On Sun, 29 Aug 2010, markspace wrote:
Most data in a database is relational and therefore can be thought of
as forming tree structures.
I tend to think of relational and hierarchical structures as being
rather different. Are you saying this from the point of view that a
table is trivially a hierarchy, the whole being split into rows which
are then split into fields, or something else?
Something else. Let's see if my idea holds up:
Suppose we have data like those you mentioned, customers and products.
You have a list of customers:
Cust1
Cust2
Cust3
Each customer has presumably some purchases:
Cust1 --+-- Invoice1A
+-- Invoice1B
+-- Invoice1C
Each invoice lists various products that were sold:
Cust1 --+-- Invoice1A
+----- Product_a
+-- Invoice1B
+----- Product_b
+----- Product_c
+-- Invoice1C
+----- Product_a
+----- Product_x
That to me is a tree.
It's a tree to me too. You could draw something very similar for
category/product/SKU as well; it might turn into a DAG if you allow
products to be in multiple categories, but it's broadly treelike.
If SQL forces a tabular format, that's just an artifact of SQL; the
fact that SQL would retrieve this data as a table is immaterial. It
doesn't change the fact that the data itself is a tree.
No, the tree is a way of looking at the data, just as a table is. One
might feel one or the other was more natural, or find one or the other
more practical, but they're ultimately just views. I'm not saying you're
wrong about XML being a good fit for this kind of data - if it is
aesthetically or practically beneficial to treat it as a tree, then XML
is a better choice than CSV - just about this being an essential feature
of the data.