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

Comments

"the SQL programming language"

[jeroenb]

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"

[n0dalus]

It's a query language.

Yeah. The SQL query language.

Re:"the SQL programming language"

[mmkkbb]

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

Re:"the SQL programming language"

[Kaemaril]

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

Re:"the SQL programming language"

[Vengeance]

Correction: The Structured SQL Query Language.

Re:"the SQL programming language"

[DrSkwid]

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"

[RotateLeftByte]

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"

[Ed Avis]

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"

[Zemplar]

How about GNSQL language?

GNSQL's Not a Structured Query Language language.

Re:"the SQL programming language"

[tod_miller]

It is the stuctured query language programming language query language.

I just wait for the prequel.

Re:"the SQL programming language"

[mmkkbb]

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"

[s0rk]

Is that something like a "Digital" modem?

Re:"the SQL programming language"

[Sicnarf]

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"

[S.O.B.]

Hurray for proprietary extensions that promote vendor lock-in.

Re:"the SQL programming language"

[tolkienfan]

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"

[Anonymous Coward]

Right, like Java which is Sun's closed version of BASIC extended with syntactical sugar from ALGOL and Smalltalk.

Re:"the SQL programming language"

[alekd]

Have you ever heard about CONNECT BY?

Re:"the SQL programming language"

[Kaemaril]

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 the other?

Re:"the SQL programming language"

[jp25666]

It's also important to note that SQL uses sets/bags as a primitive data type. In an all-purpose, Turing complete programming language, support for sets is limited or non-existent. If you want to integrate the two, you usually have to use a cursor in an all-purpose programming language, and go through all the tuples of the set one by one. So, it's even less of a "one is better or more powerful than the other" thing. SQL is just different from all-purpose languages.

Re:"the SQL programming language"

[Anonymous Coward]

Yeah. The SQL query language.

YEEAH! The SQL structured query language!

(Brought to you by the Department of Redundancy Department)

Re:"the SQL programming language"

[arkanes]

In an all-purpose, Turing complete programming language, support for sets is limited or non-existent.

Eh? Maybe you meant set operations, as in set theory? sets and bags, as data structures, are well supported (Turing equivilence and all that).

If you want to integrate the two, you usually have to use a cursor in an all-purpose programming language, and go through all the tuples of the set one by one.

In order to *do* anything with a set, you must go through the tuples of the set in some way (not neccesarily one by one). That is why programming languages interact with them like that. The fact that SQL cannot do that is one reason it is not a programming language - it can only describe sets, not act upon them.

Re:"the SQL programming language"

[arkanes]

So, it's even less of a "one is better or more powerful than the other" thing. SQL is just different from all-purpose languages.

SQL is unequivocaly less powerful than a Turing-complete language, pretty much by definition. SQL can only describe sets, the same way that you might describe a set (actually a tuple, but whatever) in Python as (1,2,3,4). There's no reason a set-based language can't be Turing complete, as thats exactly what PL/SQL and the various other prodecural variants are, but SQL per se is absolutely not as powerful as any "general purpose", Turing complete language.

Re:"the SQL programming language"

[JulesLt]

The CONNECT BY and equivalent extensions have been in most variants of SQL for at least a decade.
CASE allows limited conditional functionality, and has also been in the standard for some time.

Most variants now support the idea of being able to order things and do things to the ordered set, which was once an abhorrence (once upon a time, the only time you could apply an order was to the final returned result set).

Of course this is a battle between the pragmatic needs of programmers using SQL, and the relational theorists who want to keep it mathematically clean - which is why the language so often races ahead of the standard, then they finally begrudgingly accept that if everyone has some version of CASE / DECODE / etc, then they'd better define an ANSI standard one.

Re:"the SQL programming language"

[marklark]

How about GNUSQL? (Pronounced "New School")

GNUSQL's Not an Un-Structured Query Language :^)

Re:"the SQL programming language"

[fbg111]

Or,

GNSQL's Not a SQL Query Language language.

Re:"the SQL programming language"

[clem.dickey]

> SQL can only describe sets

SQL 99 can also construct sets, using "common table expressions." (implemented in DB2 and SQL Server). Whether the construction terminates depends on the construction logic and, of course, the input data.

I think Oracle has something similar in CONNECT BY, but their construct didn't happen to get chosen for SQL 99.

Re:"the SQL programming language"

[S.O.B.]

Firstly, Java is a bit more sophisticated than BASIC.

Sun's implementation may not be open enough for some but the Sun community license is not as closed as something like .NET.

And while Sun's Java implementation is not entirely open the Java spec is open which has allowed many vendors to create compatible runtimes. GNU has GCJ which is still a work in progress but is getting better all the time. The project may just be starting but Apache's Harmony is also promising.

A 100% open source Java runtime implementation is inevitable.

Re:"the SQL programming language"

[clem.dickey]

> It does follow SQL92 when accessing databases though.

DB2 doesn't implement of SQL 92. And it implements some things which are not SQL 92.

