Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sneak Peek at IBM 'Viper' DB2 Release

ScuttleMonkey posted more than 8 years ago | from the taking-the-gloves-off dept.

IBM 181

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

cancel ×

181 comments

Sorry! There are no comments related to the filter you selected.

"the SQL programming language" (5, Funny)

jeroenb (125404) | more than 8 years ago | (#14099337)

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" (4, Funny)

n0dalus (807994) | more than 8 years ago | (#14099359)

It's a query language.

Yeah. The SQL query language.

Re:"the SQL programming language" (2, Funny)

Vengeance (46019) | more than 8 years ago | (#14099438)

Correction: The Structured SQL Query Language.

Re:"the SQL programming language" (4, Funny)

Zemplar (764598) | more than 8 years ago | (#14100224)

How about GNSQL language?

GNSQL's Not a Structured Query Language language.

Re:"the SQL programming language" (2, Informative)

mmkkbb (816035) | more than 8 years ago | (#14099368)

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

Re:"the SQL programming language" (1)

DrSkwid (118965) | more than 8 years ago | (#14099453)

SQL has no logic, ergo that description is wrong.

If a procedure is encapsulated logic

that's a pretty big if

Re:"the SQL programming language" (1)

Sicnarf (529730) | more than 8 years ago | (#14100661)

stored procedures are seperate from SQL. the SQL standard has no mention of programming constructs (if, else, stored procs), even though you embed SQL commands in stored procedures. the only correlation is calling a stored proc within SQL (with the execute or call statement).

Re:"the SQL programming language" (1)

Kaemaril (266849) | more than 8 years ago | (#14099388)

Maybe this is a typo for "SQL procedural language", which is DB2's version of Oracle's PL/SQL.

Re:"the SQL programming language" (2, Informative)

RotateLeftByte (797477) | more than 8 years ago | (#14099468)

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 Oracle, DB2, SQL/Server or Sybase.

Re:"the SQL programming language" (4, Interesting)

Ed Avis (5917) | more than 8 years ago | (#14099842)

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.

Re:"the SQL programming language" (2, Interesting)

mmkkbb (816035) | more than 8 years ago | (#14100510)

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.

Re:"the SQL programming language" (1)

S.O.B. (136083) | more than 8 years ago | (#14100712)

Hurray for proprietary extensions that promote vendor lock-in.

Re:"the SQL programming language" (1)

tolkienfan (892463) | more than 8 years ago | (#14101065)

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.

Re:"the SQL programming language" (1)

tod_miller (792541) | more than 8 years ago | (#14100461)

It is the stuctured query language programming language query language.

I just wait for the prequel.

Re:"the SQL programming language" (1)

s0rk (810678) | more than 8 years ago | (#14100600)

Is that something like a "Digital" modem?

Sneak PEEK (4, Informative)

Sexy Bern (596779) | more than 8 years ago | (#14099343)

Not "peak". Sheesh!

Re:Sneak PEEK (2, Funny)

Anonymous Coward | more than 8 years ago | (#14099351)

Give him a break. At least this time he read it through and checked if it had been posted before!:)

Re:Sneak PEEK (1)

Sexy Bern (596779) | more than 8 years ago | (#14099369)

Hey, there's still time.

Re:Sneak PEEK (5, Funny)

peetola (700206) | more than 8 years ago | (#14099428)

I had a sneak peak once in high school. Very embarrasing.

Re:Sneak PEEK (1)

R2.0 (532027) | more than 8 years ago | (#14100375)

A "sneak" paek isn't the problem - it's when it becomes not so sneaky.

That's OK, I'll take the zero.

Although I think I once caught a female classmate jilling off in the middle of class using the crossed legs trick.

Re:Sneak PEEK (0)

Anonymous Coward | more than 8 years ago | (#14099436)

Not "peak". Sheesh!

ITYM Sheash!

Oracle (1)

bLanark (123342) | more than 8 years ago | (#14099350)

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.

Re:Oracle (1)

robiurl.biz (933349) | more than 8 years ago | (#14099400)

IBM are normally full of good ideas, its weather they can put them into practice

Re:Oracle (0)

Anonymous Coward | more than 8 years ago | (#14099932)

its weather they can put them into practice

So, this means they can put their sunny or their rainy, or maybe even their cloudy into practice?

I don't know whether to believe or not.

Re:Oracle (1)

NineNine (235196) | more than 8 years ago | (#14099413)

Oracle's had this for years. Since v 8, I think? (corrections welcome)

Re:Oracle (5, Informative)

bLanark (123342) | more than 8 years ago | (#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 (5, Informative)

bj_rmz (601513) | more than 8 years ago | (#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 (0)

Anonymous Coward | more than 8 years ago | (#14100765)

Indeed, it is quite humorous to watch; next thing you'll see will be someone extoling the virtues of the Pick OS! Or Mumps for gosh sake!

Re:Oracle (3, Insightful)

stephenbooth (172227) | more than 8 years ago | (#14099623)

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

Stephen

Re:Oracle (1)

zootm (850416) | more than 8 years ago | (#14100711)

Doesn't it essentially store it raw, and use another system to load and query the XML, rather than this more-native approach?

Re:Oracle (1)

Asgard (60200) | more than 8 years ago | (#14101078)

Oracle can do it both ways, but if you provide a XML schema to Oracle it will 'shred' your document into tables that are efficient to process.

Re:Oracle (1)

zootm (850416) | more than 8 years ago | (#14101128)

That's not really the same, I think (I have to admit knowing little to nothing about the Oracle implementation here), but at least it does something.

It would be interesting to see the Oracle and IBM implementations put side-by-side.

Re:Oracle (1)

christoofar (451967) | more than 8 years ago | (#14100069)

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.

Re:Oracle (1)

duffbeer703 (177751) | more than 8 years ago | (#14100255)

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.

Re:Oracle (1)

electroniceric (468976) | more than 8 years ago | (#14100501)

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 first blush, it's basically just a question of figuring out how to comprehensively auto-update the mappings for database objects, as well as dealing with transactions and performance issues.

The nice thing about IBM's version is that they can control the database-Virtualization Server communication, so they can really optimize perfomance out of the box.

It looks like we may finally be reaching some meaningful convergence of object models and storage models.

XML database (1, Offtopic)

RasendeRutje (829555) | more than 8 years ago | (#14099397)

Talking about native XML databases... My company can't find a decent one, preferably open source. Any suggestions?

Re:XML database (3, Insightful)

Oscaro (153645) | more than 8 years ago | (#14099406)

Talking about native XML databases... My company can't find a decent one, preferably open source.

That's probably because an XML database is NOT a decent idea. XML is NOT meant to be used as a way to store data! Rather, it's a way to communicate data between entities.

Sadly, XML is a one of those words that have the magic power to make marketing people happy. So they put it everywhere. If that doesn't work, they just put more.

Re:XML database (1)

RasendeRutje (829555) | more than 8 years ago | (#14099443)

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.

Re:XML database (2, Informative)

Oscaro (153645) | more than 8 years ago | (#14099577)

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.

Re:XML database (1)

TheSpoom (715771) | more than 8 years ago | (#14100739)

...saying "we store data as XML natively" sounds to me just a silly marketing campaign.

Not to mention a HUGE waste of space.

Seriously, how long could it have taken them to grab an XML parser and store the relevant data of the XML in a tree format? Maybe I'm missing something about how this is so earth-shattering. But then, I'm a developer, not a PHB who only hears buzzwords like "XML".

Re:XML database (2, Informative)

Randolpho (628485) | more than 8 years ago | (#14099918)

XML is neither a means of storing data, nor a means of communicating data, but is only a means of *marking up* data.

Re:XML database (2, Insightful)

Daniel Dvorkin (106857) | more than 8 years ago | (#14099417)

There aren't any. XML databases are a dumb idea, and they will never perform as well as regular relational databases. The best thing you can do is store your data the regular way, and use an application layer to read and write XML as needed.

Re:XML database (2, Insightful)

CrankinOut (629561) | more than 8 years ago | (#14099541)

As I recall, that's the same sentiment expressed about relational databases when the current state of the art was hierarchical and CODASYL databases in the 70's. All it takes is one really good implementation of the new idea to change this perception.

There were huge debates about the "abstract model" of a relational database that didn't make sense in The REAL WORLD (TRW), because "real" problems were more complex than the relational model and performance would suffer.

I don't know that an XML database is "better", but then again, I don't know that it isn't. Maybe I'll learn something!

Re:XML database (1, Informative)

Kenneth Stephen (1950) | more than 8 years ago | (#14099621)

There aren't any. XML databases are a dumb idea, and they will never perform as well as regular relational databases.....

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.

Re:XML database (1)

dwandy (907337) | more than 8 years ago | (#14100589)

...on XQuery. I dont know if "Viper" supports [XQuery] (unlikely, since the standard is now at W3C candidate recommendation status still

from TFA:

The XML data will be accessible through the XQuery XML query language, which is an analog to SQL for relational databases.

Re:XML database (1)

RegularFry (137639) | more than 8 years ago | (#14099671)

What's it for?

Re:XML database (1)

RasendeRutje (829555) | more than 8 years ago | (#14099793)

My company designs information products (e.g. manuals, helpfiles, elearning) and uses XML for storing documentation. We store small snippets of information (paragraphs) in an XML database. And compile the snippets to documents and publish this document in any format (e.g. HTML, PDF, CHM). We're using XML because you can separate content from layout.
Shameless ad: http://www.axis.nl/informatie-ontwerpers/english/ [www.axis.nl]

Re:XML database (1)

RobWalker (623706) | more than 8 years ago | (#14099727)

Try: http://www.sleepycat.com/products/bdbxml.html [sleepycat.com] As I recall, it is open source as long as your application is also open source (or used purely internally). Bit like GPL, but under their own license

Re:XML database (1)

barticula (886847) | more than 8 years ago | (#14100106)

I don't know about decent, but Apache has an open source one called Xindice. I last used it about 9 months ago, and there were problems, but you may want to check it out to see if it's gotten better. http://xml.apache.org/xindice/ [apache.org]

Re:XML database (1)

dtietze (708094) | more than 8 years ago | (#14100362)

Try Infonyte DB: http://www.infonyte.com/ [infonyte.com]

No, I'm not related to them.

Dan.

So? (1)

thogard (43403) | more than 8 years ago | (#14099414)

Its a 4GL with XML inplace of SQL?
Most of the old 4GL databases are something on the order of 10,000 times faster than any SQL I've ever seen.
This could give them a massive speed increase.

But what do I know, I've been running major databases in flat files for decades because I figure a modern OS/VM system can cope with 1 gig of real data faster any combination of data+database over head in the problems I deal with.

Re:So? (3, Insightful)

emamousette (871456) | more than 8 years ago | (#14099488)

If you've been running these databases successfully, you're probably spending a lot of time writing and maintaining code to handle ACID issues, locking, and other headaches.
Why not pay someone else to do that kind of work?

[And yes, you can donate to PostgreSQL development!]

Re:So? (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14100223)

1 gig? Major database? BWAHAHAHAHAHAHA!

Excellent (1)

squoozer (730327) | more than 8 years ago | (#14099426)

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 (1)

srpatterson (515721) | more than 8 years ago | (#14099456)

Is your copy of Postgres missing the string datatype?


Or do you just need something thats buzzword compliant :P

Re:Excellent (1)

squoozer (730327) | more than 8 years ago | (#14100035)

That's how I do it at the moment but don't you think it would be better if the database had an XML type? You could, for instance, apply a doctype / schema to the field thus ensuring data integrity or perhaps use XPath in a query to load only certain rows. Both of these things can be done in your own code but that's not an excuse for re-inventing the wheel everwhere it's needed.

Re:Excellent (1)

plopez (54068) | more than 8 years ago | (#14100822)

it is open source. write an extension and release it :)

(btw, you can define your own data types in the PG DB, that + PG/SQL (or PG/Java) + external procs may be the way to go)

Technology Pot Pie (4, Informative)

borkus (179118) | more than 8 years ago | (#14099458)

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

Verily I say unto you (0)

Anonymous Coward | more than 8 years ago | (#14099686)

Notes was a very unique platform for document databases.

Substituting 'one of a kind' for 'unique', your sentence reads....Notes was a very one of a kind platform for document databases.

Writing "very unique" is akin to saying "it's very daytime."

Why does proper grammar matter? Because when it's not used, it dings your credibility. Whether that's fair or not is moot - it happens. Moreover, it sidetracks your reader. Instead of reading what you've written, the reader might respond with a pendantic off-topic comment about grammar instead of thinking "gee, what an interesting comment..."

Re:Verily I say unto you (0)

Anonymous Coward | more than 8 years ago | (#14100108)

You miss how it really works. Something can be unique because of a single factor, or because of multiple ones. If it's only unique because it differs from other objects by one single factor, we would say that it's not very unique. It is, of course, unique in the very strictest definition, but it's a terrible example of uniqueness. If it is different from other objects in almost every way, then we would say it is very unique. It's still just as unique as my previous example, in the strictest sense, but it's clear to anybody that there's more to it than that, and that's what people are expressing by putting modifiers in front of "unique" like "very".

Re:Technology Pot Pie (2, Insightful)

Greyfox (87712) | more than 8 years ago | (#14099962)

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 forces all their employees to use Notes is that they have to justify the purchase of Lotus for 6 BILLION DOLLARS.

Every so often a company other than IBM will try Lotus Notes. I've encountered a couple of them over the course of my career. Interest quickly devolves into the deep kind of loathing that I describe here. That usually results into a quick move (back) to MS Exchange server.

I keep hoping that IBM will give up on Lotus Notes and kill that atrocity, just like they killed Smartsuite and OS/2. Unfortunately they seem bound and determined to get some value for their 6 BILLION DOLLARS, even if it means saddling every employee in the company with the worst E-Mail client on the planet.

Re:Technology Pot Pie (2, Informative)

FooAtWFU (699187) | more than 8 years ago | (#14100060)

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 IBM to make a switch possible.

Re:Technology Pot Pie (1)

TexVex (669445) | more than 8 years ago | (#14100420)

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 Exchange server, and Windows XP is to me a necessary evil. Microsoft Word needs to be dragged out back, shot, and left for the vultures. But Excel is a good product, and Access kicks ass when used to fill its niche -- as a database frontend, for data querying and reporting, and as a platform for quickly creating and deploying data entry and data management tools/utilities. It's also a badass tool for rapidly prototyping database applications.

(I've recently started using OpenOffice.org Base and I find it to be a great product as well, but I don't know yet where it falls short of or overcomes Access.)

Re:Technology Pot Pie (1)

metamatic (202216) | more than 8 years ago | (#14100542)

As of Notes 7, you can use DB2 as the underlying data store, and have a fully relational database.

FYI.

Re:Technology Pot Pie (1)

digidave (259925) | more than 8 years ago | (#14100909)

"As of Notes 7, you can use DB2 as the underlying data store"

That sounds cheap and efficient.

Re:Technology Pot Pie (2, Informative)

tigersha (151319) | more than 8 years ago | (#14100539)

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

Notes is a fine document store and OKish to quickly bring up a quick website for use by something. It is also Okish when it comes to dealing with groupware-related stuff. The UI of the mail client sucks bad but the underlying idea of implementing the Mailstore as a document databse definitely has its plus points. It makes some kinds of mail management tasks (member newsletters and tracking of bad mail addresses) quite easy.

On the plus side, it slao does things like remote calling (through Corba and Java) very easy and it has a very good implementation built into the entire system of PKI. Notes also can replicate and communicate through a pice of wire connected the Joytick port. It is very reliable in that way. The replication of data is very good, UNLESS there is a conflict, in which case it sucks, sucks sucks. Please people, can I PLEASE KNOW WHICH GODDAMN FIELD CAUSED THE PROBLEM???

But in the name of all that is holy, I hope they improve the stupid godawful horrifyingly bad development environment. Not that I care, I will be leaving my Notes nightmare rather soon.

I am the viper... (5, Funny)

pulse2600 (625694) | more than 8 years ago | (#14099465)

I am the vinder viper!!!! I vill be there in three months!!! I come to vipe your vindows!!!

Re:I am the viper... (1)

Zemplar (764598) | more than 8 years ago | (#14100258)

{waving toilet tissue in hands}

"Anyone need a vipe?"

Late to the party (3, Insightful)

cyberjessy (444290) | more than 8 years ago | (#14099470)

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! (3, Funny)

brunes69 (86786) | more than 8 years ago | (#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:It sure is mauve! (1)

dwandy (907337) | more than 8 years ago | (#14099640)

The first thing we look for is the mauve databases - we need all the ram we can get.

Re:Late to the party (2, Informative)

kpharmer (452893) | more than 8 years ago | (#14099929)

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

DB2 has always been late. (1)

emil (695) | more than 8 years ago | (#14101056)

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, and that is not a nice place to be.

IBM answers MS (3, Interesting)

Decker-Mage (782424) | more than 8 years ago | (#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).

Re:IBM answers MS (0)

Anonymous Coward | more than 8 years ago | (#14099620)

I cannot see the difference between Viper and MSSQL2005. Could someone enlighten me? Both allows us to store XML and use XQuery towards those.

Re:IBM answers MS (1)

jsight (8987) | more than 8 years ago | (#14099905)


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.

Re:IBM answers MS (1)

S.O.B. (136083) | more than 8 years ago | (#14100843)

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 (2, Informative)

kpharmer (452893) | more than 8 years ago | (#14100213)

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

Re:IBM answers MS (0)

Anonymous Coward | more than 8 years ago | (#14100747)

You are not quite correct. There will be one database engine, and one optimizer. There will be two query languagges. XML will be stored on the disk in a different format than the tabular storage already. The parser, optimizer, and database engine have been enhanced to understand XQuery. As a matter of fact, you can combine query languages, for example using XQuery in a subquery of a SQL query.

Presently (v8.2) there is a non-priced option - the XML extender, which allows for manipulation of xml in either columns or blobs through functions and stored procedures. In Viper the xml manipulation primitives are added, both as a means of selection, and displaying results, as well as updating, inserting and deleting all or parts of an xml document.

The pricing will probably be about the same, or a bump up from what you are paying now. XML support is not an extra option, it is an integral part of the product.

I have read the specs and have been to presentations from the developers.

It still sucks (1)

roman_mir (125474) | more than 8 years ago | (#14099554)

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.

Re:It still sucks (0)

Anonymous Coward | more than 8 years ago | (#14099675)

DB2 still wins the comparison of math functionality native to the rdbms.

Re:It still sucks (1)

kskuhlman (701471) | more than 8 years ago | (#14099923)

Rollback segment? Sounds like savepoint, which db2 has had for years.

Re:It still sucks (1)

ciggieposeur (715798) | more than 8 years ago | (#14099977)

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 (5, Informative)

kpharmer (452893) | more than 8 years ago | (#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...

I HATE DB2 Re:It still sucks (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14101136)

As a Java programmer, DB2 sucks.

Only DB2 forces us to use static sql.
DB2 makes mistake when it decides access path and to avoid the mistake, they say you have to use staic sql, bind it, and never rebind it.
So IBM tells you not to use dynamic SQL and not to use JDBC.

Because of it, the failure of DB2, they said you have to use SQLJ
rather than JDBC as usual.
But who else is using SQLJ now?
Oracle, Sun, JBoss, BEA, HP, MySQL, and every one else use JDBC as a standard. Many frameworks such as Hibernate, iBATIS use JDBC. If you are DB2 user, you can't use them.
Of cause SQLJ is not in J2SE nor J2EE.

IBM supports PHP?
Then how does IBM make PHP use static SQL?
They are making a precompiler for PHP?
I have no idea and all I can say is IBM is stupid.
They are dying dinosaur.

Usefulness? (3, Interesting)

CodeShark (17400) | more than 8 years ago | (#14099731)

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?

Re:Usefulness? (1)

plopez (54068) | more than 8 years ago | (#14100854)

Am I missing something?

ACID compliance, mainly consistency in this case. Which with a tree structure you can easily violate.

Why waste time and money in DB (-1, Flamebait)

TarrySingh (916400) | more than 8 years ago | (#14099776)

IBM (and all other monkeys) should just leave databases to Oracle!

Re:Why waste time and money in DB (1)

iBod (534920) | more than 8 years ago | (#14099900)

Yea, sure.

IBM had a serious DBMS (IMS DL/1) a decade before Oracle even existed.

Codd and Date were IBM Research follows weren't they?

I never have been impressed with Oracle's product or the bullshit that goes with it (or their fanboys).

Don't tell me you haven't heard this old chestnut...

Q: What's the preferred hardware platform for Oracle?

A: The salesman's slide projector of course!

 

Re:Why waste time and money in DB (1)

slysithesuperspy (919764) | more than 8 years ago | (#14099970)

Might as well nationalize Oracle Corporation at the same time!

Re:Why waste time and money in DB (1)

TarrySingh (916400) | more than 8 years ago | (#14100810)

I was thinking in terms of globalization ;-)

What the hell? (0, Offtopic)

Viper Daimao (911947) | more than 8 years ago | (#14099872)

I call prior art!

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

Anonymous Coward | more than 8 years ago | (#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 (2, Insightful)

sgent (874402) | more than 8 years ago | (#14100070)

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.

Re:MSSQL (1)

spectrokid (660550) | more than 8 years ago | (#14100218)

Not that I would have a clue or anything, but if Oracles distributed filesystem hits the next Linux kernel, will MySQL and Postgress be able to profit from that?

XML Database, Good or Bad (3, Interesting)

awol (98751) | more than 8 years ago | (#14100388)

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.

Re:XML Database, Good or Bad (2, Insightful)

kpharmer (452893) | more than 8 years ago | (#14100487)

> 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 that you lose some valuable features such as foreign key support, etc. But it is doable, just performs slowly and is labor-intensive to create. Still, it has its place.

> However in my view correct normalisation solves most of these issues and makes
> the need for native XML unnecessary.

Hmmm, not sure about that. Dynamic models weren't really an issue thirty years ago when Codd was coming up with these ideas: business changed much more slowly. Today we're changing business rules so quickly - and expect to modify major systems in the blink of an eye. As mentioned above, we can support this using relational systems, but we end up heading away from normalization, not towards it.

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

Until people determine what the 'best practices' are for such a database they can get into trouble with it: how do you convert the data when the application changes? Is it easy as it is today with relational databases? Or do you have to write entire data conversion apps (like you did with hierarchical databases twenty years ago). How do you design & tune for performance? How do you handle data quality? Well, it will probably be best to start with some very small projects ;-)

For some reason... (viper/cobra/obscure) (1)

tod_miller (792541) | more than 8 years ago | (#14100481)

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! ;-)

Re:For some reason... (viper/cobra/obscure) (1)

The_Dixie_Flatline (842927) | more than 8 years ago | (#14100792)

Or, 'Operation CORBA'?

Awesome! (1)

Bravo_Two_Zero (516479) | more than 8 years ago | (#14100959)

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 wouldn't care to understand where others in the same situation have landed.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>