Charley wrote: >The ever-present "Databases V. XML: Battle To The >Death" comes from the fact that (relational) >databases are *highly* structured, and XML offers >more degrees of freedom from *highly* to *partially* structured.
>From experience the degree of freedom that XML gives within the scope information modeling is largely cosmetic (data in class 1, please read my pervious mail). That is, if data is highly structured (like most metadata is) somewhere you have to play the pipe of structuring information into a coherent schema with minimal redundancy (playing with ID's in XML?) otherwise managing transactional updates to metadata will be a nightmare. IMO the Entity Relationship modeling an RDBMS offer way better artifacts to manage this specific need (When needed data can be exported easily in XML). There are a lot of benefits not related with structuring information in XML: * Offers a better way to store and structure information in files. * Offers a better way to structure messages between systems (SOAP). * Offers a better way to structure information to be shared by multiple systems (DocBook Schema, Dublin Core, etc etc). This pretty much covers the most important benefits of XML IMO. Nothing of this is related with modeling a candidate to a fully structured model like most metadata "objects" are. Mattias wrote: >This method would allow you to create a "dynamic database" inside of sql >server. Luckily I already developed this part for handling user prefences >when I realized that i couldnt fix them to a certain set of attributes but >would have to make a easy way for administrators to customize preferences. >I developed a system with "Entities" stored in the database, each entity >has a certain entity type, each entitytype has a certain number of >atttributetypes associated with it, these attributetypes can be integers >strings etc and also sets of values like Skills[C#,C++,Java] or a single >value from a valuelist like Country[Sweden] This is interesting in the sense that it maps with our architectural vision too (see previous post). An entity type in our system is called Content Template. The notion of Content Template (entity type) is used to do all sorts of things, not only to provide a easy way to administrators to customize preferences. In our system a Content Template is used to set the policy for creation of content with similar structure across the organization. A Content Template describes content of identical structure. It does this by defining content in terms of the kind of associations, the kind of basic content properties (your attribute types), the kind of content schema (Docbook for instance) and the kind of substructures that it's structure should or is required to have. Associations, properties, content schema and substructures are said to be the metadata of a peace of content. Users will build content templates with a visual editor (Content Model Editor). A Content Template is stored in the relational database in straight XML (We use an annotated XSD schema to format the XML). The Content Template only defines structure, it does not define how content will be stored. A second process related with this is allocating storage in the database to hold content compliant with the content template. This process automatically creates tables in the database (on user request) following the practices stated in my previous post, not only does that but also dynamically creates insert, update and select SQL procedures. Best regards, Nuno Lopes. PS: Hopefully all this will be provided Open Source within 6 months. -- http://cms-list.org/ more signal, less noise.