So what does the parent mean by "follows"? Perhaps that where DB2's syntax happens to intersect that of SQL 92, its semantics do also.

Re:"the SQL programming language"

[jadavis]

With PostgreSQL you can use languages like java and perl.

That's hardly vendor lock-in.

Re:"the SQL programming language"

[S.O.B.]

I was referring to the proprietary extensions mentioned by the grandparent post.

Re:"the SQL programming language"

[Ed Avis]

Be careful. 'SQL procedures' are not SQL. They are some proprietary addon language like Postgres's PL/pgSQL, Oracle's PL/SQL or Sybase/Microsoft's T-SQL. SQL itself doesn't have any way to create procedures, set local parameters etc. Don't say SQL when you mean something else.

Re:"the SQL programming language"

[Ed Avis]

Yes, I've heard of CONNECT BY, and it is not powerful enough. Try it:

create table parent (person varchar(100), parent varchar(100));
create table ancestor (person varchar(100), ancestor varchar(100));

insert into ancestors ..... what?

There is no ordinary SQL query (at least with the SQL92 standard, or with Oracle 9.x) that will populate the ancestor table with a transitive closure of the parent relation.

However, you can do it by running the same insert SQL over and over again until no rows are updated. This requires a loop, which SQL doesn't support - but you can easily do it using a procedural language like Perl or PL/SQL to repeatedly run your query.

Sneak PEEK

[Sexy Bern]

Not "peak". Sheesh!

Re:Sneak PEEK

[Anonymous Coward]

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

Re:Sneak PEEK

[Sexy Bern]

Hey, there's still time.

Re:Sneak PEEK

[peetola]

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

Re:Sneak PEEK

[Anonymous Coward]

Not "peak". Sheesh!

ITYM Sheash!

Re:Sneak PEEK

[R2.0]

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.

Oracle

[bLanark]

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

[robiurl.biz]

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

Re:Oracle

[NineNine]

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

Re:Oracle

[bLanark]

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.

Re:Oracle

[bj_rmz]

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

[stephenbooth]

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

Stephen

Re:Oracle

[Anonymous Coward]

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

[christoofar]

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

[duffbeer703]

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

[electroniceric]

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

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.

Re:Oracle

[zootm]

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

[Anonymous Coward]

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

[Asgard]

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

[zootm]

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

[rubycodez]

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

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

If Oracle's marketing has convinced you of something different, then that's their marketing department's fault. The exact implementation (how the XML tree is stored) and syntax (how you query it) is irrelevant. The relational model, and classical type theory (which predates the RM) already tells you how to think logically and abstractly about any data storage and manipulation task, without regard to the peculiarity of any particular product.

For a more concrete example, not using the syntax of any particular product:

