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."
Not "peak". Sheesh!
From an intro on stored procedures:
"What is a Stored Procedure?
If a procedure is encapsulated logic that can be invoked from within your application, then a stored procedure is simply a procedure that is stored on the database server. Usually written in SQL, the stored procedure benefits from the power and proximity of the database from which it is managed."
-mkb
Oracle's had this for years. Since v 8, I think? (corrections welcome)
;-)
Glad to oblige
Oracle basically chucks it's XML into a LOB, and you can search the lob for strings, etc.
What IBM has actually breaks down the XML, creating a tree structure behind the scenes. There may be no out-and-out benefits at the moment, but the solution is a much better implementation than Oracle. The applications will come.
Visit here and have a look at the paper "An Overview of Native XML Support in DB2". Also maybe see "Learn how IBMs new XML technology differs from other XML storage", which is a link to a Register article.
Note to ACs: I won't mod you up, even if you are being funny or insightful. So take a chance! It's not real life!
Back when IBM bought Lotus, Notes was a very unique platform for document databases. I wonder if they've taken the old Notes document database concept and exapanded it to XML. IBM owns so much esoteric intellectual property; you would hope they could find some interesting overlaps.
As IBM indicates in their press release, they're making sure it integrates with PHP as well.
BTW, the register has some good coverage on the new XML integration.
There is a "Standard" (I know this is a dirty word to some) that commonises SQL over a number of platforms.
/.) SQL for use in some other products and called it Extended SQL (Websphere Message Broker). In this incarnation it is a programming language. It does follow SQL92 when accessing databases though. These databases can be Oracle, DB2, SQL/Server or Sybase.
Do a google for SQL92.
DB2 SQL is not a copy of Oracle SQL. There are lots of other database software that is complaint to a standard such as SQL92.
IBM has extended (another bad word on
I'd rather be riding my '63 Triumph T120.
The strange thing about this development is that the navigation model used by XML is essentially :-)
the old "network" model used by among other CODASYL in the early seventies. This model
became unfashionable when the relational model gained popularity, but seems to be quite fashionable
when it is wrapped in XML syntax
We develop documentation (manual, onlinehelp, etc.) and develop our content modular in XML, and publish it to different output formats (PDF, HTML, CHM, etc). In this case XML is an excellent format for storing content.
Ops, of course I should have been more clear. What I meant is that I don't think XML is meant (IMHO) to be used to store MASSIVE amounts of the kind of data you USUALLY store on a DB.
While it can be extremely useful to use XML to represent the data you just extracted from the DB (or the data you are about to insert), saying "we store data as XML natively" sounds to me just a silly marketing campaign.
This leads me to believe that you dont understand what modern database technology is all about. The theory is that the database manages the physical data stores and how to retrieve data from the stores, and the application program using the data stores worries about what data it needs. Now, are RDBMS's faster than you directly accessing a flat file whose structure your program knows about? Absolutely not. Yet its a stupid idea in this day and age to architect an application with flat files instead of an RDBMS as a datastore. The benefits in terms of application development time and maintainability are so huge that the slowness that RDBMS's add on are almost always discounted.
Non-XML physical datastores are typically physically non-structured, though the database may impose a logical structure by using indexes and writing out records to the physical files in a specific order. So you can have structured data organization like btrees that your database knows about but which your program doesnt know or care about.
An XML file is explicitly structured. Yes, parsing an XML file may take longer than parsing a "flat" file, but on the other hand, an intelligent database may be able to optimize away the overhead of structuring the data by moving records within the file around that is needed for flat files. Further more, the great advantage of XML is that it is a standards based human readable format. It opens up whole new worlds. Will native XML storage be slower than flat file storage? Maybe. Even so, it is still an improvement over what was there before.
And you should also read up on XQuery. I dont know if "Viper" supports it (unlikely, since the standard is now at W3C candidate recommendation status still), but thats where the wind is blowing with XML data stores. XQuery is SQL for XML structured data. With XQuery support, you should in theory be able to take all XML physical data files that Oracle has and copy it over to DB2 and still make your XQuery based program work without changes because the physical data store has a standard structure (XML) and the query language is also a standard. Dumb idea? Far from it.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
XML is neither a means of storing data, nor a means of communicating data, but is only a means of *marking up* data.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
> Now, Sql Server 2005 and Oracle have excellent Xml support right now, not next year. Which means IBM, you are late.
That's incorrect - DB2 has supported XML for probably two years now. What they're rolling out is a database engine that has much improved support for XML. Prior to Viper the existing database engine would convert the xml to/from tabular format within the database.
Now, what's the value? Well, this should allow more functionality and flexibility for XML queries, and should also allow for queries against XML data to also include non-XML data.
> It still sucks for real time applications. DB2 is a good warehouse DB, good for batch processes and such.
The differences between oracle & db2 for transactional apps are mostly:
- db2 is about 1/3rd the cost of oracle
- db2 is faster
- db2 includes some warehousing features (range-partitioning via MDC) for free which are often also useful in these applications
- db2 is simpler to administer
- oracle has a locking interface that's easier to use (MVC instead of row-locks)
- db2 likes to use static sql that requires binds (pita, but optional)
> I must admit those IBM guys know how to butter the sales to the management with all those golf subscriptions,
> hockey tickets what have you.
Hmmm, i've worked with sales staff from quite a few different companies. But I've never worked with people as nasty as at oracle. They go *way* beyond mere buttering up of management all the way to stabbing the technical staff in the back when the want their professional services team to get their work, or when the oracle product fails to deliver the labor savings that sales promised. Oh, and then there's the famous oracle trick of leaving vital pieces of the product out of the discounted original deal, and slaying the customer when they discover that these are required...
> Both now have native XML support with XQuery, both do stored procedures
.NET and that db2 does
> although SQL Server has for some time.
So has DB2 - though SQL Server stored procedures (inherited from Sybase) are the easiest to work with in the industry. And have almost no exception handling, though perhaps (I doubt) they've improved this in 2005.
> What's interesting is that db2 can have the Zend core bolted on as the equivalent of
> very nice document store handling but that's always been a selling point for a while now. I really like the notion
> of using it for a document store.
DB2 is very focused on this, with entire sets of add-on products for content management. Never used them, no idea how good they are or how expensive though.
> 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!
Note that db2 will now have two database engines: the xml engine, and the relational engine. Both are getting upgraded in Viper. The relational engine is picking up:
- Oracle-style partitioning (to add to its own three other types)
- Label-based access controls (to handle more complex security requirements)
- adaptive self-tuning memory (to automatically configure itself)
I've got no idea how they plan to price the XML engine within Viper. But I'm asuming that the existing database engine will be priced similarly to how it is priced today.
For example, the top-end db2 product costs $32k/CPU, with some potential add-ones if you want spatial analysis or whatever. Oracle is $50k/CPU and the add-ons tend to be much more critical ($10k/CPU for partitioning, etc). SQL Server's top end product is now $25k/CPU. These are all list prices - and subject to huge discounts.
But of the three DB2 includes a lot more in their base product - so you can actually use the lowest-end products at about $1000/*server* and still get a partitioning solution that can handle a terabyte data warehouse. Or $7.5k/CPU and out-perform the SQL Server database at $25k/CPU on warehousing & reporting apps.
SQL Server is getting a lot of press on their analysis services and new reporting services features. DB2 partners with essbase for olap engine equiv to analysis services. I think this would also be an equiv to reporting services, but I haven't yet seen a good detailed description of exactly what that is. It looks like little more than crystal reports or brio from what I've seen so far. If that's the case then there's little there of real value. Still, it's obvious that db2 & oracle both need to shore up this area of functionality.
You can store XML according to a schema, and index it using B*Trees, or you can store it as a LOB and index it with function-based indexes or text indexes. There are tradeoffs to either. Here's a document explaining Oracle's implementation, though you need to sign up to OTN (free reg)
/ appdev.101/b10790/xdb01int.htm#sthref46
http://download-west.oracle.com/docs/cd/B14117_01
-Stu