I've actually been dealing with quite a few of these issues over the last year or so, so here are some of the answers we've come up with (albeit good or bad).
-----Original Message----- From: tonyl/pillarsoftware [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 8:00 AM To: 'Jonathan Peterson'; [EMAIL PROTECTED] Subject: RE: [cms-list] managing metadata; Perfomance >Would you store XML as BLOBs in a RDBMS? Pros/cons? I've actually recently been starting to store XML files as BLOBS within Oracle. This seems to work really well, except for the case that its essentially a royal pain in order to do any searches into the internals of the XML document. Some RDBMSs, notably Oracle (9i), now have blob-like columns that are essentially XML Document columns that allow you to do more granular searches into the internals of the document tree from within your SQL. We've been doing some testing with this, and it seems to work fairly well, if you in fact have any need to do on the fly searching of these documents. >Would you store XSLTs as BLOBs in a RDBMS? Pros/cons? I've tried both storing XSLTs within BLOBS and storing them on the filesystem. On the whole, I've had a better experience keeping them on the FS. This has allowed for greater maintainability and ease of updating. However, I can certainly see some cases where having them in the DB would be useful, especially if you want to give the user the capability of entering new stylesheets on the fly, etc. >I think XSLTS should be stored on disk...but XML data can be stored in many ways...Mapped, as BLOBS, etc. >Have you ever generated XSLTs from a scripts BEFORE they are used to transform? In a past life I've worked on some software that was actually generating XSLTs from within a java template. While this seemed necessary at the time for the product at hand, it was certainly never a very elegant solution :-) > Have you ever tried using multiple XSLTs to generate just one output >page or pages. I am considering using a different XSLT process to >transform each "region" of a page. Any thoughts? I generate a bunch of pages through a series of XSL Transformations. As in, a XML Document may pass through 2-3 different XSL sheets prior to being in the final format. This is actually a really useful thing to do, especially if you can reuse a number of these middle stylesheets for a variety of cases (as in, we have one stylesheet that converts from our ml to newsml, and it is often the last rendition). On an uglier note, I've also generated a bunch of components with XSLT that later get included with another templating system. >Thanks, >Tony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jonathan Peterson Sent: Thursday, February 06, 2003 6:47 AM To: [EMAIL PROTECTED] Subject: Re: [cms-list] managing metadata > 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". I agree, but I'd like to hear of such a database. SQL is good for storing some kinds of information. XML is good for storing other kinds. I've never had a huge problem with mixing these things. I often hear that databases are 'bad' because a change to the taxonomy requires much work re-writing SQL queries, whilst in XML, a change merely requires updating a schema. I can't say agree. All data processing makes assumptions about the data. It matters little whether you are re-writing your SQL phrasebook or the XSLT sheets, either way you are re-writing. My final thought is that much information doesn't fit into either XML or relational systems, simply because it does not fit into a rigid taxonomy. People tend to forget this when building CMS systems. XML may make it easier for computer programs to talk to each other, but that doesn't necessarily make it easier for humans to talk to each other, which is the ultimate goal of CMS systems... -- Jonathan Peterson Technical Manager, Unified Ltd, +44 (0)20 7383 6092 [EMAIL PROTECTED] -- http://cms-list.org/ more signal, less noise. -- http://cms-list.org/ more signal, less noise. ============================================================================ == "MLB Mail Domain" made the following annotations on 02/06/03 08:27:41 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---- [INFO] -- Virus Manager: No Viruses were detected in this message. ============================================================================ == ============================================================================== "MLB Mail Domain" made the following annotations on 02/06/03 10:18:27 ------------------------------------------------------------------------------------------------------------------------------------------------------------ [INFO] -- Virus Manager: No Viruses were detected in this message. ============================================================================== -- http://cms-list.org/ more signal, less noise.