EMPLOYEE_DETAIL = (EMPLOYEE# employee#, XML_DOCUMENT resume, JPEG_IMAGE mugshot),
PRIMARY KEY EMPLOYEE_DETAIL employee#,
KEY XPATH(resume, '/employee/@id'), -- they should be unique and indexed
ASSERT IS_VALID_XML(resume, 'whatever.dtd'),
ASSERT XPATH(resume, '/employee/@id') = employee#,
ASSERT IMAGE_SIZE(mugshot) < (512, 512) AND IMAGE_SIZE(mugshot) > (128, 128);

-- find all employees that listed more than 5 skills and whose last name begins with "Smit"
SELECT EMPLOYEE_DETAIL
WHERE XPATH(resume, 'count(/employee/skills/skill) > 5')
AND XPATH(resume, '/employee/first_name') LIKE 'Smit%';

Of course, this needs a cup and a half of syntactic sugar to make it more pleasant when using XML-heavy applications (for instance, XPath could be embedded a little more gracefully), but surely you can see that all XML databases can reduce to the same model. Those that are created with ignorance of the relational model won't be as useful.

A well-designed relational database would already be an XML (hierarchic) database, and would already be an object (network) database, because those are both less general than the RM (entities related by arbitrary assertions).

One problem with today's SQL products (and they have MANY) is that you can't create your own types easily. You should be able to add XML support, object support, or whatever else, as easily as you can with a general-purpose programming language. You shouldn't have to wait for the vendor to "add" it.

Imagine if you had to *wait for a new release* to get XML support in Java or Perl. Yeesh. Yet database users seem perfectly content to suck down the crap from the vendors. They don't know what to ask for or how to evaluate what they get. Even though this was mostly figured out 30 years ago.

Re:Oracle

[sydb]

I tried to selectively quote the bits of your post that mean you do not pass the Turing test, but it ended up being your whole post. I call you on it, you're either a salesman or a pisspoor AI program.

XML database

[RasendeRutje]

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

Re:XML database

[Oscaro]

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

[Daniel Dvorkin]

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

[RasendeRutje]

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

[CrankinOut]

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

[Oscaro]

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

[Kenneth Stephen]

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

[RegularFry]

What's it for?

Re:XML database

[RobWalker]

Try: http://www.sleepycat.com/products/bdbxml.html 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

[RasendeRutje]

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/

Re:XML database

[Randolpho]

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

[barticula]

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/

Re:XML database

[dtietze]

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

No, I'm not related to them.

Dan.

Re:XML database

[dwandy]

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

[TheSpoom]

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

[yukster]

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

Did you take a look at eXist (http://exist.sourceforge.net/). I've used it a bit and found it well-documented and with useful tools like a swing query tool and a web app to run the server from. Alas, Xindice seems to have gone no where though.

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.

That's because you are a data bigot. :-) The general bar=foo stuff may be far more common than document-centric or heavily hierarchical data, but that just makes the latter "minority" data... you treat minority people as if there irrelevant too? In all seriousness though, a relational db quickly becomes a major pain in the ass when storing hierarchical data... like querying parentage of arbitrary depth... yech. And, the best thing about IBM adding native XML abilities to DB2 is that you get the best of both worlds... no need to deal with two different servers. That sounds like a winning proposition to me.

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?

Um, that's what they did... what do you think "native XML" means? That they store formatted XML strings in a huge text field? No, they parse the XML into some sort of DOM and store the pieces in hierarchical fashion... which creates -- ta-da -- a tree! And, if IBM has been as fastidious as I've usually found them to be (particularly on one of their flagship, high-dollar products) this tree is probably heavily optimized, with appropriate re-use of nodes and indexed to make queries faster.

I have to say, I really, really can't fathom the rampant XML prejudice I keep running into. There may have been a better approach to marking up documents or modeling hierarchical but, well, the W3C didn't pick those. Sorry if you had a brilliant markup format that was passed over. But too bad! It's done! XML is now far, far too entrenched to be worth throwing out at this point.

And it's really not that bad. I'm so sick of seeing, "ew, it's a waste of space"... Why, because the file is formatted? Well, stip the formatting out... and compress it for crying out loud. Hmm, kind of like OpenOffice did... I actually saw some (paid!) ding dong on a major tech site say that it would be a disaster for Microsoft to switch to XML-based file formats... "think about how huge the files would be!" Um, OpenOffice's file formats are a zipped group of XML files... have you ever compared OpenOffice file size to binary Word doc file size? Say no more! (Plus there's the benefit of being able to write programs that unzip the OO file and parse data out of the XML content... all with readily available open-source tools.)

XML is very useful for a number of things. There is a huge number of tools available to work with it. And it has finally given the IT world at least a start on a common data format. Yes, it can be abused... but then so can a relational db or sql or any programming language, etc. etc.

Re:XML database

[Anonymous Coward]

Shameless plug: http://marklogic.com/

There's a free download, good for 30 days and up to 1 GB.

Re:XML database

[handslikesnakes]

Berkeley DB XML is decent.

Re:XML database

[pkaminsk]

If you're not averse to Java, eXist (http://exist-db.org/ is open source and works reasonably well. It's still under heavy development, but the core functionality is fairly stable.

Re:XML database

[TheRaven64]

Now, are RDBMS's faster than you directly accessing a flat file whose structure your program knows about? Absolutely not.

That depends on the structure of your flat file. Consider a plain text file. You can't easily say 'jump to line 100' (well, you can on a real OS, but not on UNIX or Windows) - you have to read it from the start and count the line breaks (O(n) performance on the file size). If, however, you put each line in a database, then it will almost certainly index the records in either a tree or a hash table giving either O(1) or O(log n) on the number of lines. In this case, a database is faster. In a lot of other cases, I suspect it is faster to just dump your data in a database than it is to design an efficient file format...

Re:XML database

[Anonymous Coward]

This leads me to believe that you dont understand what modern database technology is all about.

Database technology, modern or otherwise, is about integrity and manipulation. How do you guarantee integrity in an XML file? How do you manipulate an XML file?

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.

Replace "database" with DBMS and you are correct. Let's see if this is a fluke, or if you really know what you are talking about. :-)

Yet its a stupid idea in this day and age to architect an application with flat files instead of an RDBMS as a datastore.

Not necessarily. What's "stupid" is undertaking a data management task (SQL, object, XML, flat file, or other) without an understanding of the relational model, which underlies all of them one way or another.

An XML file is explicitly structured.

So is CSV, JPEG. Heck, ASCII has an explicit structure. Why don't we clamor for native JPEG databases?

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.

"Human readable" .. that one always makes me chuckle.

How will XML open up new worlds? How is it better than what was there before?

An XML document is a representation of a hierarchic data structure, where each element is UTF-8 text. How exactly is this better than *arbitrary* data types related through *arbitrary* true assertions (as per the relational model)? This is a *huge step backwards* in data management. It's even *more* brain dead than 70's hierarchic databases, because of the text requirement.

And you should also read up on XQuery.

Yes, a confusing, navigation-oriented, non-algebraic language. More crap that IT people have to deal with, WITH NO APPARENT BENEFIT!

Note: navigational languages like XPath are a *violation* of the following principle you asserted above: 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.

Having to tell the DBMS *how* to access a particular part of the XML file means you are doing the computer's job. The RM allows you to declare what you want, and the DBMS will return it.

Dumb idea? Far from it.

There may be a use for the extremely limited functionality offered by XML databases. If you deal *only* with text files for instance. But I'd much rather see a *general purpose* relational database that can store *anything*, not just formatted XML text.

Re:XML database

[Anonymous Coward]

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.

Whoever said that was ignorant of the relational model. The RM is a *general* model, for *any* data storage, manipulation, and integrity. That's why it was created! It also says NOTHING about performance. That's an implementation detail (the RM exists so you can think about data management WITHOUT premature optimization or storage issues or syntax or any of that stuff).

The RM lets you specify *arbitrary* types and *arbitrary* assertions about those types, and gives them real-world meaning via *arbitrary* predicates. In other words, if you can use a particular type in a general-purpose programming language, and write a true statement in english about those values, you can represent the data in the RM.

Let's have an example of a data management task that can be handled with a computer, but can't be modeled with the RM. I'm sure Chris Date and other "keeps of the relational model" would be quite interested to hear about it!!

Maybe I'll learn something!

Yes please do. And do it before posting about databases in public forums. I recomend "Database in Depth" by Chris Date on O'Reilly.

Re:XML database

[CrankinOut]

Thank you for your explanatory response. I didn't say that *I* held those opinions, only that a large number of the "then resident" experts in database systems held that opinion. The point I was making was that "conventional wisdom" said that the RM would not be practical because the abstractions lost performance information.

Yes, I know that the relational model is a model. I referred to it as such.

and I have a PhD in computer science in database systems...

and I post under a user name, not anonymously.

Re:XML database

[KMnO4]

Thank you, great post! The XML zombies must be repudiated! See "The Myth of Self-Describing XML" by Eric Browne.

Re:XML database

[19thNervousBreakdown]

lseek(fd, (line - 1) * line_length, SEEK_SET);

It's OK, I miss Sys/36 too.

Re:XML database

[willfe]

Dude. You just totally snarfed most (if not all) of the ideas from Scott Adams' Tell Me Why I'm Stupid experiment. Either I owe you congratulations for the good troll, or condolences for how your brain turned out.

Re:XML database

[TheSpoom]

I never said that XML wasn't useful, just that the hype involved in claiming that they had "native XML" is a little over the top. I know they store it in a tree format, the stress in that sentence was on the "how long could it have taken," because I don't think it would have taken a lot of developer-hours.

So?

[thogard]

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?

[emamousette]

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?

[Anonymous Coward]

1 gig? Major database? BWAHAHAHAHAHAHA!

Excellent

[squoozer]

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

[srpatterson]

Is your copy of Postgres missing the string datatype?

Or do you just need something thats buzzword compliant :P

Re:Excellent

[squoozer]

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

[plopez]

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)

