This is the right approach, when I worked in the SGML world with a component versioning system, we called it the "non-linear" design.
By going down this road, your table schema is static and can cope with any type of DTD without change. However, you need to create a tool that will convert your XML document into a list of rows by mapping elements in the DTD - you do this by allowing the user to define what level of "componentisation" they want to achieve in the database i.e. the tags that will be stored in database rows. You could componentise everything (including <b>, <i> for HTML etc) but this could produce thousands of rows for even quite a small document. Maybe your XML docs are relatively clean and therefore don't have too many layers, this would allow you to do the lot. The next thing your tool needs to do, is to determine the parent-child relationships between all the rows and express this using primary key linking columns. At this stage, you could also think about versioning - our aim was to create a database that would allow editors to modify a particular component by creating a copy of the row in the database, linked to the same parents and children, but with a different version number. This means that he could choose to print the document with certain revisions or at a certain version number. The tool also obviously needs to enable you to run queries that produce "document" results, not just tag results, which would be easy. As you can imagine, rebuilding the relationships isn't a simple query - lots of self correlation etc. I was working on this SGML stuff in 1994, way before XML came along and the tools we had to work with were primitive by modern standards (Avalanche, Omnimark etc) - equally, when we worked with a document that was moderately large, it required lots of database horsepower to make it all work. However, the holy grail of being able to create a true SGML/XML repository that allows multi-user, concurrent, component level editing/versioning was just within reach, if we could just get a Cray (whatever happened to them?) to run it on! Just in case you're wondering about possible applications for this, think of people like Boeing and Airbus and how they manage and control the editing of their sets of flight manuals etc. Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of A. Pagaltzis Sent: 05 May 2006 06:14 To: sqlite-users@sqlite.org Subject: [RBL] Re: [sqlite] XML to SQLite upload Hi Vivek, * Rajan, Vivek K <[EMAIL PROTECTED]> [2006-05-05 06:40]: > Sorry, I was not clear in my previous email. I do know the > structure of the for the XML - I was wondering if there was a > direct upload capability, once I know the structure of the XML. well, you can map generic XML to a relational database by storing each syntactical element of the file in a row of a table, together with information about how the elements are nested. (Various ways to represent trees in a relational database exist.) However, what you get is nearly useless for the kind of querying that you typically want to do with a database. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
