Slashdot Mirror
Sneak Peek at IBM 'Viper' DB2 Release
Rob let us know that Computer Business Review magazine is reporting that IBM is about to add more fuel to the database fire. The company has offered up a sneak peek at their upcoming "Viper" release of their DB2 database. From the article: "DB2 Viper will be distinct from current DB2 database implementations in that it will be able to store XML formatted data inside the database natively--XML support will not be bolted onto the side. Viper will also support relational data stores, of course, and access to those database tables using the SQL programming language."
I wonder what the price point for Viper is going to be in comparison. I already know what it is for the various versions of SQL Server 2005. Ouch! I'm waiting for my Enterprise and Developer versions to show up now so I can play more (I've been playing with the betas for a long time now as I do DBE work as well).
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
So it's not the storage that counts, it is the ability to extract useful information from the text field/clob without requiring a great amount of processing overhead. Which is where I wonder how useful this is except in situations where there is very little post-processing or querying to be done against the XML. For example, if I am always just going to render the XML or pass it along without any post-processing. Even then, in terms of processor time, etc. it just isn't that hard to write good code to pull the data from a regular SQL database, output it as XML, etc. thus gaining gain all of the other advantages that a modern dbms has over flat file storage without imposing the dreadful data overhead required for all of the xml tags, etc.
Am I missing something?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
For those wondering about the difference: a good rule of thumb is that a programming language has recursion, or at least loops. SQL is less powerful than a full programming langauge because there are many things you can test in a program that you can't write an SQL query for. For example, if you have a table of (person, parent) relationships, you can't write a query to list all ancestors of a given person in form (person, ancestor). But you could easily do that given the same data and a general purpose programming language.
(Actually I think the very latest SQL standard may have some support for recursion to handle queries like this one. I don't know if it is Turing-complete though; I suspect not.)
Does this mean SQL is bad? No. Partly because it is less powerful than a full programming language, the database can often work out roughly what a given query will need to access and so make an efficient query plan for it. If what you want is expressible as SQL, it's very often a lot faster than coding the same thing in a general-purpose language, and easier to write and understand.
-- Ed Avis ed@membled.com
I think that all the folk saying that "XML is bad for databases" are dismissing it far to quickly. Let us think about the general case of "marked up" data being included in a database.
First, is there a difference between doing this in a relational database versus another kind (say object DB). Perhaps so, but I wish to focus on RDBMS since it is the one that is on topic here and the one that seems so counterintuitve.
Marked up data (XML, HTML, perhaps even SGML) consists of field values _and_ the schema of the fields themselves (even if not always the base data type). Whilst it may be necessary to have the grammar to be certain about the full domain of the *ML there is enough in the marked up data to construct a record from the input data. Think about it, this means that each record arriving at the database contains some information about the schema of the record as well as the data itself.
A database that took this *ML and integrated it natively would, in my world allow the user to create tables with an indeterminate number of fields that could vary from record to record whilst still allowing normal RDBMS functionality.
The complexity of such an implementation would be high, particularly within the context of a database that still has good indexing, table management and performance. Foreign keys would be an intriguing challenge. There is nothing about the problem that is inherently unsolvable but performance would be a real challenge.
I don't think that this functionality is a category killer. But I can imagine why some people love the idea. Lots of people would like to be able to define records in their RDBMS that have arbitrary fields that the designer of the schema did not know about when the database was built. SQL does not cope with this scenario at all. However in my view correct normalisation solves most of these issues and makes the need for native XML unnecessary. Perhaps it would have been easier for IBM to ship DB2 with a copy of McGovern and Date.
"The first thing to do when you find yourself in a hole is stop digging."
Most database vendors have extended SQL so that it is a full procedural language. Oracle has PL/SQL. MS and Sybase have TSQL. Postgres has plpgsql.
-mkb
Oracle basically chucks it's XML into a LOB
How *else* do you store a value from a type in a database?
How does Oracle store integers? "Uhh, that's different" I hear you mumble. No, it's not. An XML document and the associated tree representation is a *value*, an instance of an *XML data type*, with associated operators (xpath, text search, update, etc). So it goes into an attribute (column).
Go back and review your relational theory (that advice applies to 99.99% of users and vendors unfortunately).
If Oracle's marketing has convinced you of something different, then that's their marketing department's fault. The exact implementation (how the XML tree is stored) and syntax (how you query it) is irrelevant. The relational model, and classical type theory (which predates the RM) already tells you how to think logically and abstractly about any data storage and manipulation task, without regard to the peculiarity of any particular product.
For a more concrete example, not using the syntax of any particular product:
Of course, this needs a cup and a half of syntactic sugar to make it more pleasant when using XML-heavy applications (for instance, XPath could be embedded a little more gracefully), but surely you can see that all XML databases can reduce to the same model. Those that are created with ignorance of the relational model won't be as useful.
A well-designed relational database would already be an XML (hierarchic) database, and would already be an object (network) database, because those are both less general than the RM (entities related by arbitrary assertions).
One problem with today's SQL products (and they have MANY) is that you can't create your own types easily. You should be able to add XML support, object support, or whatever else, as easily as you can with a general-purpose programming language. You shouldn't have to wait for the vendor to "add" it.
Imagine if you had to *wait for a new release* to get XML support in Java or Perl. Yeesh. Yet database users seem perfectly content to suck down the crap from the vendors. They don't know what to ask for or how to evaluate what they get. Even though this was mostly figured out 30 years ago.