Re:Excellent

[soosterh]

Actually the pricing 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>

Re:Excellent

[Notrace]

Pick your flavour ...

http://gborg.postgresql.org/project/xpsql/projdisp lay.php

or

http://www.throwingbeans.org/tech/postgresql_and_x ml.html

Re:Excellent

[squoozer]

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) but I think there could be money in it. As companies grow they are likely to stick with wht they know. Personally I find postgres to be perfectly good enough. I've only once hit a bug and that had a well documented work around.

Technology Pot Pie

[borkus]

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.

Re:Technology Pot Pie

[Greyfox]

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

[FooAtWFU]

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

[TexVex]

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

[tigersha]

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.

Re:Technology Pot Pie

[metamatic]

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

FYI.

Re:Technology Pot Pie

[digidave]

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

That sounds cheap and efficient.

Re:Technology Pot Pie

[Blakey Rat]

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 sort people by first name (Open Database, a few other places) or last name (Address Book.) (Oh, and no, there's no way to change the sort order.) They could remove the misleadingly-named features that cause data loss, like "Edit Attachment," or at least allow admins to turn it off so we'd onlt get "where did my document go?" three times a week instead of twenty. Ditto with mail folders. Or they could make mail filters and Out Of Office messages actually work, instead of randomly triggering for no reason and staying around long after they're deleted. They could make it easy to change a user's name which, right now, is so difficult that it's usually quicker for us to just create a new user with the new name and copy-and-paste their email over to it.

Guh I hate Notes.

Re:Technology Pot Pie

[cgrayson]

That Register article says they don't have a name for the product yet. Assuming "Viper" is just a code-name, allow me to put forth the obvious:

DB3!

Re:Technology Pot Pie

[WuphonsReach]

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, document storage with ad-hoc), it was very very good. For users who need portable access to documentation, with easy syncrhonization, it makes a lot of sense. (Applications like insurance adjusters, realtors, other service industries that travel to customer sites and don't always have connections back to the home office.)

Unfortunately, there are too many Lotus Notes developers (and users) who think everything needs to be a Lotus Notes database. So you end up with some nasty shoe-horned projects that would've been better off developed either as client-server or web-centric (with a relation database backend).

I have mixed feelings about Notes. It had a lot of strengths, but being forced to use it in odd ways gave me too many support headaches. Very cool capabilities with a nasty and inconsistent user-interface.

Re:Technology Pot Pie

[tigersha]

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 select documents is very, very good, EXCEPT the bloody things won't select all the documents in a category if you click there. I kow it is not standard (standard would be to shift click the docs) but in this case Notes's way is better than the standard. Except for that one extremely irritating quirk.

Notes's way of dealing with document folders is also something that I think a few other programs can emulate, it definitely has something, IF you can train you users to use it and IF they make the delete button remove someting from a folder instead of deleting it (like iTunes playlists, delete a song in the library and its gone, delete it from a folder and it is removed from the folder only). And what the hell is up with F9 to confirm delete??!!

I have to admit having mixed feelings about Notes and about programmers who think it is heaven on earth too. Notes has the same problem as PHP. Some things are quite easy in it and then the people think everything is easy in it, which leads to a nightmare.

Re:Technology Pot Pie

[tigersha]

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.

Re:Technology Pot Pie

[Blakey Rat]

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.

Re:Technology Pot Pie

[Max Webster]

As a former IBMer, I have to say you've perfectly captured
the feelings someone would have working in the DB2 area
and forced to use Lotus Notes for mail and groupware-type
stuff. When someone asks why I left, Notes always comes up
in the conversation.

Re:Technology Pot Pie

[metamatic]

Hey, some people have been screaming for it. Not my place to speculate why.

Re:Technology Pot Pie

[tigersha]

FTI is the Full Text Index which you have to switch on in Notes.

Re:Technology Pot Pie

[Greyfox]

Yeah, every time I get stuck on a contract there I end up thinking "*sigh* back to Notes..." and every time a contract ends out there I'm all like "Hooray! I NEVER have to use Lotus Notes EVER AGAIN!" A joyous feeling that lasts until the next IBM contract.

I am the viper...

[pulse2600]

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

Re:I am the viper...

[Zemplar]

{waving toilet tissue in hands}

"Anyone need a vipe?"

Re:I am the viper...

[Anonymous Coward]

You're not supposed to show your age! Quoting G.I. Joe will only get the old ones out to whip you.

Re:I am the viper...

[CaptainPinko]

Heh, I'm glad I'm not the only one who remembers this.

Late to the party

[cyberjessy]

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.

Re:Late to the party

[kpharmer]

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

Re:Late to the party

[aztracker1]

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 platform that's easier to install and maintain than Oracle is.

It sure is!

[brunes69]

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.

IBM answers MS

[Decker-Mage]

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

[Anonymous Coward]

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

[jsight]

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

[kpharmer]

> 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

[Anonymous Coward]

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.

Re:IBM answers MS

[S.O.B.]

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

[CaymanIslandCarpedie]

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!

Re:IBM answers MS

[kpharmer]

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

hmmm, i wonder how this will interact with everything else?

It's difficult sometimes to explain to people why they might not want to implement fringe features (thinking OORDBMS stuff like typed tables, etc) - various wonderful things just don't support them (online reorgs, whatever). Of course, no vendor ever likes to discuss these issues in a marketing campaign ;-)

