OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xml-dev] XML Database Decision Tree?




<<I have a gut feeling that the typical
developer can do a decent data model in XML more easily than he/she
could do
a decent normalized RDBMS model, but that's one for the Time Will Tell
file.>>

I do agree that a decent data model in XML is easier than creating a
data model for an RDBMS.  Obviously the relational aspects of an RDBMS
and normalization issues complicate the matter (although it is worth
noting that these are still issues for the XML data model, XML DOES have
capabilities to do identity constraints and key reference, lets not lose
site of that).  I would caution that if your organization like mine is
guided by a set of Data Architecture/Data Management standards,
policies, best practices, and principles that this is still best left to
the data architect.  My experiences have proven time and again that a
data architect armed with the knowledge of the organizations data
architecture goals will do a much better job modeling the data, even in
the simplified world of XML data modeling.  Simply put, the Data
Architect, the application developer, and even the DBA have a different
perspective and set of concerns. (i.e. the data modeler is typically
most concerned with business logic, business rules, standard data
definitions and structure, etc....your developer and DBA generically are
just not as concerned with these issues)

<< Hmmm ... I'd say that "repository" implies persistent storage and
retrieval
by some primary key, some predefined metadata, and maybe brute force
search
("grep").    "DBMS" implies that plus more flexible yet efficient
queries,
transactions, integrity enforcement (whatever that means in XML!),
backup/restore utilities, optimization tools ...  By that definition, a
vanilla WebDAV server is a "repository" whereas the products from the
vendors who have participated in this thread are "DBMS".  That seems
like a
distinction worth making. >>

Agreed.  I thought about this after hitting "send" and wished I could
modify my "repository" statement, although I still think the table
versus XML document or XML node distinction is one that needs to be
understood.  My point (which was not made well) is that you typically
create a data model for the entire RDBMS before you put it in
production.  For XML your data models (Schemas) can adapt to change in a
Native XML database much easier, and your set of data models is most
likely always growing (introduction of new XML and associated Schemas).
Typically the Native XML database does not subscribe to the concept of
one data model to describe the entire database.  Due to this
ever-changing scheme I think the data architect is even more important
now then he/she was in the traditional RDBMS world.  I personally bank
on the need to constantly evolve and create new XML Schemas as a way to
keep adding value and to stay employed.  I believe I read a statement by
Clive Finkelstein saying something to the effect that XML is going to
keep DA's in an ever more important role to the organization.  Whether
this is true or not will probably depend on how well the DA role
embraces XML and the willingness of development teams to invite the DA
to function as an important part of the application development cycle.
This is a paradigm shift.  Typically the DA was engaged to help with the
database creation, now they need to be involved at the
document/application creation level.  The Native XML database can be a
"repository" of these efforts with XML Instance documents (i.e. data)
placed in a database for common indexing, querying, and management.  The
XML database does not need to be the source of this data, it can be the
common "repository" or resting ground of the data for easier management.
(I think that's the best way to get the point I'm being so long winded
getting to).  Embrace this new paradigm shift, engage your Data
Architects, and know that your XML is being architected in a way that
supports the overall goals and principles of your companies data
strategies.

Brian


-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Tuesday, October 30, 2001 11:55 AM
To: xml-dev@lists.xml.org
Subject: RE: [xml-dev] XML Database Decision Tree?



> -----Original Message-----
> From: Magick, Brian [mailto:Brian.Magick@COMPAQ.com]
> Sent: Tuesday, October 30, 2001 10:52 AM
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML Database Decision Tree?
> 


The responses in this thread have clarified/corrected one point for me:
You
can do a "bad" table-based data model (one table with lots columns full
of
mostly null values) of almost anything in Access or whatever as easily
as
you can do a naive XML data model.  I have a gut feeling that the
typical
developer can do a decent data model in XML more easily than he/she
could do
a decent normalized RDBMS model, but that's one for the Time Will Tell
file.

 
> Now this isn't a new struggle.  Data Architecture historically has had
> an uphill battle for acceptance, I won't get into the 
> specifics of that

I'd appreciate some pointers to resources on "Data Architecture" and its
principles as it relates to XML.  It sounds like a discipline that we
need,
e.g. to address the question of when to model hierarchically and when to
model relationally.  

> In terms of the XML database I think the term database might be bit
> misleading (I personally think repository fits better) 

Hmmm ... I'd say that "repository" implies persistent storage and
retrieval
by some primary key, some predefined metadata, and maybe brute force
search
("grep").    "DBMS" implies that plus more flexible yet efficient
queries,
transactions, integrity enforcement (whatever that means in XML!),
backup/restore utilities, optimization tools ...  By that definition, a
vanilla WebDAV server is a "repository" whereas the products from the
vendors who have participated in this thread are "DBMS".  That seems
like a
distinction worth making.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>