Talk:SQL/Archive 1

This is an archive of past discussions about SQL. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

a "programming language"?

Should we really call it a "programming language"? AxelBoldt 10:37, 13 March 2002 (UTC)

Yes. Not only is SQL a programming langauge, it is turing complete. And really, it is a lot closer to structured programming languages (C, VB, etc.) than some functional langauges like LISP Grauenwolf 06:11, 1 October 2006 (UTC)

Show me an SQL statement which, starting from an empty database, takes a natural number n as input and produces the n-th prime number as output, and I'll eat my MySQL server. AxelBoldt

I don't know enough about SQL to know if this is what you're after, but how about this? Kaleja 05:23, 29 September 2006 (UTC)

Nice challenge, Axel -- lemme think about this for a while -- User:ClaudeMuncey

Nice? You have a better chance of winning the lotto twice in a row. — danakil 17:00, Sep 5, 2004 (UTC)

Here is an example using MySQL: [1] Grauenwolf 06:11, 1 October 2006 (UTC)

Are you done yet? :-) SQL is certainly not computationally complete, even if you take into account that it can do a little arithmetic and even if you add some kind of recursion. That's why for programming it is usually extended with programming language construct such as in PL/SQL which I would call a programming language. So I suggest we move it to SQL query language or just SQL if there is no other SQL in Wikipedia. -- Jan Hidders 14:33 Jan 22, 2003 (UTC)

SQL/PSM, which is defined by the SQL standard as part of the language since 1999, formally defines the previously vendor-specific control-of-flow and other elements of PL/SQL, T-SQL, etc., that make it what you would call a "programming language". SqlPac 18:54, 8 June 2007 (UTC)

I agree with the suggestion to move SQL programming language to just SQL. --Hirzel Jan 22, 2003

The page currently states that "As such, it is a set-based programming language". And nothing on http://en.wikipedia.org/wiki/Programming_Language prevents SQL to be called a programming language (the page even lists SQL among the "Major programming languages"), although a very declarative and domain specific one. Now, http://en.wikipedia.org/wiki/User:Danakil claims that SQL cannot be called a programming language, see http://en.wikipedia.org/w/wiki.phtml?title=SQL&diff=0&oldid=5653966 I suggest that we accept SQL as a programming language until someone writes up a proper wiki page about query languages. TroelsArvin

Programming language does not currently exclude non-programming languages because that article is in the process of a major rewrite and this has had rather unfortunate effects on the malleability of the current text. It should be fixed soon. SQL is a:

set-based (vs. array-based or logic-rule-based, for example)
declarative (vs. imperative, that is, it does not rely on a state and a series of steps to change that state bit by bit)
query language (vs. programming language, that is, there are many things it cannot do... such as making User:AxelBoldt eat his MySQL server—see above)

All three of the former characteristics are orthogonal, i.e., you could have one without the others. — danakil 16:48, Sep 5, 2004 (UTC)

You also have to make a careful distinction between the relational calculus as a general method in set theory and the various versions of SQL (no matter how much we love/hate/tolerate it). Chris Date has nearly made a career in recent years pointing out the deficiencies in SQL as an implementation of either relational calculus or algebra. User:ClaudeMuncey

Flaws

http://www.c2.com/cgi/wiki?SqlFlaws - Discussion of possible SQL flaws —Preceding unsigned comment added by 67.73.12.204 (talk • contribs) 04:59, 30 July 2003

Full name

The spelled-out name is 1000x less common than the initials (according to google), and the initials don't have any other common meanings. I think the full name should redir to the initials. Any reason not to? Stan 19:52, 23 Oct 2003 (UTC)

I'm surprised it wasn't moved there already. You certainly have my vote. Jan Hidders 15:41, 24 Oct 2003 (UTC)

Done. Hopefully the next person to get the urge to move it back to the spelled-out name will see this bit of the talk page and reconsider. :-) Stan 17:15, 24 Oct 2003 (UTC)

vendor lock-in?

From the article:

SQL code can rarely be ported between database systems without major modifications. Most people in the field believe that this lack of compatibility is intentional in order to ensure vendor lock-in for proprietary database systems.

Is this really true? Are there any references to back up the "most people in the field..." assertion? I think there are some equally plausible reasons for the lack of compatibility between implementations of SQL:

SQL is very large (the spec is 1500+ pages) and complex; it's also ambiguous in places and difficult to understand. Even understanding what is standards-conformant behavior can be tricky in some situations.
Database vendors tend to be conservative about making backward-incompatible changes. Since many vendors already implemented some features (say, stored procedures or sequences) in one way or another before they appeared in the standard, it can be difficult to migrate from the vendor's implementation of the concept to the standards-compliant implementation.
Databases are extremely complexes pieces of software, and the ability of any standards document to allow for easy portability between different database systems is limited (the large swaths of functionality that are treated as implementation-defined by the SQL standard is one major example of this). So blaming the poor state of compatibility solely on vendors (and worse yet, claiming that it is an intentional decision on their part) doesn't seem to be telling the whole story.
It may be possible to write Vendor-neutral SQL, but one generally has to go out of their way to do it, and it may result in code more verbose than vendor-specific code. For example, some dialects ignore case (capitalization) when comparing, while others don't. If you want generic SQL, then you have to convert case for potentially every comparision done, resembling: WHERE UPPER(FOO) = UPPER(BAR)

-- Neilc 06:40, 30 Jul 2004 (UTC)

Acronym or not?

Different sources give different definition of the "SQL" name:

Some claim that it stands for Structured Query Language, and that's also what the page currently indicates in the first paragraph.
Some claim it's recursive acronym, short for SQL Query Language.
Some claim it's not an acrynym at all (that the three letters aren't short for anything else).

I can't find a definite source (did a superficial search in part 1 of SQL:2003). Can somone else? TroelsArvin

The difinitive authority on SQL is NIST. Look up the acronym of SQL at [2] and you will see that it stands for Structured Query Language. Since this fact seems obscure to at least one person, perhaps we need a history lesson on where SQL came from, and who now has administrive authority over defining what is, and what is not, SQL. KeyStroke

According to Melton/Simon: SQL:1999:

NIST is not involved in the SQL standard any more (page 842), so they cannot be regarded "definitive authority" of SQL.
About the transition from SEQUEL/2 to SQL: "No doubt, this is the source of the popular belief that SQL stands for Structured Query Language" (page 24)

One of the authors (Melton) of the cited book was editor of the SQL-92 and SQL:1999 standard-revisions, as well as the U.S. representative in the related ISO/IEC committee.

In short, I believe that Wikipedia currently contains a factual error about the "meaning" of SQL. I assert that SQL officially has no mening, although a strong urban legend equates it with an acronym for "Structured Query Language".

- Oh, and in [| A Guide to the SQL Standard], it's explicitly stated that SQL officially isn't an acronym for anything.

TroelsArvin 14:33, 6 Dec 2004 (UTC)

In DigitalEnthusiast's Rants it's made clear that Structured Query Language isn't really an acronym at all - it originated when a a bunch of drunken programmers mispronounced "SoCal," a term for Southern California, where they wanted to go surfing.

Seriously, people, we might as well be arguing whether there really is a moon. DigitalEnthusiast 23:32, 21 December 2006 (UTC)

It is not an acronym. I thought so too, but I recently looked at an O'Reilly Press book that said anyone that says it is an acronym is flat out wrong. SQL is short for SEQUEL, the orginal name for the language. According to the O'Reilly book, Codd released his paper on relation databases, and presented a language called DSL/Alpha. "IBM comissioned a group to build a protoype... created a simplified version of DSL/Alpha that they called SQUARE. Refinements to SQUARE led to a language called SEQUEL< which was, finally, renamed SQL." -Senecarr

So if you shorten USA to US, it no longer stands for United States? Or conversely, does adding letters to an acronym invalidate the original letters, such that DDR-RAM stands for Double Data Rate RAM, where the RAM no longer stands for anything? The fact that the acronym was shortened doesn't mean it's no longer an acronym. Along the same lines, it doesn't really matter if ANSI or whatever other standards body claims that it doesn't officially stand for anything -- the fact of the matter is that it was created with a meaning and that meaning is (rightfully) preserved by tradition -- to claim otherwise is revisionist and just plain false (see DVD as another example -- the current standards would have us believe that it doesn't stand for anything). It's something that people, like the author of your book, sometimes do to revel in technicalities when they are able to present "facts" that are only true in an arbitrary, trivial sense, such as non-recognition by the current standard.24.6.99.30 14:11, 14 December 2006 (UTC)

To futher confuse the issue "The Complete Reference SQL second Edition" (McGraw Hill, Osborne (c)2002) calls it an abbreviated for "Structured Query Language". Something tells me we will never be able to say without a shadow of a doubt that this is or is not an abbreviation. - Nathan

"Problem" of INSERT and UPDATE

The article currently states that the following is a problem in SQL:

"The syntax of INSERT and UPDATE differ, which can be difficult to work with."

I don't see why that's a problem, and it's not criticism that I've seen in commonly expressed in literature. At any rate, I wouldn't consider it big enough to be mentioned in an encyclopedic article (could fit well into someone's weblog, though). Am I overlooking something important? TroelsArvin 14:05, 6 Dec 2004 (UTC)