Any thoughts of the usefulness of XQuery compared to SQL?

It still sucks

[roman_mir]

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

[Anonymous Coward]

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

Re:It still sucks

[kskuhlman]

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

Re:It still sucks

[ciggieposeur]

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

[kpharmer]

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

Re:It still sucks

[mikaelhg]

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?

Re:It still sucks

[professorfalcon]

>The differences between oracle & db2 for transactional apps are mostly:

And don't forget:

o DB2 has a different locking model that has lock escalation, which causes frequent deadlocks (i.e. on concurrent DDL).

o DB2 does not expose many statistics for tuning in an easy-to-use format like Oracle does (V$ tables). Sure, you can set event monitors, but they are cumbersome, and they don't provide enough information. And where are the timed event (or wait) statistics?

o DB2's Java-based tools are slow and bulky.

o DB2 doesn't expose space usage statistics for objects such as tables and indexes. The documentation literally says to _calculate_ the object size!

Re:It still sucks

[kpharmer]

> o DB2 has a different locking model that has lock escalation, which causes frequent deadlocks (i.e. on concurrent DDL).

Actually, I find that genuine deadlocks are very rare, and are usually resolved by simply getting the apps to use the same table access sequence. Waits are much more common - in which one app has to wait for another to commit its transaction in order to access the same object, and the transaction can die if it has to wait too long. In my experience it's usually a symptom of bad tuning that's easy to fix on all but the busiest app designed specifically for oracle.

> DB2 does not expose many statistics for tuning in an easy-to-use format like Oracle does (V$ tables). Sure, you
> can set event monitors, but they are cumbersome, and they don't provide enough information. And where are the
> timed event (or wait) statistics?

yeah, db2 could use better runtime stats. Personally, I never bother with the event monitors, especially since they're only good for finding the needle in a haystack. Have you tried the snapshot functions & commands? I find them much easier to work with and more valuable.

