If you don't understand or know the necessity of things like constraints and tying business logic close to the data then you don't care that MySQL can't do them. It's obvious that MySQL developers do not have a clear understanding of the relational model, either.
And how is this elitist? Is it elitist to require that engineers who build bridges know the physics behind bridge building? Would you go to a doctor that didn't know the science of human physiology? Why do we not expect the same level of competence from people who build databases?
As computer professionals we need to hold ourselves to the same standards that we require other professionals. I'm not suggesting, or even think it's a good idea, to license developers but we need to get out of the mindset that it's acceptable to eschew formal ideas (predicate logic/set theory and the Relational Model) for ad hoc junk science (XML, UML, virtually every SQL DBMS product, etc.) all in the nebulous name of 'performance'.
Why UML is bad...
on
UML Fever
·
· Score: 2, Informative
This is a well-known persuasive issue...
on
The Paradox of Choice
·
· Score: 4, Insightful
This is a well-known phenomenon in people management. If you're trying to persuade someone to make a choice and give them 50 options they are most likely to not choose any of them (or in this case, stick with Windows). When you have so many options they get worried and confused - did I pick the right one? What if I had picked XYZ? What makes option XYZ better than option ABC?
Now, I'm not suggesting that choice is bad - but if you want someone to decide you must initially present them with a small number of options - A or B - not A or B or C or D or.. N, etc..
You can take a look at Sybase ASE which runs on Linux, Windows, Solaris, etc.. As I'm sure you are aware Sybase wrote the original SQL Server and licensed it to Microsoft. When they split (around version 6.5 I think) Microsoft took the SQL Server name.
In any rate, Sybase ASE uses the T-SQL dialect and also has many of the same stored procedures for system administration.
I would rather HK-47 would chat it up: "Hello meatbag... err.. master."
"It's just that... you just have all these squishy parts, master. Not to mention all the water - how the constant sloshing doesn't drive you mad I don't know."
But is there actually a need for a truly relational database?
Only like there is actually a need for a car that doesn't crash and drives you to your destination. Certainly you can get from point A to point B with any old auto now -- but it would be easier and safer if the car did that for you (presupposing that such algorithms could be written etc.)
Relational does not refer to restrictions that the software imposes on the developer.
The Relational Model is quite well-defined by Codd -- your assertions are quite false and make little or no sense. A series of "rules of thumbs" is available online - search google for Codd's 12 rules.
Any database product that allows a developer to relate a record in one table to a record in another table
is relational. "End of story."
You are incorrect. A RDBMS is comprised of relations which have a very strict mathematical definition. Their set-theoretic background rules out duplicate tuples (rows) - sets do not contain duplicates. A relation that allows duplicates is no longer a relation by definition, therefore a DBMS which allows duplicate rows is not relational. Q.E.D.
Can you honestly tell me that what I do for a living is not develop relational databases...
You can logically model a RDBMS - but no such product exists to fully implement that logical model. You have to shoehorn it into a SQL DBMS which does not fully implement the relational model.
Try picking up a few good books/papers (Practical Issues in Database Management by Pascal, just about any of Codd's works, etc.) and reading them. You are obviously ignorant about RDBMS.
RowIDs typically are: 1) Not visible to the user 2) Based on physical (e.g. on-disk) row placement (e.g. Oracle's ROWID pseudocolumn)
Both of these are violations of the relational model.
If, however, every table had a unique sequence number or something, then sure they would not be materially in breach of the uniqueness constraint. However, remember that result sets are *also* relations so you would have to have DISTINCT appended to every SELECT statement to also pass the uniqueness test.
Obviously you can generate duplicate rows any number of ways if you include non-unique column combinations in your SELECT.
In any rate, because SQL allows you to create a table *without* a primary key (which then means that result sets can have duplicate rows) then it is not relational. End of story.
No one is saying that SQL is double-plus ungood, just pointing out that it is not relational (just as saying that 2+2 != 5, and the sky is not made of fish), and don't attribute deficiencies of SQL to deficiencies of the relational model.
You can begin to understand how Date and Pascal et al at DBDebunk.com feel if you consider the following scenario (this thought exercise presupposes that perfect is possible):
You spend a lot of time and effort developing The Perfect Car which is perfect in every way. Not only does it not require any non-renewable resources, but it drives to any destination perfectly and is perfectly safe. You work out all the mathematical details and proofs and can say: "I have proven that this car is perfect."
Since you do not have the time/expertise/money/etc. to build The Perfect Car you then license your Perfect Car Model to the big automakers. They then proceed to implement your Perfect Model in the form of a "Perfect Car" Implementation. Unfortunately for them, building The Perfect Car is very, very difficult, almost impossible. The automakers then proceed to make significant changes to your Perfect Model. They cut corners, make changes which violate certain precepts and assumptions in your Perfect Model, etc.
They then put The Less-Than-Perfect Car on the market but proceed to call it a Perfect Car. After the "Perfect Car" Implementations that people start to buy get lost, run out of gas, and even blow up and kill them, they start saying: "These Things are wrong with the Perfect Car!"
Enterprising people then decide to try and fix the "Perfect Car" Implementations by creating New Perfect Car Models. Some of these models include the implementations as a background. Some create Entirely New Models Without Significant Scientific Background. They provide, possibly, incremental improvement over the "Perfect Car" Implementations but generally include just as many, if not more so, opportunities for flaming, burning death as the current Implementations. Not only that, but they throw out Actual Working Parts of the "Perfect Car" Implementations!!
And all the while you are there, yelling from the sidelines: "But that is not a Perfect Car! I have shown you the path (Model) to building the Perfect Car! I have Proved it True! If you'd stop wasting your time on these other Stupid Designs and focus on the Perfect Model then we'd all be better off!"
Now that this long-winded description is over you can replace The Perfect Car with The Relational Model and "Perfect Car" Implementations with {Oracle, MySQL, etc.}. You can replace "New Perfect Car Models" (including "Without Significant Scientific Background") with {XML, OO-DBMS, 'Persistence Layers', etc.}.
No one is saying that you cannot use SQL products or XML, or that you cannot accomplish tasks in these tools, just that when used in the context of data management they are poorly solving what the Relational Model already solved.
Because IT practitioners are poorly educated and increasingly fad-driven they latch onto non-solutions (like XML, "Post-Relational", OO-DBMS, etc.) and put little or no pressure on DBMS vendors to get it right. Even worse, if someone does release a Truly Relational DBMS there are no guarantees that anyone will buy it due to the ignorance of the IT community.
Put simply: People don't know what they're missing, so they don't know to ask.
And, of course, there is nothing stopping you from using your AGP in conjunction with the rest of your PCI slots (or all PCI-slot multi-displays), either. Before multi-head cards were common I used to have an AGP plus two PCI cards for triple displays.
I bought two Iiyama 17" 4315s a couple years ago after Tom's Hardware rated them the best 17" they've ever seen. You can get them for about $550USD which is a far better deal than the $750 they were when I got em!
Scatological reference aside, I do agree. Not only that, but educate them *properly*. Most higher education these days is a sham. They 'teach' products and not processes, cook-book approaches and not critical thinking.
Dijkstra has a few things to say on the topic as well:
On Education, Specifically:
The ongoing process of becoming more and more an a-mathematical society is more an American specialty than anything else (It is also a tragic accident of history).
The idea of a formal design discipline is often rejected on account of vague cultural/philosophical condemnations such as "stifling creativity"; this is more pronounced in the Anglo-Saxon world where a romantic vision of "the humanities" in fact idealizes technical incompetence. Another aspect of that same trait is the cult of iterative design.
Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its work force. Since in the US the influence of industry is more pervasive than elsewhere, the above dogma hurts American computing science most. The moral of this sad part of the story is that as long as the computing science is not allowed to save the computer industry, we had better see to it that the computer industry does not kill computing science.
And then on Computer Science in general:
"I hope very much that computing science at large will become more mature, as I am annoyed by two phenomena that both strike me as symptoms of immaturity.
The one is the widespread sensitivity to fads and fashions, and the wholesale adoption of buzzwords and even buzz notes. Write a paper promising salvation, make it a "structured" something or a "virtual" something, or "abstract", "distributed" or "higher-order" or "applicative" and you can almost be certain of having started a new cult.
The other one is the sensitivity to the market place, the unchallenged assumption that industrial products, just because they are there, become by their mere existence a topic worthy of scientific attention, no matter how grave the mistakes they embody. In the sixties the battle that was needed to prevent computing science from degenerating to "how to live with the 360" has been won, and "courses" -- usually "in depth"!-- about MVS or what have you are now confined to the not so respectable subculture of the commercial training circuit. But now we hear that the advent of the microprocessors is going to revolutionize computing science! I don't believe that, unless the chasing of dayflies is confused with doing research. A similar battle may be needed." --Edsger W. Dijkstra, My Hopes Of Computing Science, 1979
I'm pretty sure, in the case of IM, that network issues are quite important. When you consider the potential client base (tens of millions of IM users) network message size is of CRITICAL importance.
I would be willing to BET MONEY that the IETF sat down with XML in mind and did NOT critically evaluate the suitability (or not) of XML before deciding the protocol.
A, yes true, but does it really matter? As others have stated, you don't ALWAYS need to have extremely small, efficient, fast, etc. code/programs/information/etc.
WHAT!?!?!? Since when is it acceptable to WASTE computing resources JUST BECAUSE? You certainly are not someone who has to manage any sort of large-scale system (be it a network, or a DBMS, or a render farm, etc.).
We're talking about a protocol that, potentially, tens of millions of people will be using. I think it would be important to CONSIDER optimization.
XML has been PROVEN to be a superfluous format, one which poorly or incompletely solves problems which have already been solved.
Whereas IM is WHOLLY made up of time-sensitive (I'd not call IM 'time critical', but close) network transactions (aside from idle clients, but in that case the format could include 10MB of junk and not matter).
Just because XML parsers already exist doesn't mean XML is better. It means someone spent a lot of time parsing a poor language. Hey, Google has an Esperanto translator, let's all start authoring our web pages in Esperanto!
"WEFSAFD" was random frustrated keyboard mashings.
You say "Computer readability" then you mention an example of someone opening the file and looking at it.
As an API developer I would care what the physical structure of a file is only because I'm writing functions to write to these files. As an application developer I couldn't care less; I would be working with high-level things like 'measures' and 'notes'.
The method of storage has absolutely nothing to do with it being proprietary or not. In this case, XML is both ASCII and open, in that it doesn't obfuscate the plaintext. I could easily create a non-ASCII but open (all you have to do is tell someone what it is) format, just as easily as I could create an ASCII but 'closed' format (encrypting your message to an ASCII format for example).
Further, the scenario you paint makes no sense. A computer program does not need a file to be in ASCII text to be able to understand the structure and therefore derive meaning.
The only thing remotely plausible is that someone would look at the file contents but what is not plausible is that, given a super-duper-recognizing browser, they would use a text editor and not the penultimate file browser.
Slashdot Mirror
I can give you the reason why MySQL is so popular: practitioners are ignorant of data management fundamentals (perennial links: Unskilled and Unaware of it and Database Debunkings).
If you don't understand or know the necessity of things like constraints and tying business logic close to the data then you don't care that MySQL can't do them. It's obvious that MySQL developers do not have a clear understanding of the relational model, either.
And how is this elitist? Is it elitist to require that engineers who build bridges know the physics behind bridge building? Would you go to a doctor that didn't know the science of human physiology? Why do we not expect the same level of competence from people who build databases?
As computer professionals we need to hold ourselves to the same standards that we require other professionals. I'm not suggesting, or even think it's a good idea, to license developers but we need to get out of the mindset that it's acceptable to eschew formal ideas (predicate logic/set theory and the Relational Model) for ad hoc junk science (XML, UML, virtually every SQL DBMS product, etc.) all in the nebulous name of 'performance'.
I'll save the typing and just link:
DbDebunk.com
This is a well-known phenomenon in people management. If you're trying to persuade someone to make a choice and give them 50 options they are most likely to not choose any of them (or in this case, stick with Windows). When you have so many options they get worried and confused - did I pick the right one? What if I had picked XYZ? What makes option XYZ better than option ABC?
.. N, etc..
Now, I'm not suggesting that choice is bad - but if you want someone to decide you must initially present them with a small number of options - A or B - not A or B or C or D or
You can take a look at Sybase ASE which runs on Linux, Windows, Solaris, etc.. As I'm sure you are aware Sybase wrote the original SQL Server and licensed it to Microsoft. When they split (around version 6.5 I think) Microsoft took the SQL Server name.
In any rate, Sybase ASE uses the T-SQL dialect and also has many of the same stored procedures for system administration.
I would rather HK-47 would chat it up:
"Hello meatbag... err.. master."
"It's just that... you just have all these squishy parts, master. Not to mention all the water - how the constant sloshing doesn't drive you mad I don't know."
Only like there is actually a need for a car that doesn't crash and drives you to your destination. Certainly you can get from point A to point B with any old auto now -- but it would be easier and safer if the car did that for you (presupposing that such algorithms could be written etc.)
The Relational Model is quite well-defined by Codd -- your assertions are quite false and make little or no sense. A series of "rules of thumbs" is available online - search google for Codd's 12 rules.
You are incorrect. A RDBMS is comprised of relations which have a very strict mathematical definition. Their set-theoretic background rules out duplicate tuples (rows) - sets do not contain duplicates. A relation that allows duplicates is no longer a relation by definition, therefore a DBMS which allows duplicate rows is not relational. Q.E.D.
You can logically model a RDBMS - but no such product exists to fully implement that logical model. You have to shoehorn it into a SQL DBMS which does not fully implement the relational model.
Try picking up a few good books/papers (Practical Issues in Database Management by Pascal, just about any of Codd's works, etc.) and reading them. You are obviously ignorant about RDBMS.
Oracle has done plenty of MS-style things in the DBMS market.
Would you mind dropping me an email? I interviewed for a position there late 2001 and wondered about some people. Thanks!
RowIDs typically are:
1) Not visible to the user
2) Based on physical (e.g. on-disk) row placement (e.g. Oracle's ROWID pseudocolumn)
Both of these are violations of the relational model.
If, however, every table had a unique sequence number or something, then sure they would not be materially in breach of the uniqueness constraint. However, remember that result sets are *also* relations so you would have to have DISTINCT appended to every SELECT statement to also pass the uniqueness test.
Obviously you can generate duplicate rows any number of ways if you include non-unique column combinations in your SELECT.
In any rate, because SQL allows you to create a table *without* a primary key (which then means that result sets can have duplicate rows) then it is not relational. End of story.
No one is saying that SQL is double-plus ungood, just pointing out that it is not relational (just as saying that 2+2 != 5, and the sky is not made of fish), and don't attribute deficiencies of SQL to deficiencies of the relational model.
You can begin to understand how Date and Pascal et al at DBDebunk.com feel if you consider the following scenario (this thought exercise presupposes that perfect is possible):
Now that this long-winded description is over you can replace The Perfect Car with The Relational Model and "Perfect Car" Implementations with {Oracle, MySQL, etc.}. You can replace "New Perfect Car Models" (including "Without Significant Scientific Background") with {XML, OO-DBMS, 'Persistence Layers', etc.}.
No one is saying that you cannot use SQL products or XML, or that you cannot accomplish tasks in these tools, just that when used in the context of data management they are poorly solving what the Relational Model already solved.
Because IT practitioners are poorly educated and increasingly fad-driven they latch onto non-solutions (like XML, "Post-Relational", OO-DBMS, etc.) and put little or no pressure on DBMS vendors to get it right. Even worse, if someone does release a Truly Relational DBMS there are no guarantees that anyone will buy it due to the ignorance of the IT community.
Put simply: People don't know what they're missing, so they don't know to ask.
The first thing I thought of was that they were going to start sending XML down the line.
Imagine that horror:
<message sender="Titanic">
<word>
<char>dot</char>
<char>dot</char>
<char>dot</char>
<char>space</char>
<char>dash</char>
<char>dash</char>
<char>dash</char>
<char>space</char>
<char>dot</char>
<char>dot</char>
<char>dot</char>
</word>
</message>
And, of course, there is nothing stopping you from using your AGP in conjunction with the rest of your PCI slots (or all PCI-slot multi-displays), either. Before multi-head cards were common I used to have an AGP plus two PCI cards for triple displays.
I bought two Iiyama 17" 4315s a couple years ago after Tom's Hardware rated them the best 17" they've ever seen. You can get them for about $550USD which is a far better deal than the $750 they were when I got em!
They are truly fantastic LCD displays!!
Dijkstra has a few things to say on the topic as well:
On Education, Specifically:
And then on Computer Science in general:
Sure, *I* can. But XML isn't for humans to read -- it's for computers to talk with, right?
A computer cannot figure out semantics from that -- as far as a computer is concerned it's simply a string of ASCII characters.
To the receiving PC, it might as well be:
<aabb ab="42"><ffff>John Doe</ffff><yyyy>Hey Bob</yyyy></aabb>
I'm pretty sure, in the case of IM, that network issues are quite important. When you consider the potential client base (tens of millions of IM users) network message size is of CRITICAL importance.
I would be willing to BET MONEY that the IETF sat down with XML in mind and did NOT critically evaluate the suitability (or not) of XML before deciding the protocol.
A, yes true, but does it really matter? As others have stated, you don't ALWAYS need to have extremely small, efficient, fast, etc. code/programs/information/etc.
WHAT!?!?!? Since when is it acceptable to WASTE computing resources JUST BECAUSE? You certainly are not someone who has to manage any sort of large-scale system (be it a network, or a DBMS, or a render farm, etc.).
We're talking about a protocol that, potentially, tens of millions of people will be using. I think it would be important to CONSIDER optimization.
XML has been PROVEN to be a superfluous format, one which poorly or incompletely solves problems which have already been solved.
The whole advantage of XML is that someone wrote a library for it? AND there are no such libraries for ANY other protocol? Please.
Whereas IM is WHOLLY made up of time-sensitive (I'd not call IM 'time critical', but close) network transactions (aside from idle clients, but in that case the format could include 10MB of junk and not matter).
Just because XML parsers already exist doesn't mean XML is better. It means someone spent a lot of time parsing a poor language. Hey, Google has an Esperanto translator, let's all start authoring our web pages in Esperanto!
How is XML self describing?
"WEFSAFD" was random frustrated keyboard mashings.
You say "Computer readability" then you mention an example of someone opening the file and looking at it.
As an API developer I would care what the physical structure of a file is only because I'm writing functions to write to these files. As an application developer I couldn't care less; I would be working with high-level things like 'measures' and 'notes'.
The method of storage has absolutely nothing to do with it being proprietary or not. In this case, XML is both ASCII and open, in that it doesn't obfuscate the plaintext. I could easily create a non-ASCII but open (all you have to do is tell someone what it is) format, just as easily as I could create an ASCII but 'closed' format (encrypting your message to an ASCII format for example).
Further, the scenario you paint makes no sense. A computer program does not need a file to be in ASCII text to be able to understand the structure and therefore derive meaning.
The only thing remotely plausible is that someone would look at the file contents but what is not plausible is that, given a super-duper-recognizing browser, they would use a text editor and not the penultimate file browser.
We have a perfect, existing method to show human-readable notation:i f
http://www.recordare.com/xml/images/hello-world.g
Ha! XML is not a data storage format. At least it is not supposed to be a data storage format. Ask the people who 'invented' it.
o -world.gi f
m l
We have far, FAR better data storage formats (binary, etc.) for just about any purpose.
MusicXML is a horrible, horrible idea. We have a perfect way of showing a human-readable format:
http://www.recordare.com/xml/images/hell
Look at this:
http://www.recordare.com/xml/helloworld.ht
ONE NOTE!!!WEFSAFD
Is this not insane? Why does no one see this as ridiculous?
That is incredibly unethical. If I ever get your resume, remind me not to hire you. :)