SQL, XML, and the Relational Database Model 453
Kardamon writes "In an article on DBAzine, Fabian Pascal writes that SQL is not a good representation of the relational model, and is afraid the situation will get worse with XML and XQUERY. An overview of some of the reactions on the positions Pascal and also C.J. Date take on this issue is given in this article over at SearchDatabase.com by Sara Cushman."
Isn't XML semi-object oriented? (Score:2, Insightful)
Re:Isn't XML semi-object oriented? (Score:5, Informative)
XML is a file format, it has nothing to do with objects, no more than HTML does, which is not at all.
However to counter your claim that XML is hard to represent in a relational database. Uhm. No, it's not.
XML consists (simplifying) of elements and attributes, elements may be nested.
A generic mapping to a relational database is that elements correspond to the entity tables, attributes correspond to columns in those tables, and the nesting of elements is modelled as a foreign key in the child entity records.
Whats so hard?
Re:Isn't XML semi-object oriented? (Score:4, Informative)
The "arbitrary XML" part. You must have existing mappings set up to process the XML. New forms of XML thus require a great deal of work on the part of the DB developer.
XML databases such as Xindice [apache.org] OTOH, allow you to create a table and insert XML in whatever format you chose. XPATH queries take a bit of getting used to, but you can query on tags, attributes, CDATA, or whatever else you chose at whatever level in the XML hierarchy you choose. Thus I can query for the list of addresses for all records that have a firstname attribute that is LIKE "Bob". Or I can dive down to the individual address level and query for all records that have an address of "Drury Lane" (important for tracking down the Muffin Man when you need a giant gingerbread cookie).
It's not like you can't do this stuff with SQL databases, it's simply a different method of accomplishing the task. Depending on the data you're working with, an XML database may very well be a more efficient method of storage and queries.
Re:Isn't XML semi-object oriented? (Score:3, Interesting)
> used to, but you can query on
Right on. Another nice thing about XPath is that it can be mapped onto other hierarchical structures. For example, the Java static analysis utility PMD uses XPath to query Java source code for problems. This XPath query checks for empty if statements:
Good stuff; more XPath rules are here [sourceforge.net]. Props to the Jaxen [sourceforge.net] and SaxPath [sourceforge.net] guys for their fine work!
Re:Isn't XML semi-object oriented? (Score:3, Interesting)
Sure, this is a nice syntax to describe one-off problem. Though for a database you'd hope that it is done once to transform it to something useful instead of 100 times per second.
Re:Isn't XML semi-object oriented? (Score:3, Interesting)
In fact, that's exactly what a good XML database will do. By indexing all the accessible fields, it's able to provide fast access to database wide queries like the one you suggested. Of course, these indexes do come at a cost of disk space and memory, so not everything is quite rosy in Denmark.
Re:Isn't XML semi-object oriented? (Score:4, Insightful)
In other words, it pretends to be a ralational database.
What is it with people lately? Everyone seems to want a piece of the trolling action?
For your information, a set of indexes no more makes a relational database than being in a garage makes you a car. Index data structures are an inherent way to improve the performance of all databases, whether they be ISAM, Hiearchical, Object, or Relational.
What makes a relational database relational is the way that the data is loosely intertwined to develop logical connections. In theory, these connections can complete various thoughts about a piece of data. ISAM files are merely indexed data, while Hierarchical (including XML) databases contain a complete "data packet" covering a particular concept. (e.g. Customer contains name, a set of addresses, and a set of phone numbers.)
Re:Isn't XML semi-object oriented? (Score:3, Interesting)
Um... I haven't read this article yet, but to respond to your comment.. um, no, not really. Here's a trivial possible setup to describe an arbitrary xml tree:
Table tagname: int tagname_id, varchar name
Table attrname: int attrname_id, varchar name
Table tag: int tag_id, tagname_id tagname, tag_id parent
Table attr: attrname_id attrname, varcha
Re:Isn't XML semi-object oriented? (Score:4, Insightful)
As I said before, you can do many of the same things with an SQL database as you can with an XML database. That's not the point. The point is working with the data in a form that is natural to it and will provide the best results.
Re:Isn't XML semi-object oriented? (Score:3, Informative)
I've been happily using it on version 8. The connect_by_root & sys_connect or whatever it is may well be introduced in 10g. Certainly I could have killed for the ORDER SIBLINGS BY clause in 8 but it's only available in 9i+.
Re:Isn't XML semi-object oriented? (Score:5, Insightful)
Re:Isn't XML semi-object oriented? (Score:3, Informative)
This is completely false. If you had RTFA, it is mentioned that the relational model can represent hierarchies (and thus XML) just fine. It is SQL that is deficient for this purpose.
Also, it makes no sense to call XML "object-oriented," which is a programming language term[semi-OO? LOL]. XML is a syntactic hierarchy that can be used to represent "object
Re:Isn't XML semi-object oriented? (Score:5, Interesting)
Generic XML, sure, but you can always layout your XML in a relational style, like this:
<root>
<Table1>
<Table1Row Table1RowID="1"/>
<Table1Row Table1RowID="2"/>
</Table1>
<Table2>
<Table2Row Table2RowID="1" Table1RowID="1"/>
<Table2Row Table2RowID="2" Table1RowID="1"/>
</Table1>
</root>
Join support would be nice for simple jobs, but this works really well for more complicated jobs in XSLT. You can use a for-each on "/root/Table2/Table2Row", calling a template and drill down to "/root/Table1/Table1Row[@Table1RowID='$Table1ID'] within the template. This lets you use whatever hierarchy you want, rather than being stuck with the one hierarchy the original designer chose. Just like real relational databases.
Re:Isn't XML semi-object oriented? (Score:5, Informative)
It sounds like you're kidding (or being sarcastic), and I'm not going to debug it (I'd need data, anyway.), but probably something like this:
<xsl:template match="/root/Employees/Employee[@Salary>100000
<xsl:variable name="EmployeeID" select="@EmployeeID"
<xsl:variable name="NumReports" select="count(/root/Employees/Employee[@ManagerID = $EmployeeID])"
<!--
XSLT sucks with dates, no matter what your data is arranged like. Storing dates as YYYYMMDD does
at least allow for comparisons. Also, there is no facility that I know of to retrieve the current
date, so I'm going to hard-code that.
-->
<xsl:variable name="RecentTravel" select="boolean(/root/Trips/Trip[@EmployeeID = $EmployeeID and @Date>=20030628 ])"
<xsl:if test="$RecentTravel and ($NumReports>20)" >
<xsl:variable name="ManagerID" select="@ManagerID"
<xsl:text>
Name: <xsl:value-of select="@Name"
Manager Name: <xsl:value-of select="/root/Employees/Employee[@EmployeeID = $ManagerID]/@Name"
</xsl:text>
</xsl:if>
</xsl:template>
And this approach seems to perform just fine in MSXSL, which I believe is DOM-based. It might give a SAX-based engine problems, because it jumps around so much.
Lest I give a false impression, I'm not suggesting that this sort of XML replace relational databases. The point is that a roughly relational layout is still a good approach, even when you need to be working in XML.
Re:Isn't XML semi-object oriented? (Score:5, Insightful)
This quote needs to be placed toward the beginning of the Grand Encyclopedia of Intellectual Arrogance. Let's see, you have flat tables with a defined primary key and you form relations between these flat tables.
I do agree that SQL is not the best possible query language, but it succeeds where the other languages fail, it is easy for people to grasp and manipulate. Likewise, HTML has many faults. Plain HTML is still the preferred choice of most web designers because it is easy to learn and write.
Personally, I think the primary intellectual impulse is to add convolution to simple processes. There will never be an end to the stream of blither about how nulls cannot exist, and anyone who simply uses an sequence counter as a primary key is the devil incarnate. HTML and SQL have two things that almost all the stuff coming from arrogant snits like this author lack. They were designed by people who were actually doing stuff.
This quote needs a position in the library of intellectual arrogance as well:
A snit crassly dismisses several millenia of literature because it is unstructured.
Quite frankly, meaning and structure are independent of each other. It is possible to find meaning in things with radically different structures. It is true that there is a correlation between structure and the ability to communicate meaning, but a healthy mind can find meanings in things that have not been normalized.
Likewise, you can have meaningless garbage in relational databases. A case in point is the large number of fake web sites that do things like join the FIPS database to product names so that they can have millions of pages that show up in search engines. Likewise, we see academician filling volume after volume of publications with meaningless tripe.
Re:Isn't XML semi-object oriented? (Score:3, Insightful)
He was not talking about 'data for human consumption', but rather 'data for machine consumption'. As far as a machine is concerned, all literature carries no information, because a machine cannot extrapolate meaning from it like humans can.
Re:Isn't XML semi-object oriented? (Score:3, Interesting)
And yes, the relational model is indeed *much* more than just flat tables with keyed relationships. I thought this upon my first encouters with the relational model, but after actually studying the concepts, I realized that there is in fact something much deeper going on, and that it has a conceptual integrity that I only wish cou
Re:Isn't XML semi-object oriented? (Score:3, Informative)
"NULLS are bad." quote (Score:5, Informative)
Date/Darwin/Pascal propose that you codify what you don't know (so to speak). Read their proposed solution here:
http://www.hughdarwen.freeola.com/TheThirdManifes
And yes, XML DBMS are a throwback to IBM IMS and other hierarchical DBMS products. Anyone who has ever used a hierarchical DBMS will tell you that there are some pretty non-trivial problems that you cannot work around due to their hierarchical data model, yet XML DBMS proponents propose we go back to that old, inflexible system!
Re:"NULLS are bad." quote (Score:5, Interesting)
Basically what I take from this is that the table (e.g. SELECT * FROM foo) is simply a convenient logical representation of a stored relation. That is to say, foo can be implemented by the DBMS as a linked list, a tree, any data structure. The problem is that current SQL DBMS products do NOT do this and so we have the associated performance problems with normalized schemas. If the DBMS was truly a RDBMS then it could optimize the physical storage to improve performance.
The question is not "Are current SQL systems providing value" because certainly they are. They overthrew the hierarchic DBMS products for good reason - they were better. The real question is "Are the current SQL systems providing all the value they can". One can simply look at the wide array of DBMS offshoot products like XML DBMS, so-called "Multivalued DBMS" etc. to know that there are significant limitations of SQL products - ones which Date/Pascal/Darwin stress are not limitations of the Relational Model but merely these SQL products. To put words in their mouth, but I don't think they'd disagree at my summation, they'd suggest that if someone were to implement a Truly Relational Database Management System that these other products would quickly become obsolete.
Re:"NULLS are bad." quote (Score:3, Insightful)
True. However, this encoding is usually very inconvenient (consider representing an HTML document or a structured piece of literature in this manner).
Besides this, nested structures are at least as logical as flat structures (I continue to call them flat because they
Re:"NULLS are bad." quote (Score:5, Insightful)
I read this and pretty much gave up getting anything of value out of this article -- I hadn't understood much that went before it, though my distrust of all things XML had led me to believe this guy might know what he's talking about.
If you removed NULLs from relational database design, people would reinvent them (poorly) -- probably by using IDs of -1 or 0, or IDs to a special magic "null" row, which I suspect is what he's talking about by "it can be handled relationally." To suggest that missing or inapplicable values are not part of "the real world" is so wrong it's... well... wrong. Anyone who's actually done database work (or programming work, for that matter) knows this.
Re:"NULLS are bad." quote (Score:3, Insightful)
I understand the argument (NULL indicates no data--so you can't claim it's equal to anything). Academic bullshit. Anyone who's maintained code using SQL NULL semantics will agree. If you really want to claim that NULL is so much 'not a value' that you can't compare it to
Re:"NULLS are bad." quote (Score:3, Insightful)
Re:"NULLS are bad." quote (Score:3, Insightful)
1. the only situation I can think of where you are comparing two values, where neither is a literal, is when you are joining on a pair of columns
2. if one of the values *is* a literal, there is no reason not to write "IS NULL" instead of "=NULL"
3. if you *are* joining on a pair of columns, letting "NULL=NULL" would not make any sense (you would get the cartesian product of all rows from both t
You Are Missing the point of NULLs entirly (Score:5, Insightful)
select part number, sum(quantity shiped), avg(quantity shipped)
Group By Part Number;
This works with NULLs in the column for quantity shipped on parts which have not yet been shipped. If you just use zero for "no shipment" then your average number will have no real value for answering questions like "how much do we spend shipping these parts, on average?" etc.
If you wan't to throw an exception you can throw the execption or not in your program. In that case you fetch the individual values and do the math yourself and the "that's not a number" that is caused by the null gives you the chance to throw your exception.
But since, in aggregate operations, your program isn't even interractin with the data yet, where would such an exception go?
What would the SQL syntax be communicating a list of results PLUS a list of exceptions to your program? Which order would things be processed in?
Your boolean analogy is also flawed. "You have stopped beating your wife?" is not a yes-or-no question because it carries a predicate around with it that you may not fulfill for serveral reasions (not married; you are hetrosexual female, so you don't have a "wife", you have never beaten your wife so you can't "stop" doing it; etc). There are a surprisingly large number of "real data" that nature. For those of you who have trouble abstracting this, the "real comparason matrix" is "True, False, and Not Applicable". NILL buys you "Not Applicable" so very cheaply.
In poin of fact, people who don't like NULL, usually because they don't understand its purpose and use, make a hell of a lot of work for themselves.
My current employer has a large database of test values that grows by huge numbers of elements each day. The programmer "didn't understand" NULLs (ro RDBMS' for that matter) and has "-" in fields that should be NULL.
Consequently we cannot aggregate. All of our client applications end up haveing to bulk-fetch whole table ranges and run through elaborate statistical routines full of conditionals; or do separate fetches with "field != '-'" in the where clause and run a concordance operation in ram after the repeated bulk fetches.
This costs bocup time and degrades the quality of the product.
You call "academic bullshit", I suspect you have never had to work the really large or significant data sets. I suspect that you don't ever ask the server-side to aggregate for you. And I suspect you have never worked time-critical transactions across a "slow" link.
You can't have. You think of "NULL" in terms of equality.
I will give you the "syntatic" point that "Where X = NULL" ought to be unversal. But, for instance, the cartesian nightmare of having "NULL == NULL" in a join is beyond idiotic.
The problems of preemptive data typing (Score:4, Insightful)
In the world of self taught dabblers, NULL is not well enough understood to be expected to do anything more than cause the kind of problems you alude to with the likes of '-' to (partially) imply what NULL should be used for.
SQL has to coexist with other components where an empty string and a numeric zero are assumed null and treated accordingly, the quantity shipped example you give being just as easy to understand and implement with zero meaning not shipped as with a separate null (just add "where quanity shipped > 0").
There are also several possible reasons for a data value to be left NULL or undef, not all of which are mutually exclusive. Is it "not yet", "not known" or "not applicable"? In the real world we sometimes need to pair a status enum and a (numeric or string) value column to properly represent a single logical datum which needs to sometimes take state values not sensibly representable by numbers or strings.
We used to use a string of 9s in a numeric key field to represent end of data and even today Perl's DBI interface uses the 0E0 kludge to represent a "true" zero.
Re:You Are Missing the point of NULLs entirly (Score:3, Interesting)
The iterative join needed to then needed to print 10,000 invoices of average-of 20 parts per invoice gets too expensive to be reasonable.
It can be done, but it becomes anti-helpful.
Remember, normalization can go too far. By splitting the table you have now doubled your storage requiremet and multiplied the training, implementation, and execution costs since every operator (person or statement) and ad-hoc-qu
NULLs and Normalization (Score:3, Informative)
No, they are not, but the way to rectify them is a bit extreme. Keep in mind that -- as Date says again and again -- there is a difference between the logical model and the physical model. I'll summarize the example he used: a EMP_SALARY table.
Let's start simple:
[Sorry, ecode doesn't seem to want to do vertical alignment.]
Now, what do those
Re:NULLs and Normalization (Score:3, Insightful)
Exactly! I've always been in the position of needing to get stuff done, and that has meant focusing on implementation at some point. While some people get all weird with NULL values, I simply look at it as a workable solution.
I would never fully normalize to the point above, but
Re:"NULLS are bad." quote (Score:3, Insightful)
Thanks, makes sense.
However, the required complexity required to handle "the real need of supporting full value domains" has to be sufficient to handle all possible reasons and scenarios where you do not have a simple value. You might get close with a Lisp back-end, but this is heading too much like needing a supercomputer to hand one number in an el-cheapo caculator.
Nulls are a hack. A nice simple hack. It
Re:"NULLS are bad." quote (Score:3, Insightful)
Well, I read it and essentially what they're saying is that instead of having a single NULL that means "we don't have the info and we don't know why", they recommend having lots of single column tables pointing at the missing values, one table for each reason/excuse. So instead of having NULLs in the salary field, you've got tables that explain "No salary because the guy is on commision", "No
Re:"NULLS are bad." quote (Score:3, Informative)
'scuse my ignorance but... (Score:5, Interesting)
Re:'scuse my ignorance but... (Score:5, Funny)
Evidence of this is in the hundreds of companies who are completely unable to maintain a database of any significant size despite vendor claims to the contrary. Also, note the thousands of websites which routinely fail due to random database problems. It appears that all SQL products are sad implementations of a horrible standard which simply does not cut it
(the above is intended entire as sarcasm)
Re:'scuse my ignorance but... (Score:3, Funny)
Whew...
Re:'scuse my ignorance but... (Score:5, Insightful)
Re:'scuse my ignorance but... (Score:3, Insightful)
Every SQL dialect has a special, unique way of getting the value in this field. Many (not all) things in SQL can be written to be compatible with virtually every database (if you are very very careful) except this one important thing. I know you can requery the database with all the fields or
Re:'scuse my ignorance but... (Score:3, Interesting)
With "modified preorder tree traversal" you can do the whole recursive query, whether up or down, in one non-recursive SQL statement. Very neat, but it is a pain to implement and you better be careful about the atomicity of updates. So far I have not found a way to avoi
Re:'scuse my ignorance but... (Score:5, Insightful)
I'm not sufficiently versed in database theory to understand the technical side, but SQL certainly does feel to me like a non-optimal solution.
Re:'scuse my ignorance but... (Score:3, Informative)
That's why sequences (as implemented by PostgreSQL and Oracle) are handy. Simply create a sequence, and call NEXTVAL(sequence_name) to get the identity of the next record. It isn't an autoincrementer (but can be used as one with default values), and you get the advantage of knowing what ID you will use before your insert - very handy for inserting a lot of related data at once. You can also do tricks like having sequences with different increment numbers
Re:'scuse my ignorance but... (Score:5, Insightful)
Wouldn't call it a problem, but there just seems to be something about it that drives all the Oo fanboys up the wall - maybe it's the fact that they can't make nice UML diagrams of a query or something.
There nothing wrong with SQL and RDBMS - they've been around for years and they'll be around for years to come. I have this argument each and every day at work with people who seem to think that the solution to (hypothetical) "database bottlenecks" is to bury everything in a quarter of a million lines of EJB code and invest a king's ransom in application server licenses to run it on. Don't get me wrong: i've seen some real horrorshow coding with SQL mixed into code, but a bad coder will produce bad code in any language. Until then, SQL works. What more can you say?
Re:'scuse my ignorance but... (Score:5, Insightful)
Yeah, I know what you mean. These kids can't wrap their tiny minds around the following concepts:
Whenever I see a project gone horribly wrong, and the language is C++ or Java, the problem usually is the system architect didn't grok the above statements. They should be tattooed onto the forehead of every OO programmer, so when they're "pair programming" they can read it off each other.
solution to (hypothetical) "database bottlenecks" is to bury everything in a quarter of a million lines of EJB code
I get that too - then I show 'em the logs that show the database processor is mostly idle as it waits for their application to either request more data or finish working on what it's got!
Re:'scuse my ignorance but... (Score:5, Funny)
Here's one that'll make you howl: "sorting is a presentation-tier concern"
Re:'scuse my ignorance but... (Score:3, Interesting)
Yes, it's more efficiently done server-side. But a relational database server could, academically, be a full-blown RDBMS and not have any sorting abilities whatsoever.
Re:'scuse my ignorance but... (Score:4, Insightful)
Largely it is. If the user hits a table header to sort on the selected row, are we are supposed go back to the database and do a different 'order by'?... I dont think so!
If the sort is required purely to provide the user with a list in 'alphabetical' order then sorting in the presentation tier tends to be smarter because it reduces the 'bug-space'. That data generally passes through several levels of indirection, at any time someone may decide to replace an ordered collection with an unordered one and by the time it reaches the screen... it all out of sequence. Also, its very possible that while the data needs to be sorted to give users that 'fuzzy feeling' the same API can be used to provide a SOAP/XML-RPC/CORBA interface that doesnt require sorting (or rather, let the consumer decide). Why do this, fairly expensive, operation on a tier that doesnt always require that it is done?
If sorting is required in the middle-tier it is usually due to some search algorithm or something. In this case, I prefer to put the sort with the search so that it is clear. Where I have worked with pure SQL (tend to use ORM tools now) I like to put the SQL in a seperate repository that the DBA's can tweak without recompliation. That 'order by' gets dropped pretty quick when the PHB is complaining about DB performance... and WHOOPS... really weird bug in the search code.
So it seems to me, that when you factor in the real world issues around using the database as a sorting tool.... its not quite so 'howl-worthy'.
Re:'scuse my ignorance but... (Score:3, Interesting)
Then think again. It's far from a black and white question. If data transfer between persistence and presentation tier isn't costly, you're better off passing the sort to the database. It may have the data already ordered, either because the a similar query or subquery is cached, or because the database has an index on the sorted colum
Re:'scuse my ignorance but... (Score:3, Interesting)
Efficient sorting algorithms are hardly a closely guarded secret, it is possible to implement the exact same 'optimized' algoritm in any of the tiers. With this in mind, the performance costs of the two sorts cancels and you are left with the additional cost of the SQL parser. So assuming the programmer is capable of either A) writing an efficient sort or B) using the efficient sorts provided in the libraries that are supplied with most mainstre
Re:'scuse my ignorance but... (Score:3, Interesting)
Yeah, well when you have to sort String values using oddball locale-specific methods it sure the heck is.
Re:'scuse my ignorance but... (Score:3, Interesting)
Have you run test to confirm that this is false? As part of a project to improve the performance of an app that I developed at work, a colleague and I rewrote several key select statements in different manners, and found the select statements using joins were the fastest by far (in a very large table). We think that the DBA team has the database tuned in such a way to cause this, but I hav
Re:'scuse my ignorance but... (Score:3, Interesting)
What drives me nuts aobut the DB fanboys is that they have to use DB for everything. For example, I maintain an embedded system where some nitwit ex-web-developer decided to implement the process table with MySQL. Huh?
DB is suitable when you have massive amounts of uniform data. OO is suitable when you have heterogenous structured data. Often these two areas o
An attempt at a better solution. (Score:5, Interesting)
That SQL is mostly a kludge?
Let me restructure that...
The experts who know what the heck the relational model is and is not argue that the language we use to query a specific type of relational-like database, that they call the SQL databases, the SQL language, has unsufficient representation power to represent the whole model, and hence can't be used to get the whole power of the model.
That's certainly interesting, and leaves us to ponder two things:
1) a) Just how much more power could we get? b) And at what cost?
2) What about alternatives, can we get that same power elsewhere, cheaper?
1)a) is beyond my mere predicate logic skills at this time.
1)b) The cost of a model for data storage, representation and management is directly linked to it's adaptability to the data you represent. The article mentions a lot of errors with NULLs(I remember thinking, while reading the article: a NULL was an attempt by the language developers to simulate an interrupt in a language that doesn't have any, this is of course, an oversimplification on my part, but considering stored procedures and triggers[SQL's own exceptions] weren't around yet, they sound like a good basis for further research.) There are a lot of other hidden "costs" for people who use a relational tool for not-quite-so-relational data, but that's not part of the cost of a relational language, per se.
2) Brings up a few notions: there are the types of databases relational databases replaced, like network databases, and there are attempted replacements, like object databases. There are also further possibilities that I will explore deeper later. Object databases can certainly be interesting, in the sense that by bundling data with code, you can have data that can handle itself, in the very basic sense that we humans apply it to ourselves. The problem is that we tend to have a very fuzzy, real-world view of such data, and can't work with it that easily(we are using computers to make data easier to work with, so if we had software that could handle real-world data complexity outside of our brains, we wouldn't be having this discussion). Object data is certainly very adept with data that has some broad commonalities, re-usable behaviours, and follows set-rules. We can call those business rules for now. Those business rules imply that a certain subset of "The Universe" interests us more than the rest, and follows predictable commonalities, making our mental models a lot less complex. On the other hand, object methodology is not always well understood, and the documentation and models it generates sometimes dwarf some production systems implemented to solve the same problems.
Now, at the beginning, Relational Systems were data-handling "toolkits" set to handle specific subsets of data, who also followed business rules.
That's interesting to my purpose, simply because I can envision, at this time(some vendors have similar concepts, but don't formalize them in any way), a new set of "toolkits" where the relational model is only one of many "toolsets" available.
Indeed, what is probably the most used sql-based server available(MySQL) has been lacking true relational functionality for most of its life, yet that doesn't make the tool less useful for most of its users. Future toolkits can inspire themselves by focusing on specific uses of technology to solve specific problems, and yet keep the SQL as a sort of security blanket, since that's where most of the training about databases(and indeed, usually most of the training about data, period, is in database classes and perhaps, some algorithmics classes)
After reading the linked articles about XML's weaknesses, though, I don't think it belongs into any toolkit of that nature. Simply because the tool that belongs in the toolkit is the "self-documenting data", and XML's weakness in that area is evidenced there. XML's early focus as a medium of e
Re:Relational does NOT have to be "hard" (Score:3, Interesting)
I was saying
1) a) Just how much more power could we get?
is beyond my mere predicate logic skills at this time.
Explaining just what power is missing from SQL to explain "the full power of relational models" in the context of the article, where it is said relational algebra can represent tree-like structures etc... is beyond me.
I am not interested in how hard relational is to use.
1)a) was referring to expressing, just what's missing in all the SQL servers, that could be reach
Re:'scuse my ignorance but... (Score:3, Interesting)
DBAs love to lock you into the database. Put more logic there. Use extensions so you're tied to a vendor. Squeeze
Re:FUD FUD FUD (Score:3, Informative)
...useless until you realize you have to connect to the DB from several applications written in several different languages for which you have either to reimplement your way to manipulate the data everywhere, or you have to put in a middle layer of some sort which is able to talk multiple languages (via CORBA, SOAP, plain XML RPC, custom protocol, whatever) and ensure that everyone is accessing data excl
Re:'scuse my ignorance but... (Score:5, Informative)
1) You can write a given query and number of different ways. This is not necessarily a SQL problem but due to this the query optimizers have to be enormously complex to handle complicated queries and by association you can have queries which describes two identical sets but have vastly different runtimes/costs.
2) Little/No support for relational domains (e.g. complex data types)
3) Non-updateable views (partially due to duplicate handling and/or allowing relations with no primary key)
4) Weak support for complex integrity constraints (e.g. business rules)
5) No support for entity sub/supertype relationships
6) Supports NULLs (Date/Pascal/Darwin do not like NULLs)
Try searching www.dbdebunk.com for SQL. Or pick up the great book "Practical Issues in Database Management" by Fabian Pascal.
Re:'scuse my ignorance but... (Score:5, Insightful)
Just because two queries return the same results today do not mean that they will continue to do so in the future. If a value that used to be bounded from 1 to 10 suddenly is declared to be allowed to be cranked to 11, then suddenly "equal or greater than 9" and "equal to 9 or equal to 10" will have gone from always returning the same results to now specifying different sets. Clearly, the more specific code will execute faster, but if an assumed boundry no longer holds in the future, the program will become obsoleted and require revision to the less specific version. This isn't a language-specific issue, it's just a problem that crops up whenever a computer program encounters a situation its designer wasn't expecting.
2) Little/No support for relational domains (e.g. complex data types)
Not a bug, it's a feature. The S in SQL is for "structure"... go hammer out your data into a structured format rather than a complex one and then come back.
3) Non-updateable views (partially due to duplicate handling and/or allowing relations with no primary key)
Totals will always be a non-updatable view. You can't change the number of objects you have without creating some new objects or chosing to get rid of some existing objects. Fields in a one-to-many relationship cannot be changed because to do so would be ambigious... do you want to create a new entry in the other table, or do you want to rename an existing entry in the other table. Go do what you meant to do, then refresh your view.
4) Weak support for complex integrity constraints (e.g. business rules)
That's more an issue for applications rather than databases. The program or user that's creating the query should know what's allowed by business rules, because if the database is going to refuse a query due to business rule violations, that query shouldn't have been offered to the database in the first place. Those errors should be trapped upstream before they get that far. SQL triggers for business rules should be a last line of defense, not something that should be regularly asked to function.
5) No support for entity sub/supertype relationships
Plenty of support, just not intrinsically. Just use a one-to-many relationship in your DB structure and go along your way.
6) Supports NULLs (Date/Pascal/Darwin do not like NULLs)
That's like trying to do math without a concept of zero. Sometimes, things just don't apply and we put "N/A" on the form and "NULL" in the database.
Re:'scuse my ignorance but... (Score:5, Informative)
Total misunderstanding of what I wrote. To put it another way:
SQL allows you to write queries which are mathematically equivalent but result in vastly different query plans and performance. Again, not a particularly stinging-indictment of SQL as such but had it been designed differently it could have avoided such ambiguity in the language.
"Not a bug, it's a feature. The S in SQL is for "structure"... go hammer out your data into a structured format rather than a complex one and then come back."
So you're saying a tree has no "structure"? That a domain has no structure? If it had no structure, it would be a little difficult for computers to process.
"View stuff"
Pascal (or Date, can't remember) provides an iron-clad (mathematical definition) method of creating views which will always be updatable. There are structural deficiencies in SQL which prohibit this. I will not waste time/typing here illustrating them, they are all identified at their web site.
"SQL triggers" etc.
It is precisely the reason that applications were enforcing business rules that DBMS were invented all those years ago! There are plenty of reasons that application-enforcement of business rules is a bad thing. Again these are illustrated on their web site. Also, your quote about "SQL triggers" is basically re-stating what I mentioned: that SQL is poor at implementing business rules!
"Plenty of support, just not intrinsically."
Which is exactly the same as saying "no support for entity sub/supertypes". Plus, one-to-many tables are not the same, you're thinking of something else. Chapter 6 of Fabian Pascal's book "Practical Issues in Database Management" covers this in some depth.
"That's like trying to do math without a concept of zero."
Not quite the same. Remember that the relational model is based upon predicate logic and set theory. Set theory has the empty set, which is not the same as NULL. SQL products currently handle null in a ridiculous manner (some sort NULL oddly, comparison is difficult, summation is odd). Pascal/Date do not suggest that the concept of "unknown" is bad, just that the SQL representation as NULL is.
Re:'scuse my ignorance but... (Score:5, Insightful)
Sounds like a semantic argument to me; where the Rubber Meets The Road, Linux is the kernel of a variety of widely used, production-quality OS's, while Minix is an academic *model* (on purpose, to be sure, but a *model* rather than a useable-on-a-daily-basis kernel, nevertheless). Similary, claiming SQL is crappy for various academic/theoretical reasons doesn't change the fact that it's in wide use today, as a concrete solution to any number of million- and billion-dollar abstract problems.
So, if SQL is so bad, maybe they should stop cursing the darkness, and show us the light. In the meantime, people will use (and incrementally) improve the tools at hand to solve the problems at hand.
Right now, SQL-based database solutions are generally the best solutions for *real* data problems that we have to solve, from mySQL-driven personal webpages, to enterprise-grade databases powering major websites, business-to-business e-commerce, and everything in between.
Invent a better mousetrap, and the world will beat a path to your door. Criticizing the mousetrap as an inferior pest control device doesn't do much to keep the mice out...
Xentax
My Two Cents (Score:4, Insightful)
On to the next part. XML serves its purpose very well. Although I wouldn't consider XML and SQL to serve the same problem sets equally well. There are certain situations where SQL is perfect. And there are other situations where XML is preferable. If you think of the two as two sides of the same coin, I think you're making a mistake. Likewise, you can't just flip between the two on a whim. Choose the format that's most suited to what you want to do and go forward.
It aint broke and don't need fixin'
Re:My Two Cents (Score:3, Interesting)
I've mainly used MySQL for my large projects, and like you, those projects have not had more than several million entries. But my experience with SQL has been wonderful. I have spent several hours pounding my head on a desk trying to understand why something did or didn't work. But all my applicatio
Link to history of SQL.. (Score:5, Informative)
Ignores the good points of SQL (Score:3, Insightful)
SQL sucks? (Score:5, Insightful)
It has been quite obvious that the designers of SQL had little understanding of data fundamentals in general, and the relational model in particular
Gimme a break. Love it or hate it, SQL is an amazingly powerful way to work with arbitrarily complex data sets. Need proof? It is the backbone of nearly every non-toy scale data storage project. No amount of psuedo-academic argument can make irrellavent the fact that it works.
Everybody goes through a phase where they bitch about SQL. So did I. And I built a clever OO DataModel module that abstracted it into pretty heirarchies and all sorts of clever crap. Then I tried actually building systems with it and realized I was better off with ugly ol' SQL.
I've been part of too many projects where people pulled out the UML books in favor of a decent First Normal Form DB design and led the team down the tubes.
I'm not saying these other methods don't have their place -- they do. But they aren't going to displace SQL because it has it's place also. And it's place isn't theoretical, it's been practically demonstrated a million times.
Cheers.
Re:SQL sucks? (Score:5, Insightful)
However, he hasn't delivered an exaple of one, he hasn't clearly articulated the differences between his vision and the commercial options, and he apparently refuses to acknowledge that some problems in life fail to fit well into the relational model (hierarchies, networks, inheritance, etc).
Much of what he, Celko, and Date complained about were actually responses by vendors to adapt to the real world. They were somewhat successful - and now SQL can be used successfully to solve a far greater set of problems than Pascal has ever admitted exist.
A perfect example of this nonsense is there insistence that good indexing in a 3NF model outperforms denormalized data in a star schema. Sounds great, absolutely doesn't work. Across eighteen years working with relational databases I've never seen their suggestions work. Of course they have a response to this - the vendors should just "make the databases faster" - like it's fucking magic or something.
Of course, this isn't to say that he's wrong about xquery - trying to work with unbalanced networks or hierarchies in which the rules change change throughout the schema causes a few problems.
We already have extensive support for recursion & networks in the more powerful RDMBS (db2 & oracle for sure). But combining that with data structures supporting optional branching, complete lack of declarative constraints, optional rules, etc - sounds like something that will never work well.
And going back to the days in which you have to spend a day writing code against a hierarchical database in order to answer a simple question sucks.
Hmmm, haven't people gotten tired of the xml hype yet?
Re:SQL sucks? (Score:4, Interesting)
create table notes(rownum bigint primary key default nextval('rownums'), the_row bigint, notes text);
and have the_row be a foreign key to the whole rest of the database (unfortunately, I'm unaware of any DB that has direct support for this). Then, I can use this table to attach notes to ANY record in the whole database. You can use such generics very easily if you have a common format for a primary key.
In addition, only very rarely do I find a primary key that I know for absolute certain will be unique.
Re:SQL sucks? (Score:5, Insightful)
In 15+ years as a database developer, I've never seen a non-trivial problem which could be modelled correctly in 1NF. In my experience, 3NF is pretty universially considered to be the default level of normalization. Any decision to deviate from 3NF, either up or down, should be documented and backed up with a solid engineering case as to why it's necessary.
Re:SQL sucks? (Score:3, Insightful)
Re:SQL sucks? (Score:3, Interesting)
More detailed articles (Score:5, Informative)
Readers interested in what Pascal and Date have to say may be interested in visiting Database Debunkings [dbdebunk.com]. It has lots of articles written by one or both of them.
Personally, I recommend the articles written by Date because they are clearly, concisely, accurately, and calmly written. Pascal's tend to turn into a rant, which I wouldn't mind but he always seems to refer to his books rather than give a detailed justification of his arguments.
What the?!... (Score:5, Insightful)
Can anyone summarize what is being said here in some sort of logical way? Because I'm confused. I see the title, I see no information supporting the title (unless, perhaps, I was to do the research myself).
Re:What the?!... (Score:4, Interesting)
He venerates the Founder. Finding a quote that supports your argument settles the matter. Codd the Wise avoided the errors that Chamberlin made; clearly the latter is the inferior intellect. And there's only a small core with the Founder. "We" are the true believers; all others are apostates and heretics.
Overstatement is a definite tell. Chamberlin's explanation of the difference between SQL and XML data is "unbelievable." The nesting argument is "ridiculous." Industry pronouncements are "incoherent." And most prominent of all is the cutting remark that's meaningless to anyone not in the know or already in agreement:
And I sure expect a polemicist to know enough about his art to understand when he's descended into self-parody.Good grief (Score:3, Insightful)
~D
Re:Good grief (Score:3, Funny)
The issues in dispute can't be expressed in plain english. That's why we need to upgrade to haughtiness and phase out plain english immediately.
The Problem, stated more accessibly (Score:5, Informative)
This, in turn, means that every operator (programmer, statement, etc) on the database must _individually_ "already understand" all the relationships that lie outside "the table" before they can act on the data at any significant scope.
That is, you, the programmer or operator must know, from some source besides the RDBMS itself, how the different tables work with eachother.
In simpler SQL-biased terms, you have to know, before you start, what is "good" to put in your WHERE CLAUSE to make a join. And then the RDBMS query optimizer needs to guess how to satisfy your needs in something other than glacial time.
Consider a new verb "EXPOSE thing, thing, thing, thing, thing..." that would fish out of a database the one-or-more relationships between the things, and produce a table-looking vector of "tuples" that consist sets of actual values for those things. This is what the theoretical "perfect" RDBMS would do.
Given (somewhat denormal 8-):
Customer ID -> Customer Name
Customer ID -> Street Address
Customer ID -> Zip Code
Customer ID -> Purchase Order ID
Purchase Order ID -> Part Number, Quantity
One should be able to "EXPOSE Part Number, Zip Code" and have the database "know the relationship" and produce the correct vector of tuples.
But that doesnt happen.
Now all the people bleating about the Higherarchial databases and bad things from the past are doing this harping because they remember the bad-old-days when a database would maintian one tree-structured set of relationships like this. In the higherarchical model, you could basically do this EXPOSE operation, but only if you had, by dint of pre-knowledge, asked for things lying on one linear path through the tree. (* simplified for brevity).
In essence, SQL requires you, the programmer, to be in the business of making up relationships that should be in the data or schema structure but isn't.
A magically complete RDBMS would take a series of vectors of the form "Independent Datum (key)->Dependent Datum (value)" (where either side of the arrow could be a list of atomic values). The RDBMS would then assemble and maintian tables or linked lists or whatever with no exposure of SQL-esque "tables" and the accessors would be storage method agnostic. (That is, there would be no such thing as a FROM CLAUSE.)
For instance, in the above list of relationships, Customer ID, Customer Name, Street Address, and Zip Code *could* all live in a "table", or not, but you would never know that. But a better vector of
Customer ID -> Street Name, Building Number, Suite to replace "Customer ID -> Street Address" has a table-feel, but would not bias against "EXPOSE Street Name, Part Number".
The power of this comes from being able to do:
EXPOSE Building, Part Number, Quantity
Where Building == "Word Trade Center 2";
And have the RDBMS already know the sequence of relationships to get from Building to (address elements) to Customer ID, to Part Number without the programmer writing the three stage join across the "uninteresting middle tables".
(The above presumes you have a building relation that has Street Name, Street Number -> Building or some such.)
All the XML nonsense is nonsense *_BECAUSE_* the strict-nesting enclosure requirements of XML make it "naturally" become hierarchically organized. But data exists outside the single-inheretance strict parantage trees that the hierarchical model dictates.
The problem is that SQL got real popular and so the idea of structural inferrence got pared down to tables and Query-Like constraints on tables before anybody had a chance to formalize the idea of living, encoded relationships between arbitrarily stored datum. So we never really got a language or system that could "EXPOSE".
Relation arithmetic (Score:3, Interesting)
I described a general vision for this sort of formalism in a prior slahsdot post [geocities.com]. Suffice to say some progress has been made since then -- and work in other areas is starting to converge. There is much yet to be done.
Error: User doesn't know how to use program. (Score:5, Interesting)
XML's going to be no better in this area. Mistakes made during the design phase will always come back to haunt while implementing and using the system. If a single query can't return the results desired, then that should have been thought of while designing the tables of the DB. Trying to get a query to specify "All things that are red" like Pascal suggests is only going to work if all objects implement the "color" property the same way. If somebody uses CMYK, somebody else uses RGB, and a third uses Play-Doh color names, it's still gonna be a mess that requires code to figure out who really matches whom.
I don't see how this "new model" fixes the real problems with working with SQL between databases that weren't designed to work with each other.
Peddling a better way? (Score:5, Insightful)
It's important to understand what XML is replacing - binary or proprietary interfaces. This means an acceptable tradeoff between human readability (a hugely underrated requirement of a structured data format) and efficiency.
An example is EDI vs XML. EDI "efficiency" accrues only to the intermediary that invented the means to setup trading relationships across their proprietary network. XML uses the end users' bandwidth but it simultaneously eliminates the intermediary completely. This single fact saves literally millions in kilocharacter and storage charges.
SQL is what my old compsci prof would call opportunity-cost efficient. It's quick and can be implemented a number of ways - it's a data query framework, not a requirement for databases. There may be better ways to do it but you'll have a tradeoff somewhere.
And if someone offers something better, then when they've finished telling you how good the new way is, wait and listen for the inevitable sales pitch.
Re:Peddling a better way? (Score:3, Insightful)
I mean, one can kiss of the intermediary with CSV files, financial 5-bit data files, packed decimal data files, string-and-cans dictation systems, etc.
And one can sign up to use any number of intermediaries with their brand-new XML data files backed with excellent XSDs, etc.
The data file does not bear on the intermediary.
I don't have time here but I will postulate what anyone doing data integration with disp
XML Misunderstandings (Score:5, Interesting)
The fact is that in order for any data interchange to work, the parties must first agree on what data will be exchanged - semantics - and once they do that, there is no need to repeat the tags in each and every record/document being transmitted
A major point of XML is that the semantics should be explicit. If you don't repeat the tags, you reply purely on position to indicate meaning. This is a Bad Thing. For example, it does not allow sparse data in which non-default or null values can be excluded.
Inter-system data exchange requires an agreed-on efficient machine-readable delimited file format.
XML was designed to avoid the issue of 'yet another machine-readable format'. XML can be read reasonably efficiently, but always preserves meaning, ignoring the horrors of character sets and byte order. Compressed XML is a very efficient way to transmit data.
An important part of XML design was that it should allow information to be expressed in a way that is independent of the software that uses it. In this way, it has something in common with SQL. The point of 'human reading and writing' is that in the last resort, you still have you data! It also makes data transfer hugely easier to debug.
There is also a lot of confusion about the order of tags in XML. Its possible to specify in a schema or DTD that some tags are required and should be in a certain order, but its also possible to just not care about order. XML is neutral about this.
Re:XML Misunderstandings (Score:3, Insightful)
He seems to be not sure what he is arguing, as far as I can tell. After all, XML is fundamentally a semantic markup, using HTML/SGML syntax. He seems to be arguing that sematics can be indicated by position, and that tags are unecessary and Any agree-upon delimited format will do. I strongly disagree with this.
You can use XML as a syntactical markup, but its rather a waste:
<record><data>1</data><data>
Never heard so much nonsense.. (Score:4, Insightful)
Question - can you express the recursive ancestor relation in SQL? You can express a single relation such as grand parent, but not the full relation.
Reason? Because SQL is not full relational calculus. It is basically propositional calculus (actually I maybe slightly wrong, and it falls in a higher calculus than propositional).
Prolog for example is closer, but still not true relational calculus (I forget whats missing).
There's a reason for SQL's limitations, and that's decidability - guaranteeing that the query will terminate... (admittedly in theory, and you can write some pretty horrendous statements).
Anyway, just wanted to get that off my chest. Doesn't say much about where XML falls in the scheme of thing - I guess strictlt speaking it doesn't - its just a layout. In fact, to compare XML and SQL is a complete misunderstanding. Its XSLT which should be compared.
An extreme position, but with good points (Score:4, Interesting)
XML is great for data exchange. Schemas are a wonderful way to describe data. But it is completely inappropriate for querying. If you need to query XML, you should import it into a database then query it that way. The very design trade-offs made when building XML were to make it extensible, and hard to query. XPath is nice to have for simple dinky import scripts. But trying to build a whole hierarchical query language on top of XML is silly.
If someone wants to build a standardized hierarchical query language, that's great. Very few people use hierarchical databases and need such a language, but I wish them luck in that endeavor. But don't pretend that it is appropriate to use it on XML, or that it has anything to do with XML. XML is an interchange format. Leave it where it works well.
Who the f*ck designs databases in SQL anyway? (Score:5, Insightful)
You design a DB best with a pen and a large sheet of paper. Or some drawing tool your extremely good at.
SQL is the language you feed you results into the box so it builds a more or less representative imprint of the abstract reality you've designed. Which can be as relational as you want it to - as long as it meets the physical constraints of non-abstract reality. As soon as you put it onto a computer, you'll have to cut corners. That's the difference between a database _model_ and a database _implementation_. That takes stuff into account like DB load, DB Server Features and data types.
Types for instance - somewhat relevant when dealing with DB Servers and SQL - are a thing you don't want to touch with a ten-foot pole when designing a _model_.
I'm suprised a supposedly db expert guy get's all worked up about this and doesn't seem to be able to keep apples and pears apart.
Anyone initially designing a non-trivial DB with SQL and - on top of that - bitchering about this DB language not being rational deserves a clobbering.
My 2 cents.
Theory vs. practice (Score:3, Insightful)
I've done several years of application programming using SQL
I've also implemented the (XQuery-derived) query processing module for a native XML database [xpriori.com]
In my former life as a application programmer, I really liked SQL. It allowed some pretty complicated computation to be done in the query, and very concisely in many cases compared to doing the same thing in, say, C++. For example, things like grouping are very nice for many application purposes.
In my current job, I'm hoping to create an XML query language that supports the same sort of capabilities as SQL. Our XML query language implementation has decent path/predicate, sorting, and output structuring capabilities, mostly derived from earlier drafts of XQuery.
My feeling about XQuery 1.0 is that it is extremely bloated. XML seems really simple; querying it shouldn't be all that complicated, should it? But the XQuery committee has created several hundred pages of specifications for the new language. This seems excessive, to say the least. We basically have implemented a subset of an earlier version (with paths, predicates, sorting, XML construction, a few dozen functions), and stopped tracking what they were doing. This is kind of unfortunate, but we really don't have the resources to support his behemoth in all its awesome grandeur.
We just want a language that lets programmers efficiently access our database. I think we're on the right track. I'm not at all sure that XQuery is going to wind up as a long-term success, partly because of its bloat factor.
My favorite illustration of the XQuery bloat is this: early versions (up to about April 2002 [w3.org]) of the XQuery language description contained this sentence in the introduction:
It is designed to be a small, easily implementable language in which queries are concise and easily understood.
Starting in August 2002 [w3.org], this was changed to:
It is designed to be a language in which queries are concise and easily understood.
The "small, easily implementable" part got smothered up by the avalanche of features they were adding.
The academia is forgetting the whole point of XML (Score:3, Interesting)
Someone saying something like that has really got a BS in BS! Or perhaps even worse: a PhD in BS.
XML is all about programmers being able to understand the data! Yes, because we are not anywhere near that nirvana of fully semantic systems that can (semi)automatically understand each other. NO! Programmers have to do the work to make the systems fit together and XML gives them the advantage that they do not have to reverse engineer another proprietary data format or dig into a horsepile of documentation. XML makes it easy to understand how to process the information at hand - without any extra work!
Also it's great format for storing small amounts of constantly changing data (like user preferences) cause it's extensible and with only a tiny bit of effort backward compatible as well.
Anyone trying to use XML for processing large amount of data (like data warehousing) is either nuts or doesn't give a damn about the speed or costs.
However anybody using XML for long term data storage is a genius since other "more efficent" formats will be obsolete ten years from now and the software that can read it can be extreamly difficult to obtain (anybody who has tried to decode data from some long gone accounting package from the '80-s knows what I am talking about).
So yes XML is self describing only to humans and that's the whole point of it. Formalizing data semantics is not the goal of XML, has never been and will never be, thats what we have RDF, RDFS, OWL and other nice initiatives from Semantic Web movement for.
Re:The academia is forgetting the whole point of X (Score:3, Insightful)
No. XML is all about storing meta-data alongside the data. And you are implying that programmers will not understand data that is not easy readable, like XML; this implication is an oversimplification.
(...) reverse engineer another proprietary data format (...)
XML is certainly not the only well-documented interchange format.
(...) dig into a horsepile of documentation.
Is is fairly easy to create XML documents that require horsepiles
Conflicting goals (Score:3, Interesting)
What an arrogant twit (Score:3, Interesting)
It's one thing to say that either SQL or XQuery have their problems, because they do. It's quite another to say that SQL is bad because it doesn't live up to some arbitrary never-achieved (and perhaps unachievable) standard of relational purity that even Codd himself found superfluous. When Pascal does nothing but the latter, and in addition takes a dozen thoroughly unprofessional swipes at Chamberlin for having been involved in both SQL and XQuery, his professional jealousy is becomes thick enough to choke on. I wish he would, so we would be spared the incessant ranting of someone whose whole career has been marked by a lot of words and not a single deed to back them up.
Put these arguments in perspective, please (Score:5, Insightful)
1. Does too much -- too many ways of doing the same thing, and too many unecessary operations that could be better done another way.
2. Overly complex -- the SQL 1999 standard was something like 1200 pages.
3. Allows programmer to circumvent relational integrity. Things like "hidden identifiers", pointers, etc...
4. Too wrapped up in implementation -- users must spend a lot of time understanding the physical storage, rather than focusing on queries in abstraction.
5. Many small inconsistencies in SQL itself
But the problems with SQL are impossible to judge if you only know SQL. It's like the people who used to ask what was wrong with a perfectly good typewriter that made people want to use a word processor. To any who are curious, I suggest you do some reading. The absolute best simple introductions for these problems are in a two online documents by Hugh Darwen at www.thethirdmanifesto.com [thethirdmanifesto.com]. Look for "The Askew Wall", and "The Importance of Column Names".
The Data man. problem must be solved at O/S level. (Score:3, Insightful)
In my opinion, an operating system must primarily provide a data management solution. It must provide the common ways to organize, store, retrieve and process data. This means that the application should only care about the logic behind the data, not how data management is implemented. There are only a few methods of data organization anyway, and it is a shame that these methods are not available when an O/S is installed.
The algorithms that concern the data types should also be available along with the data types. This means that an operating system not only should provide data management, but it should be object-oriented: each "data node" in the system should be available as a class in the chosen programming language (if it supports such a concept).
The availability of data and their types on the O/S level would also boost security and safety, as it would not be possible for a 'devious' application to approach the data in any other way other than the intended one.
Finally, the concept of 'application' is also wrong, and I am saying this in the context of data: in our day and age, data not only multiply fast, but the types of data are frequently modified. The liquid status of data (and their data types) makes the concept of an 'application' (thousands of source code lines, cast in the stone, with a huge degree of coupling between them) a huge obstacle in really making computers useful. Applications need to be replaced by a live system of persistent objects that do simple jobs and inform the world (through events) about changes in their state or the results of their computations; the O/S should be responsible of organizing how objects communicate with each other (either in the same memory space, in different memory spaces, or in different computers).
Since the current situation is not exactly orthogonal (as described above), there are many misunderstandings and problems in defining concepts clearly; many thousands of dollars are spent in re-inventing the wheel, and many work hours and brain power is consumed in creating what should already be there...(and thus we can have a nice
Oh dear (Score:4, Informative)
The article seems to says "I don't like SQL and I don't like XML and I think XML Query is about mergin them although I don't understand it very well, so the people working on XML Query must be stupid, and in any case it's easier to attack people than understand a specification".
Perhaps that's unfair, but it's clear to me that the writer is a little fuzzy on the design goals of XML and also on the focus of SQL development over the past 10 or 15 years.
In both cases the story is about interoperability.
If you look at the XML Query Home Page [w3.org] you'll see approximately two dozen implementations of the XML Query draft, including a number of open source ones. If you look at the public mailing list for comments, you'll see we received over 1100 detailed technical comments at the last public review. So there's a lot of interest in this work.
Why is that? One reason is that, like Web services and SOAP, XML Query is able to replace a lot of proprietary and hard-to-maitain middleware. Another reason is that for the first time we'll have a standard way to search over multiple kinds of data source.
Don is the primary editor of the XQuery language, but the technical decisions reflected in the specification are a result of collaboration, and are agreed on by aconsensus process by a much larger number of particpants. The goal is to make a language that people agree to implement and to use. With support announced by Microsoft, Oracle, IBM, BEA and others (see Web page mentioned above) and judging by the public interest, I think it's fair to say that's going to happen.
It's pretty rare to see a large complex system that everyone is happy with. It's actually pretty rare to see a small system that everyone is happy with. There are people who are unhappy with some features in the Unix cat program, but it's better to have cat in every Unix system than to have millions of shell scripts break on systems where it's missing! The trick, then, is often to include features that will lead to massively wider adoption, even if some people would rather be without them.
Then we have (as part of W3C Process [w3.org]) a public call for implementations so that we can test to see how confident we are that all the major features can be implemented compatibly (i.e. interoperably) in multiple independent implementations.
Features that were not implemented get removed before the specifications are final.
Is XML Query a waste of time? Is XML evil? Is SQL evil? A lot of people think otherwise, and some of them are pretty smart, so if you are concerned, take the time to read the specs and decide for yourself.
Rediculous (Score:5, Insightful)
Re:Rediculous (Score:5, Insightful)
Re:Rediculous (Score:5, Insightful)
One of his specific complaints is about SQL NULL values being "unrelational". As an example, a real-world designer might use the following table in a genealogy DB:
If a person hasn't died yet, then people.death would be NULL. Well that just isn't relational enough for our friend Pascal. Since relations can be used to express optional values, then by God they have to be: It's pure, correctly formed, and worse than useless. It causes a profusion of tables: one for every optional value. It turns every simple query ("tell me useful stuff about this person") into a join ("find matching rows from several tables about this person"). The database server has to waste time enforcing deaths.person_id's pointless UNIQUE constraint. Cascading deletion has to be used to clean up deaths when a row is deleted in people.The simple fact is that the world is full of optional, single-valued data. NULL-allowed columns express that data efficiently, without confusion, and without breakage. Community college database designers have no trouble using the convention productively. It may be a little inelegant, but it is pragmatic and balanced engineering. The only whining you hear is from zealots like Pascal who heap fire and fury on others, but never seem to deliver the mythic PerfectoRDBMS.
Re:It would seems SQL is better for RDB than XDB (Score:4, Informative)
Martin
Re:It would seems SQL is better for RDB than XDB (Score:3, Informative)
Both oracle & db2 have very good support for recursion. DB2 in particular can easily handle hierarchies and networks of unknown depth in a single query.
Things you use XML for (Score:3, Interesting)
You probably use XML a lot without knowing it.
Re:The Criterion here is no longer machine efficie (Score:3, Informative)
No. You. Can't.
You simply cannot know what the data means without specified semantics (which you have to agree upon somehow; they aren't magically apparent from the XML itself -- that's why such abominations as DTD and XML-Schema exist).
Re:The Criterion here is no longer machine efficie (Score:3, Interesting)
yeah, you tak a file that has 1000 linse, each line has 1024 characters, and 300 fields. Transmitted from Brazilla at 28K.
Now convert the to an XML format, and then try sending it. suddenly it take 10 times longer to get the data. Literally going from a couple of hours to all day. Not exactly cost effective.
XML is easy to read, if you know the format and context in which your reading it. It sti