> o DB2's Java-based tools are slow and bulky.
Yep like oracle, you want a client with 512 mbytes of memory to use them. Even then they're occasionally a pita. There are a few other tools you can get tho - toad (expensive), quest(very expensive), aqt (very cheap), etc. Also, note that you really don't want the 8.1.0 version of the admin client - that was very slow.

> o DB2 doesn't expose space usage statistics for objects such as tables and indexes. The documentation literally
> says to _calculate_ the object size!

don't know about that - by performing runstats you'll have the number of rows, the average row size, the number of pages physically allocated to each table. Now, you could calculate size logically based on row num * row size, or get the exact physical allocation through total pages * page size for any table or index. That isn't bad.

DB2 definitely has a few warts. Many of them are the legacy of supporting various communication protocols or fashionable technologies over the years (typed tables, appc, etc). Others are just the occasional failure to achive consistency in the interface (db2batch vs db2 cli arguments, etc).

Still, the improvements in the last four years have been great:
      - mdc
      - mqt
      - most admin tasks can now be done online
      - etc
administration is now quite easy:
      - add a storage device to a tablespace and db2 automatically, and online rebalanced all your data across all devices
      - various wizards can recommend configuration & tuning settings
      - client tools, though bulky, can generate almost any command you want
      - I've found it easy to train new dbas - without any formal training - just through OTJ and a few months these guys have become fully proficient.

Right now I'm running a mission-critical data warehouse and set of marts on db2. I could fully license the warehouse for $15k total list. The cost for oracle would be $80k. This project is now supporting hundreds of customers, well over a tb of data, 100,000 queries a day on mostly very old hardware. And it was a complete snap to set up - without even a db2 dba at the time. Caveat - I did have plenty of dba & warehousing experience on other databases, not saying no dba required.

But if I used oracle for this project I would have had to spent a lot more time trying to convince people to fund it because of the greater licensing cost and it never would have flown without a dedicated oracle dba from the begining.

Re:It sure is mauve!

[dwandy]

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

Verily I say unto you

[Anonymous Coward]

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

[Anonymous Coward]

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

Usefulness?

[CodeShark]

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?

[plopez]

Am I missing something?

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

Re:Usefulness?

[Anonymous Coward]

Uh oh, new buzz word to look up...

*sigh*

What is ACID compliance? and why is it important?

What the hell?

[Viper Daimao]

I call prior art!

Re:What the hell?

[daeley]

Don't be an asp.

Re:Why waste time and money in DB

[iBod]

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!

SQL support!? Are you sure?

[Anonymous Coward]

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.

Re:Why waste time and money in DB

[slysithesuperspy]

Might as well nationalize Oracle Corporation at the same time!

MSSQL

[sgent]

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

[spectrokid]

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?

Re:MSSQL

[Miniluv]

Uhm, you forgot Sybase as a highly scalable RDBMS.

XML Database, Good or Bad

[awol]

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

[kpharmer]

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

Re:XML Database, Good or Bad

[Anonymous Coward]

So for more agility in your database designs, you endorse LESS normalization? I can't imagine a less normalized databse every being more agile than a properly normalized one. Either I'm missing what you mean by dynamic model, or you don't understand the benefits normalization. You do know one of the main goals of the relational model was to allow agility right?

Re:XML Database, Good or Bad

[kpharmer]

> So for more agility in your database designs, you endorse LESS normalization? I can't imagine a less normalized
> databse every being more agile than a properly normalized one. Either I'm missing what you mean by dynamic
> model, or you don't understand the benefits normalization.

Right - i'm not talking about 'denormalization' - in the way that you would denormalize a modeling to simplify sql and improve performance on a reporting application. I'm talking about not applying that set of database modeling rules at all.

> You do know one of the main goals of the relational model was to allow agility right?

Yep, and it has done that well: relational databases are far more agile than the hierarchical ones that preceded them. But - they aren't agile enough for some problems.

For example, lets say that you have a bicycle-shop-management application that you sell to small shops. You sell it for, what? $5,000 plus 18% annual maintenance. It handles bicycle inventory, sales, some light marketing, etc. Well, one day one of your customers decides to sell books about bicycles. Well, perhaps you've got a generic inventory table that he can describe things in - but if you've got a 3-5NF model - it isn't that generic. There are no columns specific to books in it. And he really can't afford to spend $10-50k on an update to support that.

So, ideally you've got a model in which some attributes of items are kept in key-value pair tables. This isn't wonderful for a lot of reasons - but it does give the application owner the ability to define new kinds of attributes that were unforseen by the dba. And, if done well, he can even define (in the database) rules for when some of these attributes are required, what their domain is, what their type is, what their default is, etc. These "dynamic attributes" would give the user the ability to create whatever new columns they want to describe the entity "book".

