[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: 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@S...] Sent: Tuesday, October 30, 2001 11:55 AM To: xml-dev@l... Subject: RE: XML Database Decision Tree? > -----Original Message----- > From: Magick, Brian [mailto:Brian.Magick@C...] > Sent: Tuesday, October 30, 2001 10:52 AM > To: xml-dev@l... > Subject: RE: 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>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|