Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
IBM Databases Programming Software IT

Sneak Peek at IBM 'Viper' DB2 Release 181

Posted by ScuttleMonkey from the taking-the-gloves-off dept.
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."
This discussion has been archived. No new comments can be posted.

Sneak Peek at IBM 'Viper' DB2 Release More

Sneak Peek at IBM 'Viper' DB2 Release

Comments Filter:

  • "the SQL programming language" (Score:5, Funny)

    by jeroenb ( 125404 ) on Wednesday November 23, 2005 @08:40AM (#14099337) Homepage
    the SQL programming language
    It's a query language. Ffs, the name even says so.

    Although, on second thought, the name also says it's structured.

    • Re:"the SQL programming language" (Score:5, Funny)

      by n0dalus ( 807994 ) on Wednesday November 23, 2005 @08:48AM (#14099359) Journal
      It's a query language.

      Yeah. The SQL query language.
    • From an intro on stored procedures [devx.com]:

      "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."
    • Maybe this is a typo for "SQL procedural language", which is DB2's version of Oracle's PL/SQL.
      • There is a "Standard" (I know this is a dirty word to some) that commonises SQL over a number of platforms.

        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 /.) 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
        • I didn't say that "DB2 SQL" is a copy of Oracle SQL. As an Oracle DBA moving into the DB2 field, I know only too well that the two implementations differ significantly.

          I said that maybe the OP meant "SQL Procedural Language" instead of "SQL Programming Language", and then pointed out (to those who didn't know) that DB2 SQL/PL is "like Oracle's PL/SQL"

          Oracle PL/SQL : A procedural language extension to Oracle SQL.
          DB2 SQL/PL : A procedural language extension to DB2 SQL.

          See why I might have said one was like th

    • Re:"the SQL programming language" (Score:5, Interesting)

      by Ed Avis ( 5917 ) <ed@membled.com> on Wednesday November 23, 2005 @10:11AM (#14099842) Homepage
      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.
      • 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.
      • Actually DB2 has had recursion for a while.

        And SQL procedures can do pretty much anything, including maintaining local parameters, calling external programs, accepting parameters and returning results.

        The fact that SQL has set operations like union and intersection is an added benefit, not a downside.

    • It is the stuctured query language programming language query language.

      I just wait for the prequel.

  • Sneak PEEK (Score:4, Informative)

    by Sexy Bern ( 596779 ) on Wednesday November 23, 2005 @08:41AM (#14099343)
    Not "peak". Sheesh!
  • I've had a look at the whitepaper. I think it's a fantastic idea, and Oracle will be gnashing their teeth and fuming. This is way beyond what Oracle do for XML.
    • Oracle's had this for years. Since v 8, I think? (corrections welcome)

      • Re:Oracle (Score:5, Informative)

        by bLanark ( 123342 ) * on Wednesday November 23, 2005 @09:14AM (#14099439)
        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 [ibm.com] 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.

        • Re:Oracle (Score:5, Informative)

          by bj_rmz ( 601513 ) on Wednesday November 23, 2005 @09:31AM (#14099522)
          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 :-)

        • Re:Oracle (Score:4, Insightful)

          by stephenbooth ( 172227 ) on Wednesday November 23, 2005 @09:44AM (#14099623) Homepage Journal

          Oracle has stored XML data in a tree structure and allowed querying via XQuery since version 9.

          Stephen

        • So, basically... we're going back to the bad old days of b-tree+ISAM datasets. They are fast, but they're also a bitch.

          I'm very curious how XQuery+SQL aggregates are going to be handled. As intuitively as SELECT SUM(blahblah) FROM foo?

          My guess would be no.

          Time to crack open the "--- For Dummies" books when they hit the stores. Gonna have to learn how to query data all over again.
          • The entire computer industry is like that... 15 years ago CORBA client-server apps were the big new cool thing. Now client/server is "legacy" and centralized web apps are all the rage.

            To handle all of these web apps, we're even cooking up "new" solutions like virtualization that were in mainframes thirty years ago.
          • we're back to the bad old days of b-tree+ ISAM datasets

            That's basically all any dbms is under the covers, good old b+ trees or even option for older data structures like hashes, and that includes Oracle).

        • Re:Oracle (Score:3, Interesting)

          by Anonymous Coward

          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).

    • The XML support is cool, and definitely will gain traction. If nothing else, think storing (?:.*)Office documents directly in database and searching via XQuery...

      There is a very interesting product in the pipeline:
      http://www.eweek.com/article2/0,1759,1889012,00.as p?kc=EWRSS03119TX1K0000594 [eweek.com]

      If it's not a pricey boondoggle, this Information Virtualization Server could be pretty clever, a sort of auto-Hibernate + web services kind of platform. I'm hopeful that JBoss can respond faily easily to this - at firs

  • Now there is only one thing stopping me using it.... the price.

    Seriously though I would like to see a (native) XML datatype in Postgres that would be a nice little extension.

    Wait, don't tell me it's already got one and I missed it :o)

    • Re:Excellent (Score:2, Insightful)

      by soosterh ( 137200 )

      Actually the pricing [ibm.com] of DB2 is quite resonable -- especially for the express version.

      <flame suit on>

      The other issue is that many companies using products such as MySql have to re-implement features that are standard in other systems. Features such as robust replication, clustering, etc also are just coming on line for MySql and Postgres, but have been part of DB2 and friends for years.

      <flame suit off>

      • Compared to the other big plays those prices are quite good but they are still miles out of the range of what my company can afford. I imagine a lot of other small companies are in a similar boat. I would consider $100 for a stable database that was supported by a big company even if it only had postgres level features. I'm not asing for 24/7 call out but reliable bug fixing if problems occur. I'm sure companies like IBM wouldn't consider playing seriously in the low end market (I know oracle pretend to) b

  • Technology Pot Pie (Score:5, Informative)

    by borkus ( 179118 ) on Wednesday November 23, 2005 @09:19AM (#14099458) Homepage
    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 [ibm.com], they're making sure it integrates with PHP as well.

    BTW, the register has some good coverage on the new XML integration [theregister.co.uk].

    • Re:Technology Pot Pie (Score:3, Insightful)

      by Greyfox ( 87712 )
      Unique isn't the word I'd use to describe anything about Lotus Notes. Sucktastic, maybe... Sure they've managed to kludge Notes to do a few somewhat interesting things, but those things can not offset the underlying sucktasticness of Notes. IBM knows the product sucks too. Every single IBMer that I've ever talked to hates Notes. They hate it from the bottom of their hearts. They hate it in the way they would hate someone who killed their family and kicked their dog. The only reason IBM keeps them around and

      • Re:Technology Pot Pie (Score:3, Informative)

        by FooAtWFU ( 699187 )
        Actually, their next version of Notes (code-name 'Hannover' if I recall correctly) will be more or less completely rewritten using SWT.

        That said, Notes is a pretty ugly email client. But it's more than an ugly email client. It's a distributed database replication application, not entirely unlike, say, Access, except a dead dog is a better database than Access. Notes just-so-happens happens to use one of those databases for email. And there's probably way too much stuff in the other, non-mail databases at IB

        • It's a distributed database replication application, not entirely unlike, say, Access, except a dead dog is a better database than Access.

          The last time I did any work with Notes, it was not a relational database. I assume that is still the case. Access is relational. Also admittedly, I've never used any of the replication features of Access. But, I find Access to be the most underrated, useful, and highest quality Microsoft product ever.

          Don't get me wrong. I am filled with contempt for Outlook and Ex

      • Re:Technology Pot Pie (Score:3, Informative)

        by tigersha ( 151319 )
        Yeah, I am saddled with a Notes atrocity at work (not for long though, they screw with me one more time...) and it truly, utterly sucks. With Notes the development environment sucks. Truly, totally and beyond belief. You cannot even search your own goddamn codebase for a string. THe API is a very much cobbled-together affair where you get the dintinct idea that they put on some arbitrary API call just to make some hot customer happy. Some things have little logic to them.

        The database itself is not that bad,
        • Amen. I'm forced to use Notes at work as well. I hate it. Hate hate hate. In fact, hate isn't a strong enough word for Notes.

          If IBM spent $6 billion on Lotus, you'd think they'd spent a few hundred thousand and actually make it not painful to use. Or, you know, let people sort their email by subject line. Or, perhaps, let people search the *content* of emails and not just the headers. Or, perhaps, let people use the scrollwhell on their mouse in a normal manner. Or decide once and for all whether to
          • I was diggin out an old Notes db recently and discovered a comment I had written at the time:

            "I hate Notes. Real serious, blood dripping from the fangs hatred"

            Sigh.

            Btw, you can search mail databases in Notes, you just have to FTI them and then activate the search abr. That is in the same place in the menu where you activate the Horizontal Scrollbar. God bless them.
            • I don't even know what a FTI is. Or how you "FTI" something. And Lotus Notes' "Help" file, a huge WTF by itself, has no entry for it. But I no longer care anyway; I figured out how to just forward everything to Gmail which actually works.
        • The database itself is not that bad, for what it is supposed to be used. But some people implement relational stuff in Notes (yes boss, I am talking to you), and this is deadly, deadly, deadly. Notes is a document based database that stores documents with random fields, and the fields have no structure. For many things this is OK. For things with connections between documents this is not OK.

          That matches my experience with Lotus Notes back in the late 90s. For what it was designed to do (replication, doc
          • To quote the User Interface Hall of Shame Website:

            We wish we found IBM's Lotus Notes a long time ago. This single application could have formed the basis for the entire site. The interface is so problematic, one might reasonably conclude that the designers had previously visited this site, and misread "Hall of Shame" as "Hall of Fame"

            I cannot say it better. Search for "Lotus Notes Hall Shame" on Google.

            Some things in Notes are very good though. The thingy about the checkmarks you make at the sidebar to sele

  • I am the viper... (Score:5, Funny)

    by pulse2600 ( 625694 ) on Wednesday November 23, 2005 @09:21AM (#14099465)
    I am the vinder viper!!!! I vill be there in three months!!! I come to vipe your vindows!!!

  • Late to the party (Score:4, Insightful)

    by cyberjessy ( 444290 ) <jeswinpk@agilehead.com> on Wednesday November 23, 2005 @09:22AM (#14099470) Homepage
    IBM reckons that the addition of native XML support will expand the $7.8bn relational database market by another $1.4bn. And IBM wants to get the bulk of that additional XML-related revenue for databases.

    Sql support has been on the most wanted list for most companies for quite some time now. With Web Services being used everywhere, and most data formats going XML, representing all those in old-style tabular form and querying them is such a pain. Now, Sql Server 2005 and Oracle have excellent Xml support right now, not next year. Which means IBM, you are late. The deperate switchers are already switching (I know many who did to MSSQL 2005). And many for whom it is desirable have been playing around with it for atleast a year now. By the time Viper is done, they would already be running some database which supports Xml.

    Which not only means that you would get very little of the Xml pie, but also that you will have to work real hard to make sure your existing customers don't move to Oracle or MS, because they want Xml support much earlier.

    • It sure is! (Score:4, Funny)

      by brunes69 ( 86786 ) <`gro.daetsriek' `ta' `todhsals'> on Wednesday November 23, 2005 @09:29AM (#14099503)

      Sql support has been on the most wanted list for most companies for quite some time now.

      Indeed, SQL support is often the first thing I look for when shopping for a database.

    • Re:Late to the party (Score:3, Informative)

      by kpharmer ( 452893 )
      > 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
      • Not to breach the topic, this is about where MS's SQL has bee since the v2000 release... 2005 brings a lot more.. here's hoping sun expands Postgres' support for Java, probably as a competition more direct to MS-SQL 2005, I wonder if/when IBM will add better Java support *inside* of DB2, since they have some heavy Java support as it is.

        The irony to this, is that I never liked Oracle's Oracle as a platform approach, but beign able to have a richer toolset available inside the rdbms would be nice, in a pla

    • AFAIK, DB2 didn't get triggers until v5, which was released in the late 90's. Oracle had triggers probably 15 years ahead of IBM.

      DB2 has been roadkill for Oracle for a long, long time. If Oracle hadn't a) bet on Itanium and b) mouthed off about IBM benchmarking Oracle on POWER in preference to DB2, Oracle would still be the #1 TPC-C performer (and Oracle still beats DB2 on the same hardware, AFIAK).

      DB2 is cheap, but I would never recommend it to a non-IBM shop. You end up on an AS/400 before you know it

  • IBM answers MS (Score:4, Interesting)

    by Decker-Mage ( 782424 ) <brian.bartlett@gmail.com> on Wednesday November 23, 2005 @09:33AM (#14099532)
    So now we know IBM's answer to SQL Server 2005. Both now have native XML support with XQuery, both do stored procedures although SQL Server has for some time. What's interesting is that db2 can have the Zend core bolted on as the equivalent of .NET and that db2 does 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.

    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).


    • Both now have native XML support with XQuery, both do stored procedures although SQL Server has for some time.


      Are you implying that DB2 did not have stored procedures until recently? I don't think that's true.
      • I first used DB2 (on MVS) about 17 years ago and I believe it had stored procedures back then. I started using DB2 UDB on OS/2 and Windows almost a decade ago and I believe they both had stored procedures.

    • Re:IBM answers MS (Score:3, Informative)

      by kpharmer ( 452893 )
      > Both now have native XML support with XQuery, both do stored procedures
      > 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 .NET and that db2 does
      > very nice document store handling but that's always been a sel
      • And have almost no exception handling, though perhaps (I doubt) they've improved this in 2005.

        Actually, 2005 makes huge progress in this requard. FINALLY, T-SQL supports standard TRY...CATCH constructs! A major improvement!
  • for real time applications. DB2 is a good warehouse DB, good for batch processes and such.

    However every time I had to use DB2 for real time applications I wished I could switch to Oracle (but noone gets fired in the banks for buying IBM and 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.)

    When IBM finally adds rollback segment to DB2 then I won't be as upset about DB2 being pushed onto my real time projects.
    • Could you elaborate on that? As someone else pointed out, DB2 does have savepoints which can bring you back to any state. And (granted this is at the JDBC driver level) I haven't seen Oracle support more than two transaction isolation levels whereas DB2 provides all four mentioned in the JDBC spec. And of course one can see how DB2 is escalating row-level locks so queries can be changed to not step on each other.

      I guess my question is: what are you working with such that Oracle does much better than DB2

    • Re:It still sucks (Score:5, Informative)

      by kpharmer ( 452893 ) on Wednesday November 23, 2005 @10:31AM (#14100021)
      > 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...
      • The differences between oracle & db2 for transactional apps are mostly:
        - db2 is about 1/3rd the cost of oracle

        Do they have a free-as-beer freely distributable Express edition like Oracle XE and Microsoft SQL Server Express Edition?

  • Usefulness? (Score:3, Interesting)

    by CodeShark ( 17400 ) <ellsworthpc@[ ]oo.com ['yah' in gap]> on Wednesday November 23, 2005 @09:58AM (#14099731) Homepage
    Not sure, but from where I sit, the ability to store XML natively is one of those "nice but not absolutely necessary" things you can do with a dbms. (database management system), because any of the current RDBMs can store XML chunks in {text fields, memo fields, C-LOBS}, etc. and I have been doing stuff like that since my days as a Clipper/Foxpro/xBase programmer. [aged myself right there, didn't I? :-) ]

    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?

  • SQL support!? Are you sure? (Score:4, Funny)

    by Anonymous Coward on Wednesday November 23, 2005 @10:18AM (#14099904)
    Viper will also support relational data stores, of course, and access to those database tables using the SQL programming language.

    Thank you Captain Obvious! Until I read the headline on slashdot, I was concerned the new DB2 might not support SQL queries. Now I can sleep tonight.

    On a radical tangent, I was thinking of buying a new car. Has anyone heard if the new cars from GM have wheels that turn? I'm not sure because it doesn't say on the website anywhere. I really hope the new cars have wheels that turn. If the wheels didn't turn... that'd be like a database without SQL... or something.

  • MSSQL (Score:2, Insightful)

    by sgent ( 874402 )
    DB2 and Oracle will always be better than SQL Server for one reason -- as of now, they are the only one's who can effectively scale.

    For processor intensive searches, you have the option to throw hardware at the problem, moving up into RISC and mainframe platform's if needed.

  • XML Database, Good or Bad (Score:4, Interesting)

    by awol ( 98751 ) on Wednesday November 23, 2005 @11:12AM (#14100388) Journal
    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.

    • > 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.

      Well, relational databases can handle this situation - you just have to avoid relational *modeling* within the database. And the challenge you get into at that point is
    • Perhaps it would have been easier for IBM to ship DB2 with a copy of McGovern and Date.

      I had the distinct pleasure to discuss exactly this topic with Date yesterday. Yes, that Date. To say that he's not pleased with the idea of XML in databases would be a very british understatement. In his words "it's a throwback to the hieracical database model, that has already been proven defect once and for all".

      On top of that I would like to add that it's extremely rare that one encounters an international celebrit

  • I see the captain saying:

    'Operation Cobra!'

    For americans (hey, I am in *that* mood today ok), I mean Queen Latifa saying 'you didn't jus', or 'yo moma'.

    Get the door, it is France! They want their little statue back! ;-)
  • Will it still commit partially-completed transactions when network connectivity between host and client break? Man, that's a feature I really loved. 18 months ago, even IBM reps told us "stay on Informix until the next major release." Now that the release is finally here, we've moved to Oracle.

    All DB2 flaming aside, how many other enterprise-class organizations looked at DB2 and took a pass? If you picked it, what did it do better than the commercial competitors? Just because we ditched it doesn't mean I wo

  • XML Query and XML in databases (Score:4, Insightful)

    by Ankh ( 19084 ) * on Wednesday November 23, 2005 @04:56PM (#14103336) Homepage
    A few people have asked whether DB2 is going to support XQuery, or said that it won't, or that putting XML in databases is stupid, or that there are no advantages to having XML in relational databases.

    The IBM article does say that their Viper product will support XML Query (it's also known as XQuery).

    So yes, looks like they will be supporting XML Query.

    Is it a good thing? Some pretty smart people seem to think it's a good idea, so maybe it's worth at least taking the time to listen to them.

    If the only XML you've dealt with is the result of marking up relational tables, you might not see much advantage.

    If you have a lot of XML documents, though (say, five million) that all validate to an XML Schema, you know some things about them. You might know, for example, that all of the price elements contain numbers. You might know that the description elements may contain embedded partnumber elements intermixed with the text, and that those partnumber elements contain part numbers formatted a particular way.

    A database can build an index based on this sort of information, and can do very efficient searches and "joins".

    You might also think about what you could do if you had all of the XHTML documents from some major Web site (perhaps an Intranet corporate site, or maybe your own personal site) stored in a database in such a way that you could easily make different views of the information.

    I think the real niche for XQuery might be as middleware: the ability to run queries against multiple databases, whether XML or relational or flat file or whatever, without caring about how the data is stored, can be very interesting, not to say useful.

    ISO SQL has also standardised on how to map between SQL and XML Query data types, and on how to evaluate XML Query expressions embedded in SQL expressions. The Java Community Process has been working on XQJ, a way to reach out to XQuery data stores from within Java.

    The XML Query Home Page [w3.org] (disclaimer: I maintain this) lists some 45 implementations, both proprietary and open source. Not all of these are complete, but, as others have noted here, XML Query is a W3C Candidate Recommendation: we're asking for public feedback from implementors, and trying to make sure that the specification is clear and precise enough that implementations all work the same way.

    I think XML Query support in SQL databases is likely to become pretty widespread. Until it is, you can also use some open source implementations that support JDBC, as well as one or other of the commercial implementations that support query optimisation over external SQL-based data stores.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close