Additionally, you could design the model to support the concept of "dynamic entities": in which concepts such as book, bike, helmet, wrench, tire can be logical subtypes of inventory item. Not just identified through a single simple tag - these concepts can be related through many-to-many relationships to one another, to multiple stores, to customers, etc. The relationships between these entities can be dated, prioritized, weighted, and the entities can inherit from multiple parents in this case. Now when the store owner wants to add the concept of book they can *easily* also create overlapping sub-categories below it (mountain biking, road biking, family biking, competitive biking, history, etc) - and then relate these items to other inventory items that share that category. End result - you click on the bike shop's web site and look at a heading called "winter biking" - and see everything remotely related to this concept. And - it was easy to set up, and there's nothing specific to "winter biking" in the structure of the data.

Sort of similar to what the topic maps community is trying to do with XML:
    http://www.topicmaps.org/

Though in my opinion they are only shooting for a subset of what we should be trying to do at this time, and what we can do via relational databases or whatever. Still, with strong db2 support for topic maps that may be the easiest way to go for now.

Re:XML Database, Good or Bad

[johnjaydk]

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 celebrity within the academic environment that is such a nice person.

Re:XML Database, Good or Bad

[awol]

So, ideally you've got a model in which some attributes of items are kept in key-value pair tables. This isn't wonderful for a lot of reasons - but it does give the application owner the ability to define new kinds of attributes that were unforseen by the dba. And, if done well, he can even define (in the database) rules for when some of these attributes are required, what their domain is, what their type is, what their default is, etc. These "dynamic attributes" would give the user the ability to create whatever new columns they want to describe the entity "book".

This is pretty much the model I have in mind when thinking about this issue. What would be cool would be a RDBMS that still allowed me to build high performance indexes on these "key pair" tables. That would be moderately tricky.

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

[tod_miller]

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)

[The_Dixie_Flatline]

Or, 'Operation CORBA'?

Re:Why waste time and money in DB

[TarrySingh]

I was thinking in terms of globalization ;-)

Awesome!

[Bravo_Two_Zero]

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.

DB2 has always been late.

[emil]

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.

Re:DB2 has always been late.

[Mr.Sharpy]

You end up on an AS/400 before you know it, and that is not a nice place to be.

Yes, an extremely secure, increadibly stable platform sporting one of the most modern operating system architectures in the industry running on the latest hardware is definitely not the place to be.

Re:DB2 has always been late.

[emil]

No, it's not, because you are locked into the vendor. Also, AFAIK, the DB2 kernel is only fully instrumented on the mainframe (z-series) platform - if you have severe performance problems, extensive diagnosis can only be done if you move to a z-series system. I'm certain that UDB lacks proper instrumentation, and my documentation says that z-series is the only place where proper performance statistics can be gathered.

I don't like being locked into Oracle either. The security is bad and the sales staff are sharks, but they have the best technology (featureset) hands down. If Oracle wasn't an option, I would look to the many free databases before I'd consider DB2.

Whither XQuery?

[Anonymous Coward]

Wasn't XQuery supposed to replace SQL for searching for XML formatted data in a database? What happened to that. ISTR that IBM used to be hyping it fairly strongly as "coming soon!"

NS, it's a regression to hierarchical DBs

[Urusai]

And why the heck do people think that XML internally is a good idea? XML is little more than a hierarchical interchange format, a superior .csv replacement. You might as well use TCP/IP for local interprocess communication while you're busy adding buzzwords to your implementations in a lame attempt to be hip.

A good example of trendy technology over sanity in this manner is NVidia's firewall software. Rather than provide a nice, tight control interface, they run a freakin' Apache server so they can provide an HTML control interface. Now, their NForce4 HW firewall is supposed to ease the load on the CPU. Installing a full-blown web server (which uses gobs of RAM; WTH, there are lighter HTTP servers than Apache) just to handle the interface kind of severely reduces the presumed benefits, I think, including the security benefits. I can only assume that either 1) they wanted a remotable interface (but who the heck is using an NForce4 mobo with Windows as a dedicated firewall box? You gotta be nuts) or 2) their developers wanted in on the la(t|m)est trends.

FFS, is the whole world insane? Yes, yes it is.

Re:NS, it's a regression to hierarchical DBs

[JulesLt]

How strongly can I agree. But then the same people - but I'd wager few of them are old enough to have worked with hierarchical D/B to understand why it was a complete pain in the neck and relational databases wiped the floor.

It's probably also the fact that developers can easily understand parsing a tree and recursion, but have far more difficulty working with the idea of sets - the temptation to recast all problems into the domain of your own expertise. (I do it myself after 13 years of SQL experience - use server side procedures to do something in a loop that could have been implemented directly in SQL).

Re:NS, it's a regression to hierarchical DBs

[Anonymous Coward]

You'd store XML internally when it's appropriate. For example, semi-structured posts like these here. It's a buzzword and it's reasonable choice, and you're unreasonably bent against XML.

Re:I HATE DB2 Re:It still sucks

[Anonymous Coward]

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

Bleh, that's not a fix, it's a temporary patch. You probably had design or a administration problem. Most db2 developers I know use dynamic sql primarily. Static is only if you're building something that really has to scream.

