Sybase has been releasing, ever since 11.9.2, plenty of new versions for Linux. They skipped 12.0 and went to 12.5 several years ago.
This announcement is a free as in "free beer" Linux ASE for deployment/production, something that Sybase hasn't done since ASE 11.0.0.3 for Linux.
Basically if you want to make an application that uses ASE on Linux, or you want to make a commercial website with ASE as the backend, you can now use this free version to do so (otherwise you'd have to purchase an ASE license).
It is very sensitive about the OS configuration, only runs well on supported platforms (RH Enterprise, Suse, etc). If it finds anything not conforming its requirements, displays the annoying "Proccess is infected with 11" (meaning Segmentation faults).
ASE 12.5 runs just fine on plenty of Linux distros. We run it in production on Red Hat 7.2. It will NOT give "Infected with 11" errors simply because you're on a different (non-supported) distro; it gives you those errors if libraries are missing/not the right version.
Conversion to Transact-SQL data types from MySQL or Postgres is very tricky, because it doesn't have sub-integer types (smallint, mediumint, etc)
Are you on drugs? Not only are most of MySQL's datatypes against the SQL standard, but ASE supports: int (-2,147,483,648 and 2,147,483,647), inclusive. smallint (-32,768 and 32,767), inclusive. tinyint (0 and 255), inclusive
Transact-SQL provides the smallint, int, numeric, and decimal SQL92 exact numeric datatypes. The tinyint type is a Transact-SQL extension.
Also, it uses different escape characters: eg. '' (two apostrophes) to represent one apostrophe inside a delimited string.
Blame MySQL and PostgreSQL for not correctly implementing the ANSI SQL STANDARD SPECIFICATION for escaping characters. This is the same as if you wanted to migrate to Oracle or Microsoft SQL Server, or any other product that correctly interprets this ANS SQL standard feature.
Quite possibly the stupidest comparison out there. They are comparing to Sybase ASE 10 -- a product which is almost a decade old -- and Sybase 11, which was released early 1996!
Of course, why should anyone care that the term is misused? Well, like I said, those in the DBMS industry are somewhat annoyed that XML/XMLDBMS have sprung up to 'handle' all the 'unstructured' data which, as I mentioned before, already has structure.
The real solution is to simply not generate 'not formally defined' data in the first place - if you have your data stored in a DBMS then ship that to the client which can then logically process it (since you provided the definition as well). This is what Codd et al. proposed almost forty years ago with the relational model. XML does basically this but in a less-than-optimal fashion.
However consider that the content in a big text field still has structure. If it is text data it is comprised of paragraphs, words, sentences, letters, etc. -- the structure is there just slightly more difficult for computers to work out.
Does 'common usage' trump the 'actual' definition here (e.g. structured vs. unstructured)?
I wish it didn't. Personally, as one in the DBMS field, I would much rather prefer people not use unstructured incorrectly (as 'common usage' does): technically "unstructured data" is an oxymoron. Data has structure otherwise it is not data (just random noise?).
Perhaps a more accurate term would be "non-rigorously defined" data. Or maybe "not formally defined" data.
However consider that the content in a big text field still has structure. If it is text data it is comprised of paragraphs, words, sentences, letters, etc. -- the structure is there just slightly more difficult for computers to work out.
Does 'common usage' trump the 'actual' definition here (e.g. structured vs. unstructured)?
I wish it didn't. Personally, as one in the DBMS field, I would much rather prefer people not use unstructured incorrectly (as 'common usage' does): technically "unstructured data" is an oxymoron. Data has structure otherwise it is not data (just random noise?).
Actually, Codd theorized this in the Relational Model back in the late 60's (published in 1970). He realized the necessity for logical/physical data representation separation and formulated a data model around it. It's a shame that people are only now starting to realize that it was a very, very good idea.
Although he was probably not the first person to arrive at the "data abstraction" idea he was the first to propose a general (that is to say it applies to any data) theory of data which required it.
I agree that a RDBMS as a file system is the way to go -- but we'd have to invent a true RDBMS first.:)
I've been waiting for the antiquated concept of a 'file' to go away for a long time now. The 'file' concept exposes the underlying physical construct to the user for no particularly good reason. Nowadays this limitation is foisted upon users simply because "that's the way we've always done it" which is totally contrary to the way we think of logical constructs: documents, emails, contacts, etc. and there's no reason not to store those things in a RDBMS (unless you're a company that enjoys proprietary file format lock-in).
I think what would have to occur to really show the power would be an OS that offers a true RDBMS to all applications. When you really think about it, though, current operating systems are a form of DBMS except without some of the DBMS features that we all know and love -- constraints, domains, query language etc. (some of these are currently emulated via application programs).
What is exciting to geeks like me is that a true RDBMS would be an OS unto itself -- and you'd just have various applications hanging off of it to do the UI.
Taking it to the furthest level applications would no longer necessarily be these big monolithic, closed-source juggernauts but merely constraints and 'business logic' that plug into the user's DBMS and are interpreted via the UI. It's the penultimate "information wants to be free" system.
It is an incredibly powerful concept which would require re-thinking virtually everything that we do nowadays for application development: Count me "in" on possibly the greatest computing revolution since we invented PCs (well and probably the internet, too).
And as an aside, the above concepts are slowly being "reinvented" by the XML crowd (e.g. XUL, WinFS, etc.). It's a shame we've had the framework for a good 30-40 years but no one has really thought about it until now and instead choose the flavor-of-the-month instead of the sound foundation that the RDBMS provides. It's a damn shame, because the XML-based products will fail just like their ancestors (IBM IMS and other hierarchic/network products) did. This, of course, will destroy any products which
do correctly implement it through guilt-by-association.
Of course, this idea is not without fault: such a system would be a non-trivial undertaking and probably would not even succeed in today's marketplace due to practitioner ignorance, corporate greed/power, and plain old end-user inertia. Still, it's one of those things that I wish I could do given unlimited money and plenty of talented software engineers.
"what does a wheel-barrow... have... to do with DBs??"
Nothing. It's even an incorrect category. A database is the data you collect. PostgreSQL is a DataBase Management System (DBMS). They should rename the category to reflect this.
Even looking at the configuration screen shots gave me a little wood: I can't imagine the unparalleled joy I will feel when I start it for the first time.
I suspect one of these things will occur: 1) my heart will stop for two or three seconds when I hear the first 5.1 audio 2) my bladder will burst from playing through the entire game in one marathon 54 hour session 3) I will immediately develop carpal tunnel and a permanent curved spine from sitting in my computer chair 4) My eyes will melt in their sockets like the Nazis in Indiana Jones: Raiders of the Lost Ark 5) all of the above
I posed a question to this thread but you seem knowledgeable: If my motherboard supports digital S/P DIF 5.1 is it necessary to purchase an add-on sound board (e.g. a Creative or Turtle Beach) for my system if all I'm interested in is 5.1 gaming (e.g. Doom3)?
Modern motherboards contain on-board sound -- many of which are 5.1 or greater with digital S/P DIF connectors. With all the hoopla over Doom 3 hardware requirements I couldn't find any major ([H]ardOCP, Tom's Hardware, etc.) sites listing audio benchmarks or quality comparisons pitting on-board sound and cards like the Creative Z2 series.
I'm not an audiophile, but for games like Doom 3 etc. if a motherboard already supports digital 5.1 (or greater) is it really necessary to go out and purchase a Creative card? Will said on-board audio provide sufficient quality for 5.1+ gaming? I'm building a gaming system to replace my aging first-generation Athlon and am not sure whether or not I should throw a sound card in the mix, too.
Well, their solution is for DBMS vendors to implement, not SQL DBMS users (because SQL products are pretty clunky as you pointed out).
"...that it seems to assume that you will always know why you don't know. In reality, I think systems like this would sprout lots of tables called "unknown_value_for_unknown_reasons"."
Well, consider what it means to say "I don't know why I don't know this" -- why would you store that in the DBMS in the first place? The DB is a collection of facts, and the absence of a fact is essentially "I don't have this fact" which I think is logically equivalent to your supposition.
However that said I'm not sure of too many instances (I can't think of any off of the top of my head) of why you'd have something that is truly unknown in your example. Of course, you have to wonder how valuable or reliable the rest of your data is if you start having many entries of "I have no idea":)
"Just because two queries return the same results today do not mean that they will continue to do so in the future."
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 NULLis.
I'm not quite sure what you're getting at but if you've read his work he's never saying that the concept of a missing attribute is "bad" just that the "NULL" method of representing it as such is. He proposes several different methods in his book which I think I mentioned somewhere else.
If you're interested, it's Chapter 10 - "What You Don't Know Can Hurt You: Missing Information". Take a look at it for a more precise definition.
There are a couple of "problems" that they have identified: 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.
To those not "in the know" here's some further clarification:
"The use of the terms "flat tables" or "2D tables" to describe data stored in a relational database is wrong, he added."
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.
When asked if the relational model was implemented soundly in today's systems, Craig Mullins' instant reply was "no," but he doesn't think the situation is as bad as Date says it is.
"We're doing production work and delivering value," Mullins said. "Isn't that what it is all about?"
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.
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!
"By the way, haven't I seen the exact same arguments in another favorite geek arena?"
Indeed, however it is worse in computer science. Those that don't know the "science" (read: fundamentals) behind their chosen professions are merely cookbook-style practitioners. In computer science (like cooking) the barrier to entry is low enough that any yahoo can claim to be a programmer. The main difference is that there is no easy way to deem software {wrong|broken|incorrect|etc} like you can do with food, buildings, etc.
Yet if you were to use a SQL DBMS you wouldn't have to do any sort of mucking around with parsing, validating, etc. -- the DBMS does it for you.
And oh, it has schemas, too, along with a much better query language and constraints (business rules). SQL DBMS products, although not perfect, are far better suited for data storage than XML will ever be (due to the underlying hierarchic data model, no logical/physical independence, and lack of fundamental knowledge by 'standards' folks like the W3C), no matter how many XML:whatsits are developed for it.
The point is not whether or not you can accomplish something using MySQL. The point is that it takes more effort on your part to do it right. If you were my employee I'd want you to do it right in the shortest amount of time. MySQL forces you to spend more time to do it wrong.
For example: *Before MySQL implemented foreign key constraints you had to manually run queries to ensure that the parent(s) existed (this is still a problem if you do not use InnoDB) *Since MySQL lacks more complex constraints you must implement business rules procedurally in your code. This is less simple (and therefore less desirable) than declarative constraints in the DBMS and is also easily circumvented (possibly leading to inconsistent e.g. worthless data) *Since MySQL lacks stored procedures and triggers you must implement these in code (same caveats apply as above) *Since MySQL (except the latest versions) does not support multi-table updates/deletes you must implement this in code *Since MySQL does not support views then underlying schema changes are exposed to applications and so you must change the application (this is bad for obvious reasons).
And there are plenty of other reasons which make it more difficult, more time consuming, and flat out more dangerous to develop MySQL applications (from a data integrity standpoint). Of course, MySQL is still better than rolling your own DBMS (e.g XML or something) so between nothing and MySQL, MySQL still wins. But between more capable DBMS products MySQL causes nothing but more work for developers.
"Use the right tool for the job!" This is more a commentary on the state of the IT industry than a pointed reply to your comment but most people that say this do not know how to select the "right tool". They lack the fundamentals and critical thinking skills to do so. They merely know tools and how to mechanically apply them ("When you have a hammer every problem looks like a nail").
Slashdot Mirror
Sybase has been releasing, ever since 11.9.2, plenty of new versions for Linux. They skipped 12.0 and went to 12.5 several years ago.
This announcement is a free as in "free beer" Linux ASE for deployment/production, something that Sybase hasn't done since ASE 11.0.0.3 for Linux.
Basically if you want to make an application that uses ASE on Linux, or you want to make a commercial website with ASE as the backend, you can now use this free version to do so (otherwise you'd have to purchase an ASE license).
"3. Table-level locking by default."
Page-level locking is default.
ASE 12.5 runs just fine on plenty of Linux distros. We run it in production on Red Hat 7.2. It will NOT give "Infected with 11" errors simply because you're on a different (non-supported) distro; it gives you those errors if libraries are missing/not the right version.
Are you on drugs? Not only are most of MySQL's datatypes against the SQL standard, but ASE supports:
int (-2,147,483,648 and 2,147,483,647), inclusive.
smallint (-32,768 and 32,767), inclusive.
tinyint (0 and 255), inclusive
Transact-SQL provides the smallint, int, numeric, and decimal SQL92 exact numeric datatypes. The tinyint type is a Transact-SQL extension.
Blame MySQL and PostgreSQL for not correctly implementing the ANSI SQL STANDARD SPECIFICATION for escaping characters. This is the same as if you wanted to migrate to Oracle or Microsoft SQL Server, or any other product that correctly interprets this ANS SQL standard feature.
Quite possibly the stupidest comparison out there. They are comparing to Sybase ASE 10 -- a product which is almost a decade old -- and Sybase 11, which was released early 1996!
Of course, why should anyone care that the term is misused? Well, like I said, those in the DBMS industry are somewhat annoyed that XML/XMLDBMS have sprung up to 'handle' all the 'unstructured' data which, as I mentioned before, already has structure.
The real solution is to simply not generate 'not formally defined' data in the first place - if you have your data stored in a DBMS then ship that to the client which can then logically process it (since you provided the definition as well). This is what Codd et al. proposed almost forty years ago with the relational model. XML does basically this but in a less-than-optimal fashion.
What was once old is new again, eh?
However consider that the content in a big text field still has structure. If it is text data it is comprised of paragraphs, words, sentences, letters, etc. -- the structure is there just slightly more difficult for computers to work out.
Does 'common usage' trump the 'actual' definition here (e.g. structured vs. unstructured)?
I wish it didn't. Personally, as one in the DBMS field, I would much rather prefer people not use unstructured incorrectly (as 'common usage' does): technically "unstructured data" is an oxymoron. Data has structure otherwise it is not data (just random noise?).
Perhaps a more accurate term would be "non-rigorously defined" data. Or maybe "not formally defined" data.
However consider that the content in a big text field still has structure. If it is text data it is comprised of paragraphs, words, sentences, letters, etc. -- the structure is there just slightly more difficult for computers to work out.
Does 'common usage' trump the 'actual' definition here (e.g. structured vs. unstructured)?
I wish it didn't. Personally, as one in the DBMS field, I would much rather prefer people not use unstructured incorrectly (as 'common usage' does): technically "unstructured data" is an oxymoron. Data has structure otherwise it is not data (just random noise?).
Actually, Codd theorized this in the Relational Model back in the late 60's (published in 1970). He realized the necessity for logical/physical data representation separation and formulated a data model around it. It's a shame that people are only now starting to realize that it was a very, very good idea.
Although he was probably not the first person to arrive at the "data abstraction" idea he was the first to propose a general (that is to say it applies to any data) theory of data which required it.
I've been waiting for the antiquated concept of a 'file' to go away for a long time now. The 'file' concept exposes the underlying physical construct to the user for no particularly good reason. Nowadays this limitation is foisted upon users simply because "that's the way we've always done it" which is totally contrary to the way we think of logical constructs: documents, emails, contacts, etc. and there's no reason not to store those things in a RDBMS (unless you're a company that enjoys proprietary file format lock-in).
I think what would have to occur to really show the power would be an OS that offers a true RDBMS to all applications. When you really think about it, though, current operating systems are a form of DBMS except without some of the DBMS features that we all know and love -- constraints, domains, query language etc. (some of these are currently emulated via application programs).
What is exciting to geeks like me is that a true RDBMS would be an OS unto itself -- and you'd just have various applications hanging off of it to do the UI.
Taking it to the furthest level applications would no longer necessarily be these big monolithic, closed-source juggernauts but merely constraints and 'business logic' that plug into the user's DBMS and are interpreted via the UI. It's the penultimate "information wants to be free" system.
It is an incredibly powerful concept which would require re-thinking virtually everything that we do nowadays for application development: Count me "in" on possibly the greatest computing revolution since we invented PCs (well and probably the internet, too).
Of course, this idea is not without fault: such a system would be a non-trivial undertaking and probably would not even succeed in today's marketplace due to practitioner ignorance, corporate greed/power, and plain old end-user inertia. Still, it's one of those things that I wish I could do given unlimited money and plenty of talented software engineers.
"what does a wheel-barrow... have... to do with DBs??"
Nothing. It's even an incorrect category. A database is the data you collect. PostgreSQL is a DataBase Management System (DBMS). They should rename the category to reflect this.
To those whining that $55USD is too much... try doing a little leg work before bitching.
Microcenter has a coupon to purchase it until 8/8/04 for $46.87.
Circuit City has it online for $44.99 with free shipping.
Best Buy will price match (in store purchase only) for the difference plus 10%.
What does this mean? You can easily pick up Doom 3 for less than $46USD. Quit your whining and start playing!
Even looking at the configuration screen shots gave me a little wood: I can't imagine the unparalleled joy I will feel when I start it for the first time.
I suspect one of these things will occur:
1) my heart will stop for two or three seconds when I hear the first 5.1 audio
2) my bladder will burst from playing through the entire game in one marathon 54 hour session
3) I will immediately develop carpal tunnel and a permanent curved spine from sitting in my computer chair
4) My eyes will melt in their sockets like the Nazis in Indiana Jones: Raiders of the Lost Ark
5) all of the above
BRING IT ON
I posed a question to this thread but you seem knowledgeable:
If my motherboard supports digital S/P DIF 5.1 is it necessary to purchase an add-on sound board (e.g. a Creative or Turtle Beach) for my system if all I'm interested in is 5.1 gaming (e.g. Doom3)?
Modern motherboards contain on-board sound -- many of which are 5.1 or greater with digital S/P DIF connectors. With all the hoopla over Doom 3 hardware requirements I couldn't find any major ([H]ardOCP, Tom's Hardware, etc.) sites listing audio benchmarks or quality comparisons pitting on-board sound and cards like the Creative Z2 series.
I'm not an audiophile, but for games like Doom 3 etc. if a motherboard already supports digital 5.1 (or greater) is it really necessary to go out and purchase a Creative card? Will said on-board audio provide sufficient quality for 5.1+ gaming? I'm building a gaming system to replace my aging first-generation Athlon and am not sure whether or not I should throw a sound card in the mix, too.
"(outside of it's general clunkiness)"
:)
Well, their solution is for DBMS vendors to implement, not SQL DBMS users (because SQL products are pretty clunky as you pointed out).
"...that it seems to assume that you will always know why you don't know. In reality, I think systems like this would sprout lots of tables called "unknown_value_for_unknown_reasons"."
Well, consider what it means to say "I don't know why I don't know this" -- why would you store that in the DBMS in the first place? The DB is a collection of facts, and the absence of a fact is essentially "I don't have this fact" which I think is logically equivalent to your supposition.
However that said I'm not sure of too many instances (I can't think of any off of the top of my head) of why you'd have something that is truly unknown in your example. Of course, you have to wonder how valuable or reliable the rest of your data is if you start having many entries of "I have no idea"
"When you say "no support for entity sub/supertypes" it is a specific indictment of SQL not RDBMSs in general."
Yes, of course. Perhaps I should have clairified -- those are 'features' possible in a RDBMS but not in SQL; hence a SQL limitation.
SQL DBMS != RDBMS.
You're basically re-iterating my points.
Check my other posts for a complete rebuttal/clarification of all of your points.
"Just because two queries return the same results today do not mean that they will continue to do so in the future."
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.
I'm not quite sure what you're getting at but if you've read his work he's never saying that the concept of a missing attribute is "bad" just that the "NULL" method of representing it as such is. He proposes several different methods in his book which I think I mentioned somewhere else.
If you're interested, it's Chapter 10 - "What You Don't Know Can Hurt You: Missing Information". Take a look at it for a more precise definition.
There are a couple of "problems" that they have identified:
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.
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.
Celko is misquoting Darwin in saying that "The idea that you will always know everything is arrogant".
t o.web/Missing-info-without-nulls.pdf
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!
"By the way, haven't I seen the exact same arguments in another favorite geek arena?"
Indeed, however it is worse in computer science. Those that don't know the "science" (read: fundamentals) behind their chosen professions are merely cookbook-style practitioners. In computer science (like cooking) the barrier to entry is low enough that any yahoo can claim to be a programmer. The main difference is that there is no easy way to deem software {wrong|broken|incorrect|etc} like you can do with food, buildings, etc.
Yet if you were to use a SQL DBMS you wouldn't have to do any sort of mucking around with parsing, validating, etc. -- the DBMS does it for you.
And oh, it has schemas, too, along with a much better query language and constraints (business rules). SQL DBMS products, although not perfect, are far better suited for data storage than XML will ever be (due to the underlying hierarchic data model, no logical/physical independence, and lack of fundamental knowledge by 'standards' folks like the W3C), no matter how many XML:whatsits are developed for it.
The point is not whether or not you can accomplish something using MySQL. The point is that it takes more effort on your part to do it right. If you were my employee I'd want you to do it right in the shortest amount of time. MySQL forces you to spend more time to do it wrong.
For example:
*Before MySQL implemented foreign key constraints you had to manually run queries to ensure that the parent(s) existed (this is still a problem if you do not use InnoDB)
*Since MySQL lacks more complex constraints you must implement business rules procedurally in your code. This is less simple (and therefore less desirable) than declarative constraints in the DBMS and is also easily circumvented (possibly leading to inconsistent e.g. worthless data)
*Since MySQL lacks stored procedures and triggers you must implement these in code (same caveats apply as above)
*Since MySQL (except the latest versions) does not support multi-table updates/deletes you must implement this in code
*Since MySQL does not support views then underlying schema changes are exposed to applications and so you must change the application (this is bad for obvious reasons).
And there are plenty of other reasons which make it more difficult, more time consuming, and flat out more dangerous to develop MySQL applications (from a data integrity standpoint). Of course, MySQL is still better than rolling your own DBMS (e.g XML or something) so between nothing and MySQL, MySQL still wins. But between more capable DBMS products MySQL causes nothing but more work for developers.
"Use the right tool for the job!"
This is more a commentary on the state of the IT industry than a pointed reply to your comment but most people that say this do not know how to select the "right tool". They lack the fundamentals and critical thinking skills to do so. They merely know tools and how to mechanically apply them ("When you have a hammer every problem looks like a nail").