Foreign keys with BDB XML?

Explore Related Content On "Oracle"

• Hot Articles & Questions on "Oracle"
• Foreign Keys on Nested table
• Foreign Keys on elements with maxOccurs > 0
• foreign keys not imported in DB 9i ?
• Foreign Keys involving two different databases/schemas
• Foreign Keys in tbls
• Foreign keys in Oracle
• Foreign keys in Oracle
• Foreign keys cause a redundant ROW SHARE lock?
• foreign keys between 2 tables - newbie question
• Foreign Keys b/w two schema

• Open Articles & Questions on "Oracle"
• Foreign Keys showing in exported Report
• foreign keys in sql loader
• Foreign Keys dependencies
• Foreign Keys / Parent Tables
• Foreign Keys
• Foreign key.
• Foreign Key with Varray
• FOREIGN KEY to XMLDATA
• Foreign key to another schema?
• Foreign Key script

All Comments

Leave a comment...

• 3 Comments
• • 
  • Hi,

    There is no formal foreign key support built directly in Berkeley DB XML. There are discussions on the internet about trying to accomplish this in a Schema to be validated before document insertions. You could write code to achieve the referential integrity type rules. You could also write A Query that could return (the result of a join).

    Can you expand what exactly problem your are trying to solve?

    Ron

    #1; Sun, 24 Feb 2008 01:23:00 GMT
• • 
  • Hi,

    I wanted to know if BDB XML could be used like a normal RDBMS (i.e. mysql).

    I have found notice about foreign keys in Berkeley DB java API and I have serched the equivalent for XML.

    I have read about XML schema and BDB XML here:

    http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/dbxml/ but I've not tried it.

    The operations I'm trying to do are "on delete cascade", "on update cascade" and similar.

    Many thanks

    Andrea

    #2; Sun, 24 Feb 2008 01:24:00 GMT
• • 
  • Andrea,

    I don't know if this may be a solution for your particular case, but consider the following:

    When using a relational database, your tables pretty rigidly define your data. If you follow the path of normalization, you'll start out eliminating horizontal and vertical redundancy, you'll then make data in a table depend only on the primary key, etc. Bottom line: You end up with a lot of tables that are interrelated and you need a set of integrity constraints (like cascading deletes) lest updates to your tables don't produce dangling data - etc.

    When using XML, however, you don't deal with tables, hence there is no need for normalization - all pretty clear. What needs to be split up and spread over various tables in a relational document may well fit in one document. Should you then want to delete that document there is no dangling data left.

    An example: Let's say you have some items - postal addresses - which are dependent on another item - a customer. You're in the relational data domain, and your addresses are in a dedicated table, pointing to a customer vie a foreign key. Now you may want to drop your customer, and you don't want the addresses either. Cascading delete, alright.

    Now, moving your application to the XML data domain, you might want to consider moving the addresses to the customer document, thus integrating dependent data into your main data structure. In the end, the addresses do belong to the customer. In the relational data model, they are only separated from the customer because that's the way the relational model wants you to represent your data.

    Maybe you can remodel your data to reduce, or eliminate, the need for cascading deletes. But maybe not, and then other paths will apply, such as those Ron suggested.

    Michael

    #3; Sun, 24 Feb 2008 01:25:00 GMT