Personally, I just think it was someone's rant. I edited it, because I suppose I cna see it being annoying... but, no, I do not believe it's really a valid criticism.

For one, it makes SQL confusing to learn. Second, often in web applications one may want to use the same programming code for INSERT and UPDATE so that an "add" screen can use much the same code as an "update" screen. However, the syntactical difference complicates such reuse.

I've written many web applications, and I agree that it's very nice in most cases to have the same user interface element ( normally a page ) process adds as well as changes. However, you can EASILY do this, either through dynamically generated SQL constructed on the web server, simply by adding an IF statement where you build the SQL query. Even better is to use a stored procedure that interacts with the base tables, checking for existance and then calling either the insert or update statement within a transaction. —The preceding unsigned comment was added by DigitalEnthusiast (talk • contribs) 00:14, 5 December 2006 (UTC).

I would suggest changing the "possible criticisms of SQL" to simply, "Criticisms of SQL". That removes the feeling that even minor criticisms could be put there as well. Following that, I think I might rewrite it as follows:

The various implementations of SQL listed above tend to differ in syntax and optimization, making it difficult to write queries that run anywhere.
The overall syntax is, in cases, more complex than it needs to be.
Code cannot exactly be compiled, depending on the implementation, meaning that a program using SQL will have SQL strings throughout it.
NULLs are used extensively throughout SQL, but are considered by many to be a flawed or overused concept.

I'm not sure if this is really better, but I've added one you may not agree with - I'm not sure how best to word it, but the basic point is that if I wanted to write a C program that used MySQL, the best way for me to do this would be to have the queries as strings (uncompiled.) This is somsething I know has been criticized before. However, the point about "run-on SQL sentences" makes no sense to me, because you have VIEWs, FUNCTIONs, sub queries, and various other methodogolies to conflict this.

Further, I changed the order to what I (again, personally, and this is why I'm not changing the page this second to what I typed above) feel is most important to least important. The first one is by far the worst - even inside implementations... for example, SQL may be well optimized for MySQL 3.23.x, but that doesn't mean it's properly optimized for MySQL 4.0.x. -[Unknown] 19:23, Dec 6, 2004 (UTC)

Comments:

I think your suggested rewrite is an improvement.
About your strings-in-compiled-code criticism: I think it's too product-specific to mention in a general page about SQL (embedded SQL is a rather old concept which many DBMSes offer).
About the current "It does not provide a standard way to split large commands into multiple smaller ones ..." statement: Yes, let's get rid of it; it's simply not true, especially since SQL:1999 (and DB2) which introduced the WITH ... AS construct for 'temporary' (sort-of) views.

Something which I think is missing among the criticism points: The stanards-development is very closed. I.e., I've never seen anyone from the SC32 WorkGroup on any public discussion forum/newsgroup (I've often had the desire to ask someone authoritative how something specific in the standard is to be interpreted, but there is nowhere to go for answers). I've never seen them ask for public comments, or comment on the discussions they have. I believe that this is rather different from - e.g. - the C++ standardization process. But that might just be me.

TroelsArvin 19:43, 6 Dec 2004 (UTC)

Template:Cleanup-technical

Template:Cleanup-technical or {{cleanup-technical}} What's the practicality for the use of this template? Isn't the evaluation of what's too technical going to vary by each individual reader? For example, if I (as a non-principal author) can understand the content of an article, is that grounds enough for removing it, or do we have to put it to a vote every time we want to remove such a tag? I'm also unclear as to the overall intent of such a tag. Is this supposed to create pressure for evolving towards a "Wikipedia for Dummies" authorship style? - Bevo 15:10, 22 Mar 2005 (UTC)

