Simplify Apps Using XML With PHP and DB2

An anonymous reader writes "IBM DeveloperWorks has an article from a little while back that takes a look at the impact of schema evolution on the application. The narrative walks the reader through a usage scenario to illustrate the ease of setting up a PHP environment and integrating DB2 native XML functionality with PHP applications including web services written in PHP and XQuery."

Comments

Re:IBM slashdotted?

[BrynM]

Maybe it got pulled for some reason or something else happened... When I clicked it routed the request to www-128.ibm.com and all of the pictures loaded cleanly for Google's cached copy, so I'm betting they have a little capacity ready to go. After a minute of looking at Google's link to the real page, the problem seems to be the "?ca=dgr-lnxw01DB2xmlPHP" at the end of the posted link. Here's a workig link for the IBM copy. Here's the google cache if you want it too.

So...

[Crayon Kid]

...they implemented "XML databases" by treating XML as BLOB's and adding XML parsing and updating capabilities to SQL. Hybrid indeed. I'd be rather tempted to call it a bastardization of both contepts (relational and XML).

The thought springs to mind that PHP, as it happens, would be uniquely suited to working with the hypotethical XML databases, due to it's rather particular concept of arrays. As many of us undoubtely know, a PHP array can be used to contain a tree of arbitrary shape and size, and with nodes of arbitrary types. A native, 1-on-1 match to an XML tree.

A couple of years ago I tried looking for a native XML database. The solutions were either very pricey, or very slow, or both. Nothing to keep up to RDBMS. The whole "XMLDBMS" hype died over eventually, as you may recall. OR hasn't it? Are such hybrid solutions all that's left of the concept? It was a great idea.

Re:summary of article

[eric2hill]

Wow, some actual bullet points. From an AC no less. And just one personal attack. I'm impressed.

• algebraic syntax: SQL completely hides the underlying algebra. Can you imagine doing math without math operators? How you can you do relational algebra without relational operators?

  While SQL does hide *some* of the underlying algebra, it exposes many of the operations such as UNION, INTERSECTion, subtraction (MINUS in Oracle), etc. Set division is probably the biggest missing keyword in SQL, but can be accomplished through a combination of SQL terms (JOIN ... WHERE ...), so in that sense, SQL fits the algebraic model.

• non-table-oriented storage: why do SQL databases insist on physically storing data grouped in tables? This makes joins expensive. It should be just as efficient to join columns from 20 tables as it is to use one table with 20 attributes. The designers of SQL clearly didn't understand the RM either.

  Tables were born out of the spreadsheet concepts where you have rows and columns of data. Tables do fit the relational model in that you have groups of attributes (columns) in a collection (rows). Tables are simply an easy concept for people to grasp and they work. If you don't like tables, you can use other techniques to store data. Look at Oracle's object extensions. Define an object then store those objects and query them. It's very natural to use and doesn't preclude either the relational model nor SQL syntax.

  Secondly, joins are not expensive when using indices properly. As a matter of fact, bimapped indices can perform joins (or unions or intersections etc) with *very* little CPU or disk overhead. Indices are a technology to keep speed up when performing operations on large data sets, something the "relational model" doesn't specify. You need to realize that the relational model is really a definition of "what" needs to be accomplished, not the "how" it gets accomplished.

• updateable views: the RM says base relations and derived relations (views) should be indistinguishable. Most SQL implementations don't allow for arbitrarily update-able views. How do you abstract or encapsulate in your database? How do you support two different apps that require two different schemas or column names? You can't, easily. Imagine a programming language without functions/subroutines/methods. Pretty useless, right?

  Just because most SQL implementations don't allow for updateable views doesn't mean the SQL standard is flawed. Oracle provides full support for updatable views where it can relate the update to a single row, and you can override that behavior when the update is ambiguous with a set of rules to process the update. SQL Server has the same features I believe.

• user-defined types: isn't it strange that programmers use something called an "ORM" that constantly assembles and disassembles composite types? Why can't I store the composite type right in the attribute, like the RM says I should?

  You absolutely can store composite types right in the attribute. There's nothing in the majority of SQL engines that stop you from doing that. The reason for the disassembly of composite types is twofold; First, you'll get better speed when doing *other* things with the data if the data is broken down into its simplest form, and Second, it takes less room on disk when storing properly normalized data than just BLOBing the whole mess to disk.

The Relational Model is this ideal that means different things to different people and there are some solid database engines that implement many of the concepts of the relational model, but saying that there's no database vendor out there that supports the relational model in any way is pure FUD.

I will have to check out Dataphor. It seems like a good idea, but I suspect it's plagued by many of the problems that have been solved in the RDBMS world such as scalability, recoverability, etc. Basically all th