> Because of it, the failure of DB2, they said you have to use SQLJ
once again, go back to design. DB2 has the most sophisticated optimizer available, if it is unable to figure out your joins you've got a design problem. Well, 99% of the time anyway.

> Then how does IBM make PHP use static SQL?
> They are making a precompiler for PHP?

it doesn't - if you're using perl, php, python, vb, etc - you're using dynamic sql. i haven't bothered with static sql since the c/cobol days.

> I have no idea and all I can say is IBM is stupid.

well, you're at least half-right - you have no idea what you're talking about.

XML Query and XML in databases

[Ankh]

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

Re:Rollback Segments are Good???

[raftpeople]

When IBM finally adds rollback segment to DB2 then I won't be as upset about DB2 being pushed onto my real time projects You seem to be implying that Oracle's implementation of it's roll back mechanism via rollback segments is a good thing????? Don't get me wrong, I like Oracle's concurrency model, but the implementation using roll back segments is far too problematic to consider it a good thing.

Re:Why waste time and money in DB

[TarrySingh]

Liked the chestnut. Agreed Oracle is a screw up company, Sales have had guys like "Genghis Khan" BUT the database is very much a leader.

Re:I HATE DB2 Re:It still sucks

[Anonymous Coward]

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.

Dude, you're on crack. Seriously. I write Java and have been hitting DB2 from Java (j2ee-ish stuff) for years and I have never used anything but JDBC. I've never so much as heard someone mention SQLJ.

Many frameworks such as Hibernate, iBATIS use JDBC. If you are DB2 user, you can't use them.

This is wrong - a complete outright lie. Want some examples ? Here's one :

Using Hibernate to Persist Your Java Objects to IBM DB2 Universal Database

There you go, a nice article from developerworks, an IBM developer site, covering Hibernate and DB2....and they use JDBC, no mention of SQLJ anywhere.

Thanks for coming out, now crawl back under your rock. Someone with mod points please troll the parent - I don't have any right now.

Re:I HATE DB2 Re:It still sucks

[Anonymous Coward]

>I've never so much as heard someone mention SQLJ.

Here
IBM recommends you to use SQLJ they believe it's better than JDBC

You have to know if you want to control your access path, there's only way to do it is just using static sql. And if you don't use static sql, DB2 will make big miss and it won't use any index to search and it consumes huge time.
I don't care if you don't believe this.
Read some red books.

Re:Why waste time and money in DB

[Anonymous Coward]

Hey, can Oracle yet tell the difference between a NULL value and an empty string (as required by the SQL spec)?

Mod up

[metalhed77]

I wish I had mod points to mod you up.

10gr2 can store it native

[Stu Charlton]

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)

http://download-west.oracle.com/docs/cd/B14117_01/ appdev.101/b10790/xdb01int.htm#sthref46

Re:10gr2 can store it native

[zootm]

Cheers, I'll maybe look into that if I get the chance. :)

Re:I HATE DB2 Re:It still sucks

[Anonymous Coward]

> You have to know if you want to control your access path, there's only way to do it is just using static sql. And if you
> don't use static sql, DB2 will make big miss and it won't use any index to search and it consumes huge time.

Dude, you're thick. This article merely shows that some people at ibm recommend sqlj for the fastest possible performance and a few other reasons. So what?

And so you're bummed that static sql is faster than dynamic? Why? You should be happy you've got the option. If you don't like it just don't use it. You don't have to you know. Most people don't.

And the thing about relational databases is that you *don't* want to control your access paths. That kind of thinking went away with their hierarchical predecessors. Plus, static sql doesn't really allow you to control your access paths anyway - it just ensures that things don't change until your next rebind. Big deal. They shouldn't change for dynamic sql either typically (unless tables grow substantially in which case they should).

Here's the thing - you clearly don't understand:
    - databases
    - db2
    - db2 apis
You can blame db2 all you want. But you need some serious coaching, mentoring, education, training or something.

Re:I HATE DB2 Re:It still sucks

[Anonymous Coward]

>You don't have to you know. Most people don't.

NO.
You have to use SQLJ because there will be a problem when you don't use SQLJ and static SQL if you use DB2.
The problem is, there's possibility of perfomance problem always with dynamic SQL. And DBA feels fears and forced us to use SQLJ.
That's the problem.

I don't want to use SQLJ, but still I have to use it.
*You* have to study about DB2 access path problem and think why IBM still push SQLJ. It's not a option. You have to do it or you will have a problem someday.

Re:Why waste time and money in DB

[iBod]

>>BUT the database is very much a leader.

A leader in sales revenues perhaps.

It's not a leader for any technological or performance advantage, that's for sure.

I guess it's because it's ubiquitous in the industry, because of all those 'Genghis Khan' salesmen (thus the old chestnut).

Oracle is not fast enough for VLDBs (see CCA's Model 204 for ultimate speed) and is not particularly feature-rich (see IBM's DB2 for all-round features).

Oracle muddles along in the mid/nearly-large DBMS mainstream, which I guess is where most sales are, so it's well positioned in it's market I guess - but a technological/performance leader? No way.