Simplify Apps Using XML With PHP and DB2 26
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."
Re:IBM slashdotted? (Score:4, Informative)
So... (Score:5, Informative)
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:So... (Score:2)
When you put it that, way, yes, it makes more sense.
I was just enthused by the idea of a database engine that uses XQuery [b]instead[/b] of SQL, not just for a particular type of field. You can infer the implications.
One of them is that the result sets would be variable trees, which could e
Re:So... (Score:4, Insightful)
The problem lies not in our parsers, but in our application domains -- and ourselves.
It is trivial to represent flat data structures (or sets of tuples if you prefer) using XML. It isn't hard at all to represent hierarchical or even irregularly structured data using SQL. What's hard is doing any useful processing of data after you've chosen a format whose associated tools don't readily do what you need to do with that data.
It's hard to tighten nuts with a hammer or drive nails with a wrench.
A hybrid tool certainly has it's potential uses in an application that crosses domain boundaries. Such applications are inherently hard in any case; it's not as simple as choosing a wrench or a hammer, it takes expereince. But this is greatly complicated engineers who will invariably choose the wrong tool (often XML these days), who given a hybrid hammer/wrench tool will insist on always hitting things with the wrench.
To be sure there are borderline cases, but you need to solve the problem with the minimal number of parts.
Re:So... (Score:2)
It wasn't so much a great idea as an exceedingly obvious one which no-one has managed to pick up on.
In my humble opinion, XML is essentially crippled without some kind of query/search/XML-Database f
Re:So... (Score:1)
And rightly so, because it's crap. Since XML has no regular structure, any XQuery involves a linear scan. Unless some sound theory behind XQuery is discovered and a way to index XML documents, XQuery is useless.
Berkeley DB XML claims to index XML documents. I tested it on a large document. A trivial query took a GB of memory without returning anything but an error. What's the point of this "technology"? It should have been giv
Re:So... (Score:2)
Re:So... (Score:2)
Indeed this is trivial to acheive using PHP's XML functions (expat, not SimpleXML). However, since you have to parse the entire XML file in a linear manner anyway
Re:So... (Score:2)
Welcome to post-relational, multi-dimensional databases! The wave of the future! Purchase Caché today!
[Caché is the latest in a long line of M/Mumps 'glo
Re:summary of article (Score:4, Interesting)
The database admins might argue that it's a moot point, given that relational databases are fairly close to the relational model. The concepts are at any rate, related to one another. Not quite isomorphic, but close enough for most purposes.
In fact, it could be argued that to fully implement the relational model would intoduce too much complexity to the fairly simple SQL sysetm, which has served many a programmer well over the years.
Re:summary of article (Score:2)
Yet another post on this same topic by a troll.
What the fuck do you want implemented that todays RDBMS don't do? Give me a bulleted list of features that you want added or changed to existing implementations.
I've seen so much bitching and whining that "nobody makes a true relational database", but nobody states what the difference is between an existing database and a "true" database
Re:summary of article (Score:4, Informative)
Wow, some actual bullet points. From an AC no less. And just one personal attack. I'm impressed.
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.
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.
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.
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
XML is not the answer. It's not even the question. (Score:4, Interesting)
Granted, he was talking about Python, not PHP... but still...
c'mon (Score:1, Flamebait)
BOGUS (Score:1)
From the article:
Bogometer Pegged!
If they had made the opposite assumption (that the business data was not in XML format, a much more common scenario), then, the added complexity of translating the data to an XML format would have made the non-DB2 approach look cleaner and more reasonable.
Wow (Score:1)
Funny... (Score:3, Funny)