At the very least, the overview at the top of the article should be comprehensible to someone who does not have a background in the subject. It's changed a bit since I put that template in place, but it could still use some clarification (e.g., what the hell is the "Third Manifesto" and why is it so important that it goes on top?). It's not intended to create a "Wikipedia for Dummies", nor is it intended to keep technical information out of wikipedia; but it does need to at the very least move from general to specific and provide for those who are not computer scientists to have somewhere to start. siafu 19:25, 22 Mar 2005 (UTC)

Data transaction and Data retrieval?

I'm not so sure these ought to be seperate sections. My understanding is that they're properly a part of DML and DCL. Any objections? DanP 00:01, 2 Jun 2005 (UTC)

Yes!! I object! Data retrieval and projection ( SELECT ) and Data Manipulation Language are two very different things when mastered. Many custom software packages that include transactional and reporting functions have language in their contracts saying that performance targets apply only when no reports are running. DigitalEnthusiast 23:35, 21 December 2006 (UTC)

Merging pages

We seem to have multiple pages for different topics about SQL. Shouldn't these be merged into this article?

The articles I think should be merged are:

Before I do something like this, can someone perhaps give reasons why I should not do this? - Ta bu shi da yu 7 July 2005 03:11 (UTC)

Table (database) should definitely not be merged in. It is something that is not specific to SQL. I'm ambivalent about the others, though. -GregoryWeir 7 July 2005 20:45 (UTC)

Sounds fair. Will keep this open for a while, however. - Ta bu shi da yu 7 July 2005 23:52 (UTC)

You shouldn't do it because this article would become overly large, paqrticularly as they get expanded with differences between implementations. Could well be why they are in different places already. In the event that you go ahead, do remember to preserve the full GFDL history so this article doesn't become a copyright infringment. Jamesday 12:59, 17 July 2005 (UTC)

Personally, I'm against it. The resulting article would either be gigantic, or it would contain less content than the individual articles do now. Either result would be bad. It's not like navigating from one related page to the other is difficult, and frankly I think it's organizationally nicer to have more pages rather than less, since it makes searching easier. There seems to be this tendency on WP to get merge-happy, and I think it should be avoided where not clearly advantageous. Here, it's not. --Kadin2048 17:32, 2 August 2006 (UTC)

Merging Insert (SQL) (and others) into SQL would be akin to merging addition into mathematics. SQL is not a complex language, but the myriad nuances of each command, statement, and operator makes a good argument for segregating them into their own articles. CodeNaked 14:33, 21 September 2006 (UTC)

Structured Query Language?

I don't know why people keep mixing S-Q-L with sequel and think that it's an acronym. The official name is Database Language SQL and it's not pronounced as sequel nor it stands for structured query language. Why? Because the ANSI says so. Furthermore SQL is neither structured nor limited to queries nor a complete language. I think somebody ought to correct this common misconception. Miskin 11:33, 7 August 2005 (UTC)

Hi, Miskin. First, do you have references. Second, despite whatever ANSI or any other standards organization may propagate, many or most SQL users pronounce it sequel, becuase it flows better. And I find it very doubtful that it is not an abbreviation for structured query language. Nelson Ricardo 18:55, August 7, 2005 (UTC)

In what way is SQL not a "complete language"? (And how are you defining completeness?) As for SQL standing for Structured Query Language, the research above would suggest that SQL does not stand for anything. I'll update the article. Neilc 19:48, 7 August 2005 (UTC)

Not a complete language according to Turing's Thesis in the theory of computation, but that the least here since most commercial vendors have turned it into a complete programming language anyway. References? More than plenty. Right at this moment I can get as specific as "Chris Feihily's Visual quickstart guide to SQL" that I've pretty much been quoting. I can even quote from it exactly if you want: SQL isn't pronounced sequel; that pronunciation is a historical artifact. Avoid the error and articulate each letter S-Q-L. I disagree with people who claim that saying sequel is so common that nothing's wrong with it. You shouldn't say 'sequel' for the same reason that you shouldn't split infinitives when you write your novel; it may generally be accepted, but it will rasp on the ears of knowledgeable people. Also, pronounce MySQL as my-es-kyu-el and PostgreSQL as post-gres-kyu-el... It follows the explanation of SQL not having any relation with any 'structured query language' that I have pretty much summarised above. The ANSI defines it as Database Language SQL, nothing more, nothing less: ...Furthermore, referring to it as a "structured query language" is a disservice to new SQL programmers; it amuses database professionals and academics to point out that "structured query language" is the worst possible description, as SQL:... Miskin 09:25, 8 August 2005 (UTC)

