<-wrote in message news:eq******** ******@TK2MSFTN GP02.phx.gbl...
In a relational database, it's not uncommon to name an attribute the same
as the entity when applied to the physical world.
Category, which is an entity, has a similarly-named attrbute.
CATEGORY
CategoryID
Category
This concept, in the XML world, fails, right?
I'm asking for supporting evidence from people who know better than my
cursory experience, which seems to suggest that.
That you attacked my physical implementation doesn't address my question,
nor does it seem to get around the fact that this appears to be a strong
limitation to XML. Unless there's a way around that. If so, I'd like to
know how.
Also, you don't know that I'm responsible to create the database. For all
you know, someone else may have implemented this, and I'm just working
around that. Either way, you have decided to attack me.
MVP? What does that stand for? Most Vile Pinhead?
(No offense intended to other MVPs who go out of their way to help people.
Guess you're just having a bad day).
You asked me what you had gotten "wrong", so I put my reply in those terms.
I'm aware that occasionally the entity is named the same as a piece of it -
I've done database work since before relational databases - and I stick to
my contention that two things should have the same name only if they are the
same thing. And the attribute isn't "similarly-named", it is identically
named, suggesting that it is (impossibly) the identical thing.
I _do_ prefer to distinguish between the entity, it's primary key (ID), a
textual equivalent to the primary key (Name) and a textual description. If
the naming were left to me, there would be a Category table, with CategoryID
as its primary key, with CategoryName as a unique field, and with
CategoryDescrip tion as a non-unique, longer text description. This would
make all of the relationships clear, instead of saving four characters in a
column name by omitting "Name".
I responded with such a "philosophi cal" or "stylistic" response because I
believe that your practical problem is related to the stylistic one - in the
same way as the naming of this database would confuse human readers, I
believe that you have confused the software! Both problems would be
alleviated by giving a distinct name to the entity and to each of its
fields.
Now, you've got a very similar problem in your XML. It seems that you want
to have one element named "Category" which is of a complex type containing a
CategoryID and a Category, yet that second Category is meant to be of a
different type that the root "Category". Again, this is the result of giving
the same name to different things, and will only cause trouble. In this
case, you would need to convince software that, although these two elements
have the same name, they are actually unrelated (except for the name). Why,
for instance, should software not expect the following XML:
<Category>
<CategoryID>1 </CategoryID>
<Category>
<CategoryID>2 </Category>
<Category>... .
So, frankly, it's not a problem with the XML world, nor a benefit that the
relational world has - it's just a matter of the fact that the naming
convention you were using (whether or not you are responsible for creating
it) is confusing to both humans and to software. Correcting the naming issue
would solve the problem both for humans and for XML, and would prevent this
from becoming a problem with the next piece of software which assumes that
names mean something.
--
John Saunders [MVP]
P.S. Personally, I would have saved the word "vile" for something a lot
worse than my answer to you, but I suppose that's a matter of taste.
