Talk:SQL

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] Introduction

"The language has evolved beyond its original purpose to support object-relational database management systems." Is this correct? I read this as though the original purpose of SQL was to support object-relational DBMS's. I thought it was for relationals DBMS's and OODBMS's are a recent addition.

Am I mis-reading it or am I incorrect in my SQL history?

Thanks --Doc0tis 22:03, 14 December 2005 (UTC)

Don't know. See this reference on it: ChiMu Corp. - Foundations of Object-Relational Mapping DBBell 19:51, 15 December 2005 (UTC)

You are right, it should be "...support relational database management systems." I'll change it. Pukkie 07:27, 6 September 2006 (UTC)
Perhaps "The language has evolved beyond its original purpose of supporting relational database management systems to support object-relational database management systems" is closer to the original intent, and contains both intended original pieces of information, if it is rather unwieldy. Perhaps "The language has evolved beyond its original purpose of supporting relational database management systems and now supports object-relational database management systems as well"? J A Treloar 83.146.21.253 18:18, 1 February 2007 (UTC)
I've bitten the bullet and changed it J A Treloar 83.146.21.253 18:27, 1 February 2007 (UTC)

[edit] a "programming language"?

Should we really call it a "programming language"? AxelBoldt

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)
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:
  1. set-based (vs. array-based or logic-rule-based, for example)
  2. declarative (vs. imperative, that is, it does not rely on a state and a series of steps to change that state bit by bit)
  3. 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

http://www.c2.com/cgi/wiki?SqlFlaws - Discussion of possible SQL flaws

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)

[edit] 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)

[edit] 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

[edit] "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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Who was first and whose great idea was it?