Yeah, I'm going to listen to someone who uses split infinitives as an analogy. The rule against splitting infinitives (along with "no prepositions at the end of sentences", have long since been debunked. Just ask FDR and Gene Roddenberry. At any rate, try Googling Microsoft SQL "Structured Query Language". Nelson Ricardo 10:30, August 8, 2005 (UTC)

Well I'd rather listen to someone who's written a book on the subject and quotes the ANSI standard rather than someone who considers M$ technologies as a representative of their kind. Look up SQL in foldoc: According to Allen G. Taylor, SQL does _not_ stand for "Structured Query Language". That, like "SEQUEL" (and its pronunciation /see'kw*l/), was just another unofficial name for a precursor of SQL. However, the IBM SQL Reference manual for DB2 and Craig Mullins's "DB2 Developer's Guide" say SQL _does_ stand for "Structured Query Language" Note that this is the only instance where foldoc mentions the phrase 'structured query language', verifying that the last edits in the article were necessary. No serious source defines SQL as 'Structure Query Language' anymore, simply because serious sources tend to respect the "ANSI propaganda". Miskin 11:17, 8 August 2005 (UTC)

For arugment's sake, both books on SQL that I have beside me right now define SQL as "Structured Query Language" (SAMS Teach Yourself SQL in 10 Minutes & The Complete Reference SQL Second Edition) and I have been taught in college that it originally stood for Structured English QUery Language (hence SEQUEL). Also do a google define:SQL and you'll get many, many Structured Query Language definitions. Regardless on what the "proper" meaning (if there is any) of the acronym is, it should at least be mentioned that it was "once known as Structured Query Language" -Nathan (Nov 1, 1:10 CST)

This is probably a non-issue at this point, but there were some primary references that were not mentioned in the above thread on the definition/pronunciation of SQL, so here goes my two cents worth. I don't have the actual (expensive) SQL standard reference, but I searched the framework and foundation documents in the draft SQL93 zip archive from Whitemarsh Information Systems Corporation and there were no references to "structured query" anywhere. Apparently the SQL standard only refers to itself as SQL, never as Structured Query Language. In addition, one of the top living experts on relational databases, Christopher_J._Date, states in An_Introduction_to_Database_Systems on page 4 of the 6th edition: The name "SQL" was originally an abbreviation for "Structured Query Language," and was pronounced "sequel." Now that the language has become a standard, however, the name is just a name - it is not officially an abbreviation for anything at all - and the pendulum has swung in favor of the pronunciation "ess-cue-ell." I think together this is pretty conclusive evidence that SQL is supposed to be just an abbreviation. However, public usage and opinion need not correspond to this, and since continued "incorrect" public usage rewrites a definition to match the usage, the question becomes: "What should SQL mean?" If it matters, then public usage must be corrected when it drifts, especially with respect to authoritative sources. Where secondary sources disagree with primary ones, the general rule is the secondary sources are wrong. Unfortunately, I find that the dictionary on OS X (from Oxford American Dictionaries) defines SQL as an abbreviation for Structured Query Language. The dictionaries printed by Oxford University are about as authoritative as any secondary source gets, so it may be too late already. - Jefferys 20:49, 11 February 2006 (UTC)

I suppose this debate has a certain how-many-angels-can-dance-on-the-head-of-a-pin flavor to it. I confess I don't understand what's so wrong with pronouncing it "sequel" or claiming that it stands for "Structured Query Language". The only arguments brought forth seem to be "because it's wrong" or "because this expert says so". And the current state of our own article is nonsensical: it says "commonly, but incorrectly, expanded to Structured Query Language — see History for the term's derivation", but when you get down to the History section, you find: "Structured English Query Language ("SEQUEL") was designed to manipulate and retrieve data stored in System R. The acronym SEQUEL was later condensed to SQL". So a reader would have to conclude that, yes, the modern name is based on "Structured Query Language". I propose we change the introductory

SQL (commonly, but incorrectly, expanded to Structured Query Language — see History for the term's derivation)

to

SQL (often pronounced "sequel", based on an early "Structured Query Language")

Then, if the experts insist, we can add a sentence in the History section saying "According to experts, the name of the modern language is pronounced S-Q-L and it no longer stands for 'Structured Query Language'." —Steve Summit (talk) 03:17, 13 March 2006 (UTC)