> > I would submit that neither SQL nor XML are really the best data model > > for CMS metadata. If you are limited to these two, I would go with XML > > and rely on the capabilities of a decent XML database that allows you to > > treat the XML interchangeably as either deep or shallow and provides a > > decent query interface, i.e. not "in-memory".
Well if it were that easy, the problem is that sql server 2000 is the cornerstone of the system, branching out and including a XML database would pose several issues. An serious issue when using XML in the database is that database queries including them become so much more difficult, say that you want to return the 20 most recent documents and the data is contained in a XML field in sql server, then you'd have to parse it out using OPENXML or something, very inefficient. Another problem I see is usermanaged metadata versus database managed metadata, should one separata the too. Things like last updated, created, author etc should probably be integrated into the system and it's business rules, do you store this separately in a pure table or if you store metadata as XML try and make a scheme where the system can update the relevant xml elements itself when needed? Hhere's the pros and cons of relational vs xml in the database as I see it: [Relational Method.] 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 could be used for metadata, simply defining a entitytype for each documenttype containing relevant attributes such as for example author, datecreated etc etc. PROS -------- * Better Performance * Easier to write databasequeries containing metadata CONS ---------- * Restrictions upon the structure of the metadata, shallow structure only [XML Method] This would store metadata simply as XML within a field in the database and then you could define for each document schema a correspondent metadataschema. You could then aggregate a xml document containing all metadata and use it to make powerful Xpath querys PROS ---------- * Very flexible * immensly powerful XPath queries possible CONS ------------ * Bad performance, how do you load an big aggregated metadata document into memory without a performance hit, chopping it up into several files and iterating through them also probably is slow *Very difficult to make database queries containing metadata attributes It's a difficult dilemma, probably arising from the fact that Sql server clashes a bit conceptually with storing XML but integrating a XML database doesn't seem like a solution since it'll increase architectual overhead a lot . <signature> <email>[EMAIL PROTECTED]</email> <mobile country="+46" area="709" number="284262"/> <company>Existic</company> </signature> -- http://cms-list.org/ more signal, less noise.