The dates for the System/38 were relatively easy to find. All I can find for Oracle is summer 1979, including on the Oracle web site. Seems awfully fishy to me that a company that continues to use this as a selling point today, doesn't give a specific date. Doesn't really matter who was first, but if this page is going to support Oracle's claim of being the first RDBMS, shouldn't there be a date to back it up. Also shouldn't this page hightlight the fact that Oracle didn't invent the idea, but created their version off concepts being developed by IBM. Instead we get a less than correct statement about how Oracle beat IBM by two years. Also how about some statement to the fact were mainframe and Unix worlds eventually were brought on board, but it was the midrange groups (System/38-SystemR(DB2) and VAX(Oracle) that moved forward with using RDBMS systems.

Oracle claims to be the first *commercial* RDBMS. I don't think they ever claimed to be the first implementation. IBM had been doing experiments for some time before Oracle released their first RDBMS I believe.

[edit] Wrong link

Given link (http://www.dbdebunk.com/ Tutorial-D - A language by C. J. Date and colleagues) don't point to information about Tutorial-D. Please add more precise url or delete it.

Agreed - I remove the link Turnstep 18:56, 4 October 2005 (UTC)

[edit] Over-reliance on "NULLs"

The article says that one flaw of SQL is "Over-reliance on "NULLs", which some consider a flawed or over-used concept."

I can't seem to find anything in the references here to substantiate that assertion. I've met DBAs and develoeprs who use NULL inappropriately. But the author says that SQL itself is overly reliant on NULL. Can we have an example or a citation that explains how the language itself is reliant on NULL? -- Mikeblas 09:09, 30 December 2005 (UTC)

-- This is a really good question. I'd like to hear an answer myself. Scotto 09:05, 30 December 2005 (UTC)

-- Sorry, that was me. I didn't sign my comment. If we don't hear anything, I think that line should be stricken as POV and/or unsubstantiated. -- Mikeblas 09:09, 30 December 2005 (UTC)

-- I concur --Doc0tis 19:16, 5 January 2006 (UTC)

I disagree that NULLs are bad, but here's a cite: [3].--SarekOfVulcan 19:47, 5 January 2006 (UTC)

-- I was just reading the SQL page, and I would have liked to have seen more explanation about this. However I use SQL and know about NULL values, I don't know what is meant by Over-reliance on "NULLs". --Bernard François 07:47, 7 January 2006 (UTC)

  • I strongly contest the statement that NULLs are flawed or overused, in and of themselves. Is it a mistake that C and Java make references nullable by default? Yes. Is it a mistake that mainstream compilers don't statically typecheck nullable types in a safe way? Yes. There are situations in SQL and other languages where NULLs are misused or abused, but as many situations where they're useful for describing a piece of information that's, for example, present for most but not all of the records in a table. The quoted text is a sweeping generalization that should be qualified or omitted. Deco 22:04, 11 February 2006 (UTC)
    • C doesn't have references. C++ doesn't allow comparing pointers to two unlreated types, so I can't understand what you mean by compilers "don't statically typecheck nullable types in a safe way". Despite this, I agree with you -- nobody else has defended (or even explained) the assertion in the article, so I've removed it. -- Mikeblas 04:54, 26 February 2006 (UTC)
      • I assume what Deco meant by "statically typecheck nullable types" is that C and C++, unlike SQL, don't let you say "this pointer is allowed to be null" or "this pointer is not allowed to be null". I agree that the SQL notion of NULL is theoretically and quite often practically useful, because "this element's value is the empty string" and "this element has no value" are two distinct, different concepts. (Nonetheless, like any sophisticated and mildly-subtle distinction, the "NULL" versus "empty" distinction has great potential to trip up people who aren't attuned to it, leading predictably to (a) bogus code and then (b) claims that the distinction is "bad".) —Steve Summit (talk) 03:29, 13 March 2006 (UTC)

The language doesn't rely on NULL - it's just a useful abstraction. Countersubject 21:49, 16 November 2006 (UTC)

[edit] Numbering for DDL, DML and DCL

Since there are three parts withing the Data Sublanguage, they should be numbered (numbers 1,2,3 at the beginning of the title). I don't know the syntax to do this in a proper way (if there is a proper way). Can someone please do this? I think it would make the structure of the article more clear. --Bernard François 07:59, 7 January 2006 (UTC)

[edit] Is Null a cell value or a cell flag?

I have heard everybody saying that null is a value but I don't think so. Don't you think it is a flag of a particular cell rather than value of that cell. It is that flag which determine whether there is residing some particular value in the cell or not. Why we must compare a null(a flag) with a value e.g. some people say that null=any value, null>any value and null<any value yield no result. Why we would compare a cell flag with cell value. SQL has to maintain the null flag as it is the necessity of the database system. Some people say that SQL is like three valued - true, false and null but I don't agree with that fact becuase true and false is totally different from null flag. What do you say about that. I am confused about the fact whether null is a value or a flag. If somebody has thorogh understanding of the Null then discuss here please. Thanks.

Partly it comes down to definitions. I'm not a SQL expert, but I do tend to think of NULL more like a flag; it indicates that there is no value. But you do have to define how NULL participates in comparisons, because if I say "SELECT FROM foo WHERE bar > 0", we have to know what happens if there's a row where bar is NULL.
But I suspect a lot of people think of NULL as a "value", even though what it means is that there is no value.
Another way to think of it is that NULL is a lot like the NaN which appears in many floating-point representations. NaN is a special value that means "Not a Number". NaNs have several special and peculiar properties, such as that a NaN does not compare equal to a NaN. So is NaN a "value" or a "flag"? It certainly acts like a flag, and what it means is, by definition, that it is not a number. But you can also say that it's a value, albeit a special one. —Steve Summit (talk) 03:38, 13 March 2006 (UTC)
If you think in terms of polymorphism, a flag and a value get mapped onto the same concept: values which behave differently according to their dynamic definition. Cfr the Null Object Pattern Wouter Lievens 09:41, 13 March 2006 (UTC)
Null is not a value: it is not an element of any data domain. Most of the problems with Null (three-valued logic, etc.) stem from that fact. GregorB 14:32, 16 November 2006 (UTC)
It doesn't matter. Null is the absence of a value, or "unknown." Whether the database engine implements this as a special value ( which SQL Server seems to - it does a constant lookup when you use Is Null or Is Not Null in your query ) or as a flag decorating the value. What matters is that it's logically consistant, not how it's physically implemented inside the black box. DigitalEnthusiast 19:29, 22 December 2006 (UTC)

[edit] SQL is not a relational database

SQL is not a relational database according to the relational database model.

-- Leandro GFC Dutra 13:21, 18 April 2006 (UTC)

You're right, SQL is not a relational database. It's a language for using relational databases. Goplat 04:09, 15 April 2006 (UTC)
Double wrong. SQL deals with merely SQL databases. The ISO SQL standards do not even use the relation word anymore, because it does not apply in any meaningful, precise sense.
--
Leandro GFC Dutra 13:21, 18 April 2006 (UTC)
SQL may not be relational if you're using a strict definition, but most people consider it to be close enough to be called relational, and the differences have practical reasons behind them. Goplat 18:01, 18 April 2006 (UTC)

[edit] SQuirreL

The page currently claims that "SQuirreL" is a popular alias/pronounciation for SQL. I have never heard it before, but then again, I live in a country where English is not the main language. How can the claim be verified? If it can't, shouldn't it be removed? TroelsArvin 13:57, 21 May 2006 (UTC)


I live in Canada (Toronto Area) and have never heard SQuirreL either...--65.93.236.218 17:31, 14 July 2006 (UTC)

never --207.54.103.130 18:05, 23 August 2006 (UTC)

I think it's a secret Countersubject 21:40, 16 November 2006 (UTC)

One of my (ab)users terms it SQuirreL. J A Treloar 83.146.21.253 13:13, 6 February 2007 (UTC)

[edit] Added pronunciation notes to lede

I noted an oddity about "a/an SQL" in the linguistics article clitics, then decided that it was noteworthy here as well. MaxEnt 04:37, 12 June 2006 (UTC)

[edit] Misplaced Voltaire reference, but to what extent?

I thought about revising the paragraph with the Voltaire reference to read:

One joke about SQL is that "SQL is not structured, nor is it limited to queries, nor is it a language," (which recalls Voltaire's remark that the Holy Roman Empire was "neither holy, nor Roman, nor an empire.")

(which is how Gibbon quotes it, IIRC), but it really seems like a kind of pointless reference. Those who recognize it will recognize it without wikipedia's help and those who don't probably don't care to be distracted by links to Voltaire and the Holy Roman Empire while learning about SQL. So it occurred to me to remove it entirely but I'm not sure about that. Anybody else have any ideas on this or feel strongly enough to go ahead one way or the other?

Anyway - either way, its appearance as a displaced afterthought tacked onto the end of the paragraph isn't good.

It would be awful if someone who was trying to learn something about databases accidentally learned something about Voltaire or the HRE, wouldn't it. Next thing you know, people will become well-rounded. Kaleja 05:27, 29 September 2006 (UTC)

[edit] "Cartesian Join"

The article makes reference to something called a "Cartesian Join," which isn't properly linked or explained. It's a very jargon-ish sounding term, and if it's not explained within the article, then it should be linked to someplace where it is explained in full. I can't even find another article that uses the term, though. The closest thing I can find is a mention of a Cross Join on the main Join (SQL) page, which apparently is a join that returns the Cartesian product of the two tables (as opposed to an inner join or outer join), but it's not clear if that's the same as a "Cartesian Join." I think that's what's meant by 'Cartesian Join,' but I'm not sure enough that I want to link it. This is confusing and should be cleared up by somebody familiar with the topic. If a "Cartesian Join" is the same as a Cross Join, then it should be linked that way (or the 'cartesian join' term should be replaced with 'cross join,' and the latter linked to an explanation). Anyone want to fix this? --Kadin2048 17:32, 2 August 2006 (UTC)

The term "cartesian product" is fairly common. I've never heard "cartesian join" from a reliable source. "Cross join" is an SQL feature which performs a cartesian product. --Craig Stuntz 18:43, 2 August 2006 (UTC)
A cartesian join is the same as cartesian product. That's what they called it in my DB class at college. --Doc0tis 18:10, 23 August 2006 (UTC)
Oracle's Explain Plan on a query resulting in a cartesian product describes its operation as a 'Merge Join Cartesian', so that's almost a "Cartesian Join". -anon
A cartessian join is an exploding join. These articles shouldn't be written by people unfamiliar with the sources. Edited, yes, because the article should be understandable by all ... but this would be a little like me telling a contractor I don't believe that bricks exist. Select * From Table_A Join Table_B is an inner join, even though the query doesn't explicitly say so. The same is true of cartessian joins. They're usually implicit, and most often by accident. Other than creating test data, there's very little real need to pair every combination of values from two ( or more ) lists. DigitalEnthusiast 23:54, 21 December 2006 (UTC)
I believe that a Cartesian Join is shorthand for "a join that creates a Cartesian Product". I find the two separate links to Cartesian Product and to Join (SQL) irritating. I would find a new article on "Cartesian Join" or a parenthetic note, more to my taste. However, if no-one agrees with my belief that Cartesian Join is a shorthand, and it is impossible to verify then my irritation must remain. J A Treloar 83.146.21.253 18:13, 1 February 2007 (UTC)

[edit] Designer credit in the infobox?

Why does Codd get designer credit? He didn't author the language, just the concept of an RDBMS. If I write a new access language for an RDBMS, is he also the Designer?

Also, how come IBM gets credit, while the actual authors of the paper do not? —The preceding unsigned comment was added by Vonfraginoff (talk • contribs) .

I agree on both points. --Craig Stuntz 15:58, 20 September 2006 (UTC)

[edit] comparison with fourth-generation programming languages

The article says that questions like 'Who had the top ten scores?' are more difficult to program in SQL than languages like SAS.

With the introduction in ISO SQL 2003 of window functions ROW_NUMBER() and RANK(), I believe this question becomes a lot easier in SQL. Would it be worth mentioning this? Lincoln Hannah 04:43, 19 October 2006 (UTC)

Yes, but that doesn't help if you're using SQL Server 2000. Version 2005 ( aka 9 ) allows this, and Oracle has provided RowNumber since forever.
The question is flawed, though. It could be easily answered in SQL: "SELECT TOP 10 * FROM HIGH_SCORES;". What would be very difficult in SQL without ranking functions ( or pre-crunched data ) but very easy in a procedural language like VB or C# would be "Who had the 10th highest score?" SQL works in result sets and without resorting to complicated tricks like nested subqueries or cursors, this would be easier done by hand than in SQL. DigitalEnthusiast 23:58, 21 December 2006 (UTC)
select * from high_scores order by score desc limit 1 offset 9 - that doesn't seem overly complex. MichaelSpeer 19:49, 31 January 2007 (UTC)

[edit] The language syntax is rather complex

"The language syntax is rather complex (sometimes called "COBOL-like")" Do people actaully think this? I have never heard anyone say this. It seems simple enough to meDoc0tis 17:58, 2 November 2006 (UTC)

It depends on where people are coming from. Non-programmers aside, those with a background in procedural languages can initially find declarative languages difficult - it's the paradigm-shift thing. However, I wouldn't expect a BNF grammar for SQL to be intrinsically more complex than one for, say, Java or C#. Countersubject 23:50, 2 November 2006 (UTC)
Perhaps we could say something like, "The grammar is complex (per BNF grammar specification) and in many ways resembles COBOL's key-word based syntax. Some argue that this makes it more English-like and thus "natural" such that it is easier to learn and read; but may also make interpretors or compilers more difficult to write, less conducive to automatic SQL generation, and more difficult to be DBA-extendable." {Anonymous Donor}
I'd strike the sentence. I've never heard anyone who's become comfortable with the paradigm call the syntax complex (or COBOL's, for that matter). Purely on syntax I'd say it's less complex than C/C++ (the pointers) and Perl, though more complex than Fortran or Prolog.--Rudd73 22:13, 13 November 2006 (UTC)
Done Countersubject 08:46, 14 November 2006 (UTC)
SQL has what, 25 keywords? I can point out two or three people who find tieing their shoes rather complex, but that doesn't make it encyclopedic! DigitalEnthusiast 00:01, 22 December 2006 (UTC)

[edit] Whitemarsh copy of SQL:2003

I dont think it is appropriate for Wikipedia to link to the late draft available at http://www.wiscorp.com/, as the copyright status of this is not stated, and as a result wikipedia may currently be subverting copyright:

“ A late draft is available as a zip archive from Whitemarsh Information Systems Corporation. The zip archive contains a number of PDF files that define the parts of the SQL:2003 specification. ”

John Vandenberg 07:08, 15 November 2006 (UTC)

Are you suggesting that a link to a copyrighted resource 'subverts' copyright? In that case google, wikipedia and a plethora of other sites have some serious law suits coming their way.--Grimboy 18:13, 27 November 2006 (UTC)

[edit] Removing [allegedly] untrue information

From the criticism section, I've removed the following bullet points, because either they're not true, or they're opinion, which really doesn't belong in an encyclopedia. Saying "update vs insert syntax is confusing" is like saying "Megan is really hot." The syntax is well documented, well known to many, and like riding a bike. The other three, however, are simply untrue for the vast majority of SQL databases, and the ones a person is most likely to find themselves using. I've added reasons why this is untrue in parens after each statement I've removed.

  • It does not provide a standard way, or at least a commonly-supported way, to split large commands into multiple smaller ones that reference each other by name. This tends to result in "run-on SQL sentences" and may force one into a deep hierarchical nesting when a graph-like (reference-by-name) approach may be more appropriate and better repetition-factoring. ( This is the reason views, stored procedures, and functions were created - SQL is logic and data centric, not pysical implementation centric. ) Yes, but one needs special previlages to do this, and often such a needs is a one-query use rather than something that needs to muck up the permanent SP list.
  • For larger statements, it is often difficult to factor repeated patterns and expressions into one or fewer places to avoid repetition and avoid having to make the same change to different places in a given statement. ( This is what "User Defined Functions" aka "UDFs" were created to address. )
  • The difference between value-to-column assignment in UPDATE and INSERT syntax is puzzling and confusing to many.
  • The language cannot easily be extended by programmers or DBAs. Although some variations allow the addition of functions, the functions can only take scalar values and not tables (real or virtual) as arguments. The archaic syntax (above) may be part of the reason for this. ( This is simply untrue, at least in 2006. SQL Server, Oracle, and MS Access, the three RDBMS solutions I've used, all provide UDFs ( via VBA with MS Access ) and Stored Procedures ( although Access implements them as macros that fire off a series of independant queries ). ) —The preceding unsigned comment was added by DigitalEnthusiast (talk • contribs) 00:20, 5 December 2006 (UTC).

Allegedly? Is the sky allegedly blue? Does gravity allegedly pull people downward and prevent us from flying off into space? Although knowledge of SQL is a bit more specialized than knowledge of gravity, both Newton's theory and what I wrote are true. ( Although Newton's math has been updated some. ) Anybody who has worked much with structured query language will recognize that these are more than allegedly true, just as any biologist will tell you humans need to breathe air to survive. This is just good old-fashioned common sense. DigitalEnthusiast 22:41, 18 December 2006 (UTC)

[edit] Formally

Are there any sources for the claim that pronouncing SQL like sequel is "less formal" than pronouncing it like S-Q-L? Claims about formality are difficult to establish neutrally, so it seems dubious, and I have a mind to remove it unless some citation can be provided to back it up. Nohat 03:46, 12 December 2006 (UTC)

It is less formal by definition, because the letters read "SQL" not "sequel". People only pronounce it "sequel" because they hear other people pronouncing it that way, and in turn those other people only pronounce it that way because of the history behind the acronym. Otherwise it could just as easily be pronounced "squeal", "squall" or any number of other, better words than "sequel". 24.6.99.30 14:28, 14 December 2006 (UTC)
JPEG is pronounced "jay-peg" not "J-P-E-G", and there is nothing "informal" about that pronunciation, so this argument seems a little weak. Are there any verifiable, reliable sources that describe the pronunciation "sequel" as "informal" or "less formal"? Nohat 02:53, 25 December 2006 (UTC)

[edit] Removing "original research" / garbage (AGAIN)

The text below had to be removed.

Different syntax between UPDATE and INSERT is for good reason, if the complainer would take then 15 minutes required to learn. SQL is one of the simplest computer languages in existance, but as will all languages, some learning is required.

The rest is a rant and original research that has no place in an encyclopedia. And one of the most absurd example cases I've ever read. If a person wants to fill two printed pages with complains about "typo finder" queries being difficult, Google Blogger is a much better soapbox than Wikipedia.

DigitalEnthusiast 00:18, 22 December 2006 (UTC)

Garbage that needed to be disposed of:

'The difference between value-to-column assignment in UPDATE and INSERT can result in confusion and added work for automated SQL code generation modules.

It does not provide a standard way, or at least a commonly-supported way, to split large commands into multiple smaller ones that reference each other by name. This tends to result in "run-on SQL sentences" and may force one into a deep hierarchical nesting when a graph-like (reference-by-name) approach may be more appropriate and better repetition-factoring. (Views, and stored procedures can help with this, but often require special database privileges and are not really meant for single-query usage.) Here is an illustration for a "typo finder" query: Sample Table "codeTable"

locat code descript

---- --------

10 AA Foo Bar 20 AA Foo Baar 30 AA Foo Bar 10 BB Glab Zab 20 BB Glab Zab ...etc... Sample Query to Find Data-Entry Errors

select * from codeTable where locat not in (30, 50) and code not in

 (
  select code
  from 
    (select code, descript     --(gets unique code-and-descript combos)
     from codeTable
     where locat not in (30, 50)
     group by code, descript
    )
  group by code
  having count(*) = 1
 )

order by code, locat Here we have a table of codes in which we want to find and study typos in the descriptions that are supposed to repeat for each location. For example, the second row in the sample data has the typo "Baar". (Perhaps the repetition is bad normalization, but sometimes one has to deal with such data from old systems.)

In this case we want to ignore codes from location 30 and 50 because we know they are not being used right now and thus we don't care to inspect them. To do it properly, we have to apply the filter in two different places. A language which can create a temporary sub-query and then reference that sub-query by name would result in better repetition factoring, reducing the number of places that the filtering criteria have to be applied or changed, such as if we have to change the location exclusion list. Hypothetical fix:

select * into $temp from codeTable where locat not in (30, 50); -- select * from $temp where code not in

 (
  select code
  from 
    (select code, descript     --(gets unique code-and-descript combos)
     from $temp
     group by code, descript
    )
  group by code
  having count(*) = 1
 )

order by code, locat; Here the name "$temp" is a temporary or virtual table that is used only by this group of queries. The list of exception locations only has to be kept in one place. The difference is not significant for this example, but if the filtering criteria (WHERE clause) is complex then the difference becomes significant.

[edit] Strongly typed?

The infobox says that SQL is strongly typed. As I understand it, that would mean that you'd have to explicitly convert among various numeric types or strings of different lengths. However, no implementation that I've used (Sybase, MS, MySQL) requires this. Indeed, they provide implicit conversion of strings into dates! But I'm a professional, not an academic, and perhaps I'm wrong, so I thought I'd bring up the point first on the talk page. If nobody convinces me otherwise, I'll change it to weakly. Matchups 21:05, 9 January 2007 (UTC)

No, your interpretation is not right. Strongly typed languages can (and generally do) do implicit conversions, they just can't do them blindly. If a language knows how to convert, say, an integer to a string, it can insert code do do that when it compiles and still be considered strongly typed. What it can't do is simply assign the integer to the string variable without doing a sensible conversion first (e.g., it can't just treat the integer value as an untyped pointer). I doubt you'll find a single strongly typed language which doesn't have at least a few implicit conversions. Pascal, the classic example, certainly does. --Craig Stuntz 21:43, 9 January 2007 (UTC)
I looked at the article on strongly-typed programming languages and it says that we're both right, and so are another half-dozen interpretations. In other words, the statement that SQL is strongly typed has virtually no information content, and should therefore be removed from the article. Matchups 16:57, 14 January 2007 (UTC)

[edit] Too Technical

Not being a computer technician, I find this article too technical. Most of it doesn't mean anything to me. I laud the technical detail that some users could extract, but I would really appreciate it if someone could have a go at putting in some computer bunny language? Say the reader is a novice thinking about hosting a wiki, understands well enough what wikis do and how to edit them, but knows very little about how they are actually, technically, constructed. That user finds out that one needs a SQL relational database, wonders what one is, and before long, winds up on this page. Is this page going to be of any use to that reader at all? I contend it is not - and I am exactly such a user. ElectricRay 22:58, 9 February 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../s/q/l/Talk%7ESQL_5dd7.html"