Talk:SQL/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3

Add link

Want people to see if adding this link would add value: http://seeingwithc.org/sqltuning.html Video tutorial on how to perform SQL performance tuning with reference to Oracle This video is from me so want others to validate prior to adding. —Preceding unsigned comment added by Hardeeps (talk • contribs) 17:12, 5 August 2009 (UTC)

Pronunciation

The source relied upon for the pronunciation as an acronym states that 'it is equally acceptable to say the letters individually ... or to use the word "sequel.'" I've changed the page to reflect that there are two acceptable pronunciations. — Preceding unsigned comment added by 124.149.104.143 (talk) 09:07, 16 May 2013 (UTC)

On the MySQL page, there is a very handy pronunciation aid - that article shows /maɪˌɛskjuːˈɛl/[3] (My S Q L) Thanks GregHluska (talk) 00:06, 9 May 2009 (UTC)

It's also common for people to pronounce SQL like the word "sequel". —Preceding unsigned comment added by 194.46.228.218 (talk) 17:25, 18 August 2009 (UTC)

The pronunciation of SQL changes from country to country ("Sequel" is more dominant in the USA and "S-Q-L" is more dominant in Australia").

Another fact to consider is that the original System/R product was called "Sequel" and was renamed to SQL as SEQUEL was a trademark of the UK-based Hawker Siddeley aircraft company. It is likely that the System/R team continued to pronounce the product as "Sequel" as it is faster to pronounce that "S-Q-L"

It could be argued that since SQL was developed in the USA, the USA "Sequel" pronunciation is the correct one. —Preceding unsigned comment added by GrandPoohBah (talk • contribs) 13:20, 2 January 2010 (UTC)

  • The original SQL standard declared that the official pronunciation for SQL is "es queue el", see the article for the ref. I don't find the above arguments very convincing... anoko_moonlight (talk) 17:20, 2 January 2010 (UTC)

Both of the sources cited state that "sequel" is an acceptable alternate pronunciation, even though the first states that it is not standard. I think both should be included. 67.41.46.253 (talk) 04:47, 6 February 2010 (UTC)

Absolutely, sited sources mention both. "sequel" is definitely dominate within the United States. 96.4.3.17 (talk) 19:36, 1 April 2010 (UTC)

If noone cares, I am going to change the official pronunciation to be equivalent to that of squirrel. (From the movie Madagascar: "Definitely Squirrel's.") Fnordly (talk) 16:33, 27 June 2011 (UTC)

I should think that the fact that SELECT DIFFERENCE('SQL','sequel') returns 4 is fairly conclusive. SQL pronounces itself "sequel". — Preceding unsigned comment added by 170.117.255.2 (talk) 19:56, 4 June 2013 (UTC)

Fundamental Flaw

SQL was developed by Oracle first - not IBM, and Oracle's development work did not follow Cobb directly. In fact Oracle tended to rely on the works of the American John Best, who wrote the theories that Codd emulated and later took credit for.

This difference in development is one of the main factors in the differences between Oracle SQL and PL/SQL releases and IBM's SQL and SQL-PL releases. Fact is IBM had not released System R until after Oracle Release their DB product, so excluding the little known fact that Best had developed the theories which Cobb used as reference for "his" work, history would dictate SQL is an Oracle first. —Preceding unsigned comment added by 157.203.42.50 (talk) 10:10, 1 August 2008 (UTC)

I believe your only true statement is that Oracle had an SQL-based product on the market sooner than IBM. Rp (talk) 16:12, 3 February 2012 (UTC)

Strongly typed?

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)
SQL, at least in my experience (DB2, PostgreSQL, Oracle, Firebird/Interbase, MySQL) is indeed strongly typed although some databases (MySQL in particular) muddy the waters by including a large number of implicit conversions. DB2 is probably the strictest here - CAST() is required for explicit conversions far more than in other dialects (much to the annoyance of some users converting from other databases :-).
If there is one database which seriously calls into question whether SQL is strongly typed, it is SQLite (especially earlier versions) in which individual values have a type rather than columns. Effectively, it's dynamically typed like PHP or Python. However, given that this is one database out of many with this behaviour (and that this is definitely contrary to the standard) I believe it's entirely fair to refer to SQL as a strongly typed language. Dave 23:05, 23 June 2007 (UTC)
The creators of SQLite originally created an un-typed query language with a syntax based on (and similar to) SQL; but it's definitely not standard SQL. I haven't used SQLite in a while, but it was created originally to work as a subset of SQL for a memory-resident database on embedded devices, and it originally stored all data as strings (I believe), regardless of data type declarations used in DDL statements. The actual SQL standard, though, calls for strong typing of data (although it also calls for a lot of implicit and explicit conversions). SqlPac 02:25, 25 June 2007 (UTC)

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)

This is because the philosophy of wiki stewards is to make the content verifiably accurate, not necessarily useful, and the first priority wins out if there is a conflict between the two. I think wiki needs to split into a more formal version and a less formal version that is more democratic, even if a bit messy. Formality and "useful" are not necessarily the same.

I think, on the other hand, that we can explain this material better. SqlPac 02:12, 8 June 2007 (UTC)
Have a go? Look into English Grammar for beginners.. —Preceding unsigned comment added by 157.203.42.50 (talk) 10:13, 1 August 2008 (UTC)


Seems that if I have to change a typo in an address in that database I need to write a half page of programming. Isn't there something in between this SQL and an Excel Table? Like, something with wich I can join (or link) tables and still edit them either in a table format or "single page for singe record" format? —Preceding unsigned comment added by 109.238.72.226 (talk) 11:39, 18 May 2011 (UTC)

WP:NOTHOWTO -- Doctorx0079 (talk) 21:15, 18 May 2011 (UTC)
No, you need a single line of code. Or GUI tool, and no code. 93.87.212.7 (talk) 09:59, 3 November 2011 (UTC)

Wikipedia is not where you go to learn a programming language, as it is meant to be a technical explanation of what it is or how it works, rather than teach you how to use it effectively. It is a good place to start if you want to get a feel for what it is or what some of the code might look like, but if you want to learn any programming language/tool, you should go look for tutorials, or a book, or something from a website dedicated to the language (SQL, in this case). Although there is also http://simple.wikipedia.org (designed to explain things in simple terms), programming languages are complex and therefor have very little explanation there. Wikipedia is a great place to learn about a language, but not to learn a language. — Preceding unsigned comment added by 24.220.223.50 (talk) 04:08, 29 January 2012 (UTC)

So do you agree that the article is too technical? I do. Rp (talk) 16:13, 3 February 2012 (UTC)

Data types

Should a short table be provided in the article listing the datatypes provided in SQL? — Loadmaster 16:08, 18 April 2007 (UTC)

no because this can change between different implementations Harlock jds 16:43, 18 April 2007 (UTC)
Disagree with that reasoning. The data types in SQL are defined in the ISO/IEC 9075-n:2003 standard. Any listing of datatypes (in this article) should probably avoid vendor-specific and non-SQL-standard datatypes (or just mention that they exist and provide links elsewhere). What is the reason for not listing the datatypes defined by the standard? SqlPac 15:12, 27 April 2007 (UTC)
Methinks it was simply an oversight. There is no good reason for omitting the standard datatypes. — Loadmaster 01:46, 30 April 2007 (UTC)
I concur. There might be a valid reason for leaving out vendor-specific and proprietary datatypes, but there is no good reason for leaving out datatypes defined by the standard. SqlPac 16:21, 30 April 2007 (UTC)

Examples

Some examples could be useful. That might have the effect of making this more like a training manual instead of an encyclopedia article, but it would clarify what the commands in SQL really do, and if that also has the effect of making it a training manual, so what?

Actually now that I see the 'Gentle Introduction' link, maybe that will do...

SQL Acronym

I think we need a source for this in the intro: "Originally standing for Structured Query Language, SQL is now nominally a name with no official expansion, rather than an acronym." Thanks. SqlPac 00:05, 9 June 2007 (UTC)

We do, and I don't have one to hand. (OTOH, unsourced and correct beats unsourced and incorrect, the previous situation.) There was some discussion of the "acronym" question earlier, see elsewhere on this page. Alai 13:13, 10 June 2007 (UTC)
I don't know, Wikipedia policy Attributability and Verifiability seem to say that unsourced (correct or not) only works for items that aren't likely to be challenged. I think this is likely to be challenged. The only thing I've found is that the SQL:2003 standard specifically omits any refernces to "Structured Query Language", and only refers to it as "SQL". SqlPac 16:50, 10 June 2007 (UTC)
I agree with Steve in the previous discussion, that if we want to ssay SQL doesn't stand for "Structured Query Language" anymore according to an expert, we should quote him and source it. That, or just point out that the standard doesn't reference the expansion anymore. SqlPac 17:02, 10 June 2007 (UTC)
I think I can find a cite, just not immediately. But you at any rate you shouldn't change it back to the previous version, which just expanded SQL without a cite, or a caveat. If you're that concerned, you can remove all reference to "Structured Query Language" entirely. Alai 19:39, 10 June 2007 (UTC)
I disagree. Even if SQL is now sometimes used as a word, rather than as an acronym, that doesn't mean that its not still used as an acronym, and I believe the primary use is still as an acronym. Ask all your db friends, "what is sequel" and you'll get back "structured query language" the vast majority of the time.
If you can find a very solid reference, I think we should change the sentence to "Originally standing for Structured Query Language, SQL is sometimes now used as a name with no official expansion, rather than an acronym."
Until a solid reference is added, I think we should drop this sentence and add the acronym's expansion to the first sentence in the article. JD Lambert 20:43, 10 June 2007 (UTC)
Alai, would you agree then that if we expand the acronym with a cite ("previous version, which just expanded SQL without a cite, or a caveat."), it would be enough to satisfy you? I am that concerned, as you say. I don't believe any exclamations stating that "SQL is not an acronym for Structured Query Language" will stand unchallenged; and there are literally hundreds of sources we can locate that indicate SQL is an acronym for "Structured Query Language". I'll be happy to source that SQL is an acronym for you. The other needs to be sourced or dropped. SqlPac 22:34, 10 June 2007 (UTC)
I've added no less than five sources indicating that SQL is an acronym. I've removed (temporarily) the assertion that SQL is not an acronym. Please add it back in when you have a verifiable source. Thanks. SqlPac 23:17, 10 June 2007 (UTC)
There's something unverifiable about the C. J. Date quote? I can't find a copy of the above-mentioned sixth ed., but I can confirm the above "not officially an abbreviation for anything at all" assertion (also) appears in the 5th, 7th and 8th editions. That and the-dog-that-didn't-bark in the standards document indicate to me that "is an acronym" is, at the very least, overstated. Having said that, I did in the process go through half a shelfful of textbooks that do just silently expand it to "Structured Query Language", including Ullman et al, who were my top bet for the more pedantic reading, and no-one aside from Date makes the claim that it doesn't stand for that. (I should also have made a note of those that don't supply an expansion, but the majority do.) So one could argue that it's just one of Date's (seemingly fairly numerous, it must be said) strange notions, and that mere omission from the standard proves nothing, but I think a more secure basis to proceed would be the "commonly expanded as" formulation, or something to that effect. Anything more than half a sentence or so would be better off in the "history" section, at any rate. Alai 02:42, 11 June 2007 (UTC)
That's fine with me; that or simply state that according to Relational Management expert C.J. Date it is no longer considered an acronym, but a proper name, and add a cite to one of his editions. Unfortunately I don't have that particular book handy to make the citation myself. Date is an RM guru, but he (and most of the other well-known RM gurus) lack any serious practical knowledge about modern SQL implementation. Their knowledge tends to be comprised mostly of theoretical "this is how it should be" type knowlege and SQL implementation trivia that can be used to attack it from the fringes. I think Date is a better citation for articles about pure RM theory, Tutorial D, sixth normal form, or even to create a very hefty Criticisms section for this article. But that's just my opinion :) SqlPac 19:30, 11 June 2007 (UTC)
I've tweaked the intro; if we need a longer quote for the history section, I can provide tomorrow when the books are to hand again. I wouldn't go so far as to suggest Chris Date was an out-of-touch ivory tower type, but it's clear he has strongly-held and sometimes hotly-expressed views on some things that aren't necessarily 100% in line with what the wider DB community thinks (or variously, cares about). He seems a better quotee than Allen Taylor as paraphrased by FOLDOC, since that one isn't a direct quote, and I've never heard of him otherwise (and Wikipedia doesn't seem to have, either). It would appear that the average DB textbook mentions "Structured Query Language" exactly once, and then just says "SQL" for the remaining 1200 pages, so it has that "meaning" in at least that sense, which should obviously be documented. Alai 03:42, 13 June 2007 (UTC)
Intro looks good. As for Date, et. al., their work appears to be more concerned with theoretical Relational Management than with practical application. In many of Date and Darwen's works dealing with 6NF, Tutorial D, and basically their vision of the perfect RDBMS, they flatly state (usually near the end) that their work cannot be properly implemented given the current state of technology (a cop out? I dunno...) They tend to mention SQL only in passing, and only to criticize it. Presumably this is done to gather support for their own theories about the way things should be done.
As for the DB textbooks mentioning "Structured Query Language" exactly once, that's an editorial decision by the books' editors. I write occasional articles and contribute to books as well, and it's standard editorial practice to expand an acronym exactly once per book, to eliminate confusion for the reader. In the trade it's sometimes called "parallel construction". Consider this short paragraph, with SQL expanded to "Structured Query Language" seemingly at random:
The first version of Structured Query Language was developed at IBM by Donald D. Chamberlin and Raymond F. Boyce. SQL is a declarative language. Structured Query Language is designed to manipulate and retrieve data stored in databases. SQL has been formally standardized by the American National Standards Institute (ANSI) in 1986. Later versions of the Structured Query Language standard were adopted by the International Organization for Standardization (ISO).
The reader jumps back and forth between "Structured Query Language" and "SQL" several times in this paragraph, and it makes it a bit hard to read. It can also be confusing to someone who's new to the topic (is Structured Query Language in the first sentence the same thing as the SQL referenced in the second sentence?) So I don't think the fact that books about SQL only give the expanded version one time per book is significant. Thanks. SqlPac 15:55, 13 June 2007 (UTC)
The book "Understanding the New SQL : A Complete Guide" by Jim Melton, editor of the ISO SQL-92 standard (the book can be found on Google Books), also states: "Many books and articles "define" SQL by parenthetically claiming that the letters stand for Structured Query Language. While this was true for the original prototypes, it is not true of the standard. When the letters appear in product names, they have often been assigned by the meaning by the product vendors, but we believe that users are ill-served by persuasions that the word "structured" accurately describes the language. The letters, by the way, don't stand for anything at all. They are not an abbreviation or an acronym, merely the result of the evolution of research projects." Anoko moonlight (talk) 09:46, 18 January 2008 (UTC)
There is another book (from which I learned SQL) which states that "although most [professionals] will insist that it stands for Structured Query Language, [it does not stand for anything]". Unfortunately, I do not know which book it was offhand, but I can locate it in the future (it belongs to a family member).

Source #2 (cited for the pronunciation) states clearly that SQL is no longer an acronym. —Preceding unsigned comment added by 67.41.46.253 (talk) 04:53, 6 February 2010 (UTC)

I'd like to see this stated. "SQL... often (erroneously)[2] referred to as Structured Query Language..." made me think "So what does it stand for?" Since I don't have the book that is source #2, can you quote it here, or make the edit? —Darxus (talk) 17:53, 7 October 2010 (UTC)
The info box at the top of the article lists IBM as the developer. Citation 6 is an article from IBM whose title is "Structured Query Language (SQL)". I think IBM knows better than Allen Taylor whether it stands for something, and what it stands for. It would be more accurate to state that someone says this expansion is erroneous and who says it, rather than stating as fact that it IS erroneous, when it obviously is not. Actually, I think the erroneous assertion should be removed altogether. Skreyola (talk) 19:11, 18 October 2010 (UTC)

Many Text Books define the SQL as standing for "Structured Query Language". It seems like people are fighting to ensure that SQL is NOT called Structured Query Language, but they are not helping anyone to understand what it really stands for. It is almost impossible for a technical Acronym to not stand for anything, especially one that is used in the Science of Computing. JiuJitsuTaffy (talk) 03:54, 8 October 2010 (UTC)

In response to "what it really stands for", the argument being made is that it does not stand for anything. Apparently Allen Taylor (sourced as being the "inventor of SQL") states this, suggesting that "SQL" is just a shorter jumble of letters pulled from "SEQUEL" (which stood for "Structured English QUEry Language", and hence the irreversible association with "Structured * Query Language"). It would be as if someone wanted to call a language "BASIC", but upon finding out that the name is already in use (and not wanting to drift too far from a name people are already identifying with), that person changed the name to "BSC" (as if to be shorthand for "BASIC"). However, being a shortened form for what WAS an abbreviation, we just call it "B.S.C.", and that's the official name. HOWEVER, people already having identified it as "Beginners Advanced Symbolic Instruction Code" cannot break the association, and because of how information spreads from person to person, "BSC" becomes "Beginners Symbolic Code". IBM being a company full of people who see such a change (and old professionals who already have it ingrained in their heads) cannot see SQL and NOT think "Structured Query Language", and it being years and even decades with it being called that, this popular idea is too far spread and too present in even the most authoritative contexts to be contested. IBM, being a company full of people (and owning SQL, regardless that Mr. Taylor was the "one" who "invented" it) is going to go ahead and call it that, because (1) people (working for IBM or not) are going to keep their misconceptions if everybody is still calling it that (afterall, that's where the name came from originally). Unfortunately for Mr. Taylor, "SQL" is a DARN close acronym to the original (was this unintentional!?), so even if he went with "SEQ" it might have come out the same (Structured English Query ["language" possibly tacked on anyway]). I think what is clear is that Allen Taylor (for some bizarre reason) dropped the acronym, but IBM stuck with it anyway because people couldn't break from it. It seems more likely that people (including IBM executives) just kept calling it that than that there was an actual debate over it ... I mean, how do you tell people that "SQL" does NOT mean (exactly what the language was designed to be and abbreviated for in the first place)? You cannot; and there was no way it was going to go away. Not even by (possibly mistaken/naive to this item) IBM execs. ... All in all, people call it that, and IBM (the owner) is calling it that. It may be technically incorrect; but I think that it has also become technically true now, given the circumstances. Just as most people misunderstand what "licorice" is (i.e. NOT Twizzlers or Red Vines, though their black twists are licorice flavor (but the others are not at all)). — Preceding unsigned comment added by 24.220.223.50 (talk) 04:34, 29 January 2012 (UTC)

Whether SQL originally stood for Structured Query Language (or intended to) is now irrelevant. What is correct today is what it stands for today, and as so many authorititive sources say SQL stands for Structured Query Language, I think it's pretty clear that's what it stands for today. — Preceding unsigned comment added by Detjo (talk • contribs) 22:24, 8 April 2013 (UTC)

SQL name debate

Complete and absolute nonsense. The term SQL is most definitely an acronym for Structured Query Language. The only reason why it is hard to cite the original references is because both IBM and Oracle used the acryonm internally and not in public articles or whitepapers at the time of its creation. That is of course because their DB's were not yet released and the work was not yet complete.

The fact is both Oracle and IBM consistently state that SQL is an acronym standing for Structured Query Language - look into any of their publications and it will be there in plain print to read, not to mention Ellison, openly claims to have created the acronym. It is almost unbelievable there could be any debate on this subject. I guess next we should debate if the Sun should be called the Sun since there are no sources we can cite to prove it, that existed from the time it was named —Preceding unsigned comment added by 157.203.42.50 (talk) 10:37, 1 August 2008 (UTC)

Source #2 (cited for the pronunciation) states clearly that SQL is no longer an acronym. 67.41.46.253 (talk) 04:52, 6 February 2010 (UTC)

Whether it is a technical acronym or not, there is no question that it is often referred to as "Structured Query Language." SouthLake (talk) 13:43, 16 March 2010 (UTC)

The debate is childish. Call up Oracle and ask them what SQL stands for. Their answer will be "Structured Query Language". Do we rely on people who write "books for dummies", or do we rely on the experts who use this information everyday? JiuJitsuTaffy (talk) 03:57, 8 October 2010 (UTC)

The debate would be "childish" if it was just one person with no grounds. However, you have MANY people who are not affiliated whatsoever making a common claim. Surely, there is a reason for this, and it is worth considering. It is a logical fallacy to say that X is correct just because so many people insist that it is, when there are plenty who insist otherwise. Of COURSE an employee of Oracle would say that it stands for that, because they will have been exposed to hearing it that way. That is how ontological information is stored/retrieved in the brain ("oh, I've heard that before, and I know its directly related; so it MUST be correct!" (see "Accommodating ways of human knowing in the design of information and instruction" by Jonassen). It is the same reason that a surprising percentage of people will answer "yes" when asked if evolution theory states that humans evolved from Chimps (rather than from a common ancestor)! It is the same reason that people call any long soft candy "licorice" when in fact only the black stuff is licorice at all. (see Twizzlers or other packages, and you will find this true; and yet it's "common knowledge" ... yet, I worked vending where we sold "licorice ropes" which were not licorice at all). Having worked in a call center, people insist on all kinds of things that are "common knowledge" just by being associated with it so directly; and because these people "are" the company, it their biases project onto the company. Is a thing true just because so many people claim it is? (That's a whole other debate though, so lets leave that alone) So (1) you have clear explanation for why even BOOKS (or even "Oracle") would claim that it is "called" that (and it is _"called"_ that by people), even if it is not technically _defined_ that way, and (2) you have sources with legitimate evidence and official statements from the designers that "SQL" OFFICIALLY does not stand for ANYTHING. ... Conclusion: You cannot reject a valid argument that accounts for it all (as I have presented); but on the other hand, people WILL refer to it as "structured query language" no matter what, so let people call their candy "licorice" because 99% of anybody does so. At this rate, its an argument of technicality versus common consensus; and what is clear is that they are different things. — Preceding unsigned comment added by Shkaboinka (talk • contribs) 23:30, 28 January 2012 (UTC)

a "programming language"? (continued)

Here is a single SQL statement, without any procedural extensions like PL/SQL, that solves the challenge posed 3 years ago. This SQL was built for Oracle 10g, but you can probably write an equivalent statement in other databases: 

--Find the Nth prime number
--Must have a size limit.  You want this to be as low as possible, even if N is low.
with maxNumber as (select 999 maxNumber from dual)
select * from
(
  select primeNumber, row_number() over (order by primeNumber) N
  from
  (
    --Get a list of numbers
    select level+1 primeNumber from dual connect by level <= (select maxNumber from maxNumber)
    minus
    --Subtract all numbers that can be divided by another number
    select distinct numerator from
    (
      select level+1 denominator from dual connect by level <= sqrt((select maxNumber from maxNumber))
    ) numbers1
    ,(
      select level+1 numerator from dual connect by level <= (select maxNumber from maxNumber)
    ) numbers2
    --Even though denominator is limited above it still needs to be limited here
    --(Prevents dividing small numbers by themselves)
    where numbers1.denominator <= sqrt(numbers2.numerator)
      and remainder(numerator, denominator) = 0
  )
)
where N = 30;

Jonearles 02:27, 14 June 2007 (UTC)

Well, in MS T-SQL I supposed you could do something like this:
WITH Prime(n)
AS
(
   SELECT 1
   UNION ALL
   SELECT n+1
   FROM Prime
   WHERE n <= 100
)
SELECT p1.n, COUNT(*)
FROM Prime p1
CROSS JOIN Prime p2
WHERE p1.n % p2.n = 0
GROUP BY p1.n
HAVING COUNT(*) IN (1, 2)
OPTION (MAXRECURSION 0);
This also should translate easily to other platforms [minus the OPTION (MAXRECURSION 0)]setting and possibly changing the % modulo operator to whatever is used on the different platforms. I didn't do an exhaustive test of this, but basically it creates a list of numbers, cross joins the list to itself, and eliminates rows where the first number is not divisible by the second number. Finally it counts all the rows, grouping by the first number. To be a prime number, a number must be divisible only by 2 numbers max. (1 is a special case since it is only divisible by 1 number). Not the most efficient solution, for sure, but it gets the job done using (fairly) standard SQL with no procedural extensions. SqlPac 04:47, 14 June 2007 (UTC)

SQL DML article

This actually doesn't directly affect this article per se, but I thought I'd post here to get more feedback because odds are the people who edit this article will be more interested than others.

The idea is to combine all of the SQL DML statements (UPDATE, DELETE, INSERT, MERGE, TRUNCATE [yes, non-standard but apparently widely implemented], maybe even SELECT) into a single SQL DML article. Each of the articles mentioned above (with the possible exception of SELECT, which could be expanded greatly), is a very short stub that consists mostly of a very limited set of examples. Together they would make a decent single article. I've posted comments to all the articles above requesting feedback, but have received only a little so far:

  • One person suggested combining UPDATE, DELETE, INSERT, MERGE, but not SELECT or TRUNCATE in the SQL DML article.
  • Another person agreed that combining all was a good idea, so long as redirects were included from the original articles Update (SQL), etc.

Any additional comments, ideas, suggestions? Thanks. SqlPac 04:38, 16 June 2007 (UTC)

Sounds like a good idea to me. Personally, I would encourage keeping SELECT with INSERT, UPDATE, DELETE, MERGE etc. in any such SQL DML article. This is primarily because some databases allow one to SELECT from an INSERT, UPDATE, or DELETE operation (see Data change table references in the DB2 sub-select entry - I'm not sure if this is standard or not, although it wouldn't surprise me - DB2's usually fairly good at following the standard).
On a related note, there's a small error in the article as it stands: it states that MERGE is a combination of INSERT and UPDATE when in fact it's a combination of INSERT, UPDATE and DELETE too (see the modification-operation sub-clause of the MERGE syntax in the DB2 Merge entry). Dave 23:05, 23 June 2007 (UTC)
Hi Dave, thanks for the feedback. I agree (that SELECT should probably be included in a combined DML page), although I see the other side also, which is that SELECT isn't necessarily considered DML because it doesn't cause persistent changes in the database (MS' SELECT...INTO and possibly other proprietary extensions aside). I could go either way on it, since my main concern is that I don't think there'd be enough content to fill the INSERT, UPDATE, DELETE, MERGE separate articles with much content. I do think there'd be enough content available on SELECT to fill a good-sized article on its own though. I'm slowly editing my way down the article and haven't gotten to the MERGE statement yet, but if you spot errors like that, please feel free to Be Bold! and hook it up! Thanks. SqlPac 03:30, 29 June 2007 (UTC)
Eh, I dunno about merging. I typed in a define:group by and this page just came right up in Google. It was a very helpful and easily accessible refresher on the group by concept. Not sure if a merged article is going to be able to be indexed by Google the way this standalone is. Coreydaj (talk) 23:50, 31 March 2008 (UTC)

External link to c2, discussion of SQL flaws

Was just visiting some links from the page, and came across this one:Discussion on alleged SQL flaws. This is actually a very poorly written, outdated, discussion of SQL Flaws. The author's main issue seems to be with formatting and how hard it is to read declarative code versus procedural code. The arguments seem to have more to do with the authors inability to properly use whitespace than with any flaws on the part of SQL. Also, many of the flaws have been addressed (lack of support for procedural code modules, for instance) by the standard or through proprietary extensions on nearly every platform.

Though I personally don't agree with everything the RM Experts say about SQL, I have to say that Chris Date and Hugh Darwen offer much more convincing arguments about actual SQL flaws than this C2 article (e.g., SQL's introduction of Open World Assumption into Closed World Assumption of the database, inconsistent grammar of some language elements, etc.) If someone doesn't beat me to it, I'll add some of their comments to the criticisms section. SqlPac 05:34, 17 June 2007 (UTC)

removing Crystal Clear app database.png

I've removed this image because it is irrelevant. The stylized database can might make a nice icon for the Wiki Database Project, but the database can represents a database, not a query language. SQL is a language; it has no logo. In an edit comment reverting my removal, I was asked to provide an alternative. I already have: that's the usage of no image. Wikipedia articles are not required to have logos. -- Mikeblas 02:21, 15 August 2007 (UTC)

Thank you for taking the time to improve this article. Your contributions are appreciated. SqlPac 02:30, 15 August 2007 (UTC)
What about using one of the symbols commonly used in flow charting type diagrams? A database IS commonly represented as an upright cylinder in many types of diagrams. Using a non-stylized version should not be an issue. Also it is possible to use perhaps one of the Unicode symbols. // Brick Thrower 11:16, 15 August 2007 (UTC)
SQL isn't a database; it's a language. A cylinder represents a database, or other storage, and not a language. -- Mikeblas 14:22, 15 August 2007 (UTC)
You imply that SQL and databases are not closely related. Is there an example of SQL being used against some data set that is not considered a database? // Brick Thrower 12:35, 16 August 2007 (UTC)
I didn't say they're not related; I said that SQL is not a database. It's a language. A can represents a database, not a query language. As such, an example of SQL being used against some data set that is not considered a database (Considered by whom, BTW?) doesn't seem relevant to this discussion. What's more relevant is that a database might be accessed through any number of methods other than SQL, so a can isn't an appropriate icon for an entry on SQL. -- Mikeblas 13:04, 17 August 2007 (UTC)
I'm a little late to this party, but this logic seems a little backwards. "What's more relevant is that a database might be accessed through any number of methods other than SQL, so a can isn't an appropriate icon for an entry on SQL"? This sounds like "since a query language or method other than SQL can be used to access a database, a database icon is inappropriate for an article about SQL"? Is that an accurate interpretation? If so, it's not a compelling argument. The fact that non-SQL databases do not use SQL doesn't seem to relate. Or I could be wrong... SqlPac (talk) 05:50, 18 January 2008 (UTC)

Development Method?

What does the "Development Method" column in the "Procedural extensions" subection mean? What do the "Standard", "Proprietary", and "Open Source" entries specifically mean? -- Mikeblas 02:42, 15 August 2007 (UTC)

Since their meaning isn't clear in the article, and nobody here seems to know, I think we should remove that table. -- Mikeblas 13:05, 17 August 2007 (UTC)
I've remove the column in question. -- Mikeblas 14:45, 20 August 2007 (UTC)

Named Subqueries

Could someone please explain why this was removed from the "criticism" section?"

A sub-query cannot be named and referenced so that it can be used multiple times. Instead, one has to duplicate the sub-query for reuse in the same query. (Named "views" can be defined, but query users usually do not have the necessary permissions, and most RDBMS do not treat views as transient.)

The edit comments say it isn't necessary if refactoring is used. However, trees are not as general as graphs (barring duplication of leaves), so I doubt this is truly the case. --Tablizer 05:49, 11 September 2007 (UTC)

"Subquery factoring" doesn't mean refactoring, it's the name of the WITH clause that allows you to name a query and reuse it. Jonearles 23:03, 11 September 2007 (UTC) —Preceding unsigned comment added by Jonearles (talk • contribs)

Most vendors don't support it. Perhaps we should split the criticism list into items defined in the standard versus common implementation. - anon. —Preceding unsigned comment added by 208.127.151.14 (talk) 08:19, 16 September 2007 (UTC)

External Links

I think most of the external links are just ads and don't provide any new, useful information. Since there is a Wikibook, I don't think we need any external tutorials or introductions. If you disagree, please explain why another link is needed, otherwise I will just keep removing these tutorials. —Preceding unsigned comment added by Jonearles (talk • contribs) 22:20, 4 November 2007 (UTC)

As much as I do agree that most of the external links are spam and should be removed, they should be removed based on that policy and not because of an arbitrary decision by one editor. The WikiBook is just one source of some good information regarding SQL. Providing other tutorials in other formats and methods provides the reader with a broader scope of knowlege and better understanding of SQL. I think if we limit the links to those that are not spam, we will probably come close to accomplishing the same goal. Please do not remove the links blindly. --BlindEagletalk~contribs 13:59, 7 November 2007 (UTC)
I think we need to be more restrictive on the links. WP:EL says to avoid links to: "Any site that does not provide a unique resource beyond what the article would contain if it became a Featured article". A site needs to be more than just a "good tutorial" to be included, or else we'll end up with hundreds of links. Pages like Java, C++, and C# have very few links to tutorials (although C has a few). I propose that each external link to a tutorial needs to be justified here, else we should just delete it immediately. Jonearles 02:57, 9 November 2007 (UTC) —Preceding unsigned comment added by Jonearles (talk • contribs)
However, having a varied amount of tutorials and different approches to teaching SQL gives the user a better understanding of the language overall. I disagree with your approach of hacking out links without consensus. I think a small number of external links to tutorials like what is there to-date is appropriate. I agree that we do not need a large number of links to what is essentially the same subject matter. --BlindEagletalk~contribs 20:20, 9 November 2007 (UTC)

I agree that getting rid of spam links is a good thing, but not all of the links were spam. The W3Schools and TechBookReport tutorials aren't really spam links - both of them are recommended by computer science lecturers for example. —Preceding unsigned comment added by 217.205.90.120 (talk) 15:44, 7 November 2007 (UTC)

The when the Wikibook is good enough we can do without external links to tutorials and introductions, but the Wikibook is not good enough yet. Others are invited to edit the following rating of the contenders. I should declare my interest in sqlzoo - it's my site. Andr3w 21:02, 12 November 2007 (UTC)

Potential external links:

Disagree on the tech book report comment - it's wordy but well explained, it also includes LEFT JOINs, which you don't see on most introductory tutorials. —Preceding unsigned comment added by 217.205.90.120 (talk) 13:34, 13 November 2007 (UTC)

It has minimal content, and is coated with google ads. There seems to also be a conflict of interest on your part. Kuru talk 20:12, 9 December 2007 (UTC)

Pronunciation

(/ˌɛsˌkjuːˈɛl/ or /ˈsiːkwəl/); that is... S.Q.L. verses SEQWEL

  • S.Q.L. is what I say, so do most people I work with.
  • SEQWEL is so common it should be included.
  • I checked the top 5 hits for SQL on youtube...

Regardless of the fact that it should be pronounced S.Q.L. it clearly is pronounced SEQWEL. Both options should be included. Andr3w (talk) 01:38, 17 November 2007 (UTC)

  • Seqwl is indeed used often, but it is nevertheless incorrect, as explained in the article itself, so it should not be included, or it should be noted that it is the incorrect pronounciation... Anoko moonlight (talk) 18:28, 25 December 2007 (UTC)
A contributor (possibly yourself?) has added that the 1986 ANSI standard specifically states that the pronunciation [22 years ago] was "es queue el" or whatever variant thereof. I think that's good enough. Also of note are SQL-92, SQL:1999, SQL:2003, SQL:2006, which have not really dealt with the pronunciation issue. There are plenty of books written by experts and academics that state either pronunciation is currently acceptable. I think we've discussed this before, and the references were provided - the conversation may be archived from this very page somewhere.SqlPac (talk) 07:25, 28 December 2007 (UTC)
I looked through the archives, but there's no consensus yet, so I searched a little bit more. When searching Google, all discussions about the pronounciation conclude that it is es-queue-el. I found for example the following comments on a blog: "The 'sequel' pronunciation is a carryover from when there was actually a SEQUEL language. That was in the era before SQL became an international standard. For clarification, we can go right to the people who wrote the SQL standard. Jim Melton, editor of the ISO SQL-92 standard, covered this in his book '_Understanding the New SQL_' (Morgan Kaufmann): "1.2 What is SQL? SQL (correctly pronounced "ess cue ell," instead of the somewhat common "sequel"), is a data sublanguage ..." " Understanding the New SQL on Google Books. So "sequel" seems really to be incorrect. Anoko moonlight (talk) 09:34, 18 January 2008 (UTC)
It may be incorect to some people but still a very common way of saying it. harlock_jds (talk) 11:59, 18 January 2008 (UTC)
It's asinine to suggest that the ISO dictates how words are pronounced. Both pronunciations are in very common use and are widely understood and accepted; the article should reflect this rather than trying to make judgments about which pronunciation is superior. The exact balance between them is different in different cultures; in my experience, people who use MS SQL Server would be a lot more likely to pronounce it as Sequel whereas people who use MySQL are more likely to use the awkward "Ess Cue Ell", so that might explain the article's bias here since I would guess that wiki contributers are more likely to come from the open source crowd. 204.153.195.166 (talk) 06:42, 17 April 2008 (UTC)

[inset] The pronunciation war has flared again. (sigh) While there is no group that has authority to declare what is and isn't acceptable pronunciation, it is a reasonable argument that the SQL standards organizations have the most authority due to their control over the functional characteristics of SQL. I find it unreasonable, however, to suggest that veteran database professionals who pronounce the term as "see-kwull" are pronouncing it incorrectly, when the listeners correctly understand what the speaker is referring to.

It is a fact that many people pronounce it each way (e.g. [1]). Is anyone harmed by having two pronunciations? Of course not. So my position is that the pronunciation supported by the standards organizations is the "preferred" pronunciation, and the other is an "optional" pronunciation. Trying to claim that one is right and one is wrong is a useless effort to impose an arbitrary restriction on what is commonly accepted in real-life on a daily basis. JD Lambert(T|C) 21:18, 24 April 2008 (UTC)

I'm fed up with anonymous editors changing the adjective regarding the "see-kwull" pronunciation back to "incorrect" without any discussion on this talk page. If it happens again, I'm reluctantly going to request that this page be blocked from anonymous edits. JD Lambert(T|C) 20:00, 1 May 2008 (UTC)

Surely the purpose of a wiki is to provide information as accurately as possible. Microsoft website says: ".. and is pronounced both as "ess-cue-ell" and as "sequel"; this manual uses the former pronunciation. [2]". Whichever you pefer or use, both should be included as, the simple fact is, they are both so widely used. 'Fubar' was never a word once, but is so widely used it comes to have 'official' meaning. — Preceding unsigned comment added by 80.195.13.96 (talk) 00:24, 9 April 2013 (UTC)

Proprietary SELECT INTO?

There is mention of Microsoft's "proprietary" SELECT INTO feature in the article, which creates permanent tables. Please note the following, which I executed in PostgreSQL. 

cww=# \d
No relations found.
cww=# CREATE TABLE foo (temp text);
CREATE TABLE
cww=# INSERT INTO foo VALUES ('a');
INSERT 0 1
cww=# INSERT INTO foo VALUES ('b');
INSERT 0 1
cww=# INSERT INTO foo VALUES ('c');
INSERT 0 1
cww=# SELECT * INTO bar FROM foo;
SELECT
cww=# SELECT * FROM bar;
 temp 
------
 a
 b
 c
(3 rows)

cww=# \d
       List of relations
 Schema | Name | Type  | Owner 
--------+------+-------+-------
 public | bar  | table | cww
 public | foo  | table | cww
(2 rows)

cww=#

As such, I am rewording the article to not suggest that SELECT INTO is proprietary. Cww (talk) 01:44, 25 November 2007 (UTC)

SELECT...INTO might not be MS-specific, but it is a vendor-specific extension to the standard. It's not defined in the ISO standard, so the functionality is proprietary for anyone who implements it. Consider the Oracle SELECT INTO, which selects values into predefined variables (it's been a while, and my PL/SQL is a bit rusty, so bear with me):
declare
  v_lname person.person_last_name%type;
  v_fname person.person_first_name%type;
begin
 select person_first_name, person_last_name
 into v_fname, v_lname
 from person
 where id = 'XXXX';
 dbms_output.put_line('Name: '||v_lname||', '||v_fname);
end;
/
SqlPac (talk) 07:38, 28 December 2007 (UTC)
Well, yes, everyone seems to have a SELECT INTO extension. My point was simply that it's not Microsoft-specific or beholden to any proprietary intellectual property, etc., as the article might have suggested previously. Cww (talk) 06:53, 5 January 2008 (UTC)
My point is simply that the "SELECT...INTO..." construct is not defined by the SQL standard. Neither the syntax nor behavior are defined by the standard. Any vendor that implements "SELECT...INTO..." in any form is implementing a proprietary extension to standard SQL. Thanks. SqlPac (talk) 06:02, 6 January 2008 (UTC)
Then I would rather say it is "non-standard". Proprietary seems to imply a lot more... Anoko moonlight (talk) 11:17, 6 January 2008 (UTC)
Indeed. The definitions I've found for the word "proprietary" all say something along the lines of "protected by trademark", "distributed by one having exclusive rights", and so forth. These definitions do not describe SELECT INTO. Cww (talk) 17:45, 7 January 2008 (UTC)
To be clear, I am of the opinion that SELECT INTO, itself, is not proprietary, but implementations of SELECT INTO may be considered proprietary. Cww (talk) 17:55, 7 January 2008 (UTC)
Cww: I don't get your point, many implementations are altogether proprietary, so yeah, the implementation for SELECT INTO also... What do you mean? Anoko moonlight (talk) 23:49, 7 January 2008 (UTC)
When I first edited the article, it was to remove wording that suggested the idea of SELECT INTO was something to which Microsoft had exclusive rights and that only Microsoft had implemented the SELECT INTO feature. As evidenced by my first post here in this section of the talk page, PostgreSQL also implements this feature. Therefore, I edited the article to not suggest that only Microsoft implemented this feature. SELECT INTO is not a feature proprietary to Microsoft or anybody else, since they did not invent it and they do not have exclusive rights to it. I agreed with you earlier, Anoko: I think "non-standard" is a much better term for it. Cww (talk) 03:36, 8 January 2008 (UTC)

CTEs

The following paragraph was removed. The ISO SQL standard defines CTEs as part of the current standard, so there is a standard way of dealing with hierarchical data (when dealing with adjacency list model). We might expand the article to include a discussion of CTEs, and possibly a brief mention of other hierarchical structures like Nested Sets, etc.

"SQL—and the relational model as it is—offers no standard way for handling tree-structures, i.e. rows recursively referring other rows of the same table. Oracle offers a CONNECT BY clause, Microsoft and IBM DB2 offer recursive joins via Common Table Expressions, other solutions are database functions which use recursion and return a row set, as possible in PostgreSQL with PL/PgSQL. Similar problems exist with Graph (data structure) traversal. A general graph solution could perhaps be used for trees also, since trees are a subset of graphs." —Preceding unsigned comment added by SqlPac (talk • contribs) 07:06, 30 December 2007 (UTC)

It depends on whether standard refers to an official standard or a de facto standard. I believe the paragraph should be returned to the article, except that it shouldn't speak of standard but widely implemented or shared across most implementations. Rp (talk) 16:18, 3 February 2012 (UTC)

Pronunciation "Deprecation"

The article states that the official pronunciation, established in the first ANSI SQL standard, is "es queue el". The article also states that the pronunciation "see-kwull" (or approximation thereof) is 'deprecated'. How can something that was never a standard be deprecated? I changed the text to reflect that "see-kwull", though widely used, is "unoffical" as opposed to "deprecated". SqlPac (talk) 20:38, 24 February 2008 (UTC)

SQL division

Is SQL only divided into these three languages, aside from T-SQL: Data Manipulation Language, Data Query Language, Data Definition Language and Data Control Language, or hasn't the rest of SQL been grouped into sub-languages? --Stefán Örvarr Sigmundsson (talk) 09:26, 26 February 2008 (UTC)

The ISO Standard groups SQL into sublanguages of sublanguages. For instacnce there's "SQL Data Language" which is composed of Data Query Language + Data Manipulation Language. There's also Transaction Control Language which includes BEGIN TRANSACTION, COMMIT, ROLLBACK, etc. So yes, SQL is basically composed almost entirely of sublanguages. SqlPac (talk) 00:04, 1 April 2008 (UTC)

Plural Table Names

The SQL example uses singular "book" for the table name. I find it more linquistically natural to use plural. I suggest the examples be reworked for clariy. --Tablizer (talk) 06:35, 11 July 2008 (UTC)

I think it should stay this way. Although it's hard to say which one is used more often, standard idef1x for example uses singular form:
The entity name is a noun phrase that describes the set of things the entity represents. The noun phrase is in singular form, not plural. Abbreviations and acronyms are permitted, however, the entity name must be... (e.g. http://www.idef.com/pdf/Idef1x.pdf )
Anoko moonlight (talk) 07:58, 11 July 2008 (UTC)
I agree with Anoko moonlight, the guideline has always been that the name of a table should reflect the content of a single record. So a table that has many records, one for each car, should be named car because that's what a single record holds. I suspect that the frequent use of plurals is from people who never studied the issue or don't care about standardization. JD Lambert(T|C) 12:51, 11 July 2008 (UTC)
Agreed. The ISO metadata standards (ISO 11179 series) also indicate that entities should be named using the singular form as opposed to plural nouns. SqlPac (talk) 02:43, 14 July 2008 (UTC)

Regarding Pronunciation... Again

I agree 100% with your comment and assessment, jdlambert, re: "rv opinion. I and many other very experienced people use the unofficial pronunciation frequently". However, this brings up an interesting (possibly?) question concerning Wikipedia policy - does this constitute "original research"? I'm just wondering - I find Wikipedia policies relatively confusing sometimes, especially WP:OR ... Thanks SqlPac (talk) 04:11, 26 July 2008 (UTC)

Hi again, SqlPac. That was just an ancedotal comment for my reversion of an anonymous editor's unsubstantiated edit. I would certainly not use my comment as justification for a point, but there is abundant evidence in these talk pages showing that many seasoned professionals use the unofficial pronunciation. I don't know why some people seem to have difficulty coping with this fact, but it's not surprising that such edits are usually anonymous. JD Lambert(T|C) 13:55, 26 July 2008 (UTC)
I agree completely about the pronunciation. I have a hard time understanding the little twists and turns of Wikipedia policy - and WP:OR is one of the hardest to grasp for me. My question was just for my own knowledge of trying to understand what does and doesn't constitute OR as far was WP is concerned. Thanks. SqlPac (talk) 15:45, 30 July 2008 (UTC)
It is OR, but I suspect a source can be found for it, as it is manifestly widespread. Generally it's a good idea to keep things that can be sourced until such time as they are. Dcoetzee 07:14, 11 November 2008 (UTC)

SQL Keywords

I was just looking at some things about the current SQL Keywords articles. I had begun to contribute some to the keywords articles and noticed something with the Where (SQL) article. It contains information about LIKE, however LIKE is a different keyword that WHERE. So I started to separate LIKE into its own article and this thought came to mind.

Is it necessary that each individual SQL keyword have its own individual article? I'm not entirely sure that I think they should. Some have more content that others but it is not likely that any individual keyword would ever get any extensive information put together on them. There is just only so much that you can say about them and only so many examples you can provide. Which would make more sense to everyone, individual articles for each keyword or to do an all encompassing article called SQL Keywords and have the individual keyword articles to redirect to their respective section of each?

-- Dan9186(T • E • C) November 8, 2008 18:41 (UTC)

I don't think each keyword needs it's own article, and LIKE is a good example. LIKE, IN, and EXISTS will all work well as subsections of the WHERE article. JD Lambert(T|C) 20:21, 8 November 2008 (UTC)

Ok so at least that will be done, however, how do you feel about placing all of them into one article? If not then it should at least be decided what ones should be included as subsections and where to include them. -- Dan9186(T • E • C) November 11, 2008 03:03 (UTC)

I suggest we create an article SQL predicates that discusses WHERE, LIKE, IN, EXISTS, and other keywords used in predicates. Dcoetzee 07:11, 11 November 2008 (UTC)

TRUNCATE: DML or DDL?

Currently, the article puts the TRUNCATE statement in the DDL section. But I can not see why TRUNCATE would be about definition; I can only see it as being a statement which modifies content, i.e. a modification statement. By the way: TRUNCATE is now part of the SQL standard. TroelsArvin (talk) 01:18, 11 January 2009 (UTC)

As per the following discussions, TRUNCATE cannot be rolled back, and is thus classified as DDL, I will remove it from DML:

Crowne (talk) 21:25, 2 August 2010 (UTC)

Subquery redirect

Subquery redirects here...but the term subquery is not even mentioned on this page. I think this is problematic. I also think that the topic of subqueries is a rich and important enough topic to warrant its own wikipedia page. Thoughts? Cazort (talk) 20:30, 26 January 2009 (UTC)

Add INSERT with SELECT clause

The article as it states for adding a single row of data using the syntax

INSERT INTO foo (field1, field2, field3) VALUES (v1, v2, v3)

Please also add the ability to add a set of data based on the results of an SQL SELECT query - eg:

INSERT INTO foo (field1, field2, field3) SELECT bar.field1, bar.field2, bar.field3 FROM bar WHERE bar.field1 = 'X' and 

bar.field2 = 'Y'

This could add anything from 0 rows (ie if there are none that match) through to thousands. A quick check to see if it will return rows is to run the line from the SELECT statement through to the end to see what is returned. Any valid SQL SELECT statement can be used - it can have table joins, group by and HAVING clauses, UNION etc.

It is also worth saying that when data manipulation statements are run (insert, update, delete): - this will cause any triggers set up to execute (where supported by the database engine). - data inserted/updated needs to conform to any referential integrity and constraints set up on the target table and fields within it. - appropriate permissions on both the source and target tables are required for an insert or update statement based on data in another table. —Preceding unsigned comment added by 79.76.140.225 (talk) 14:54, 28 March 2009 (UTC)

FOREACH loops

Mention if SQL can do even the basic FOR EACH construct like 

for(...){} #of perl
for i in a b c; do ...; done #of sh

Jidanni (talk) 04:00, 11 May 2009 (UTC)

Contradiction in Query subsection

"Contrary to popular belief, queries are any operation, not just SELECT. The most common operation in SQL databases is the query, which is performed with the declarative SELECT keyword." These two statements appear to be in direct conflict with each other. —Preceding unsigned comment added by 128.61.105.140 (talk) 19:59, 3 June 2009 (UTC)

Database named SQL deleted....

I dropped the database named SQL and now MySQL refuses to work I can't find any help for this.. 96.229.108.159 (talk) 23:06, 3 June 2009 (UTC)

Check out MySQL, there are a number of examples of companies that are using it, and inherently, for which it is 'working'. Do you have examples of it not being a widespread issue?Cander0000 (talk) 04:09, 13 June 2009 (UTC)

Contradiction in the Queries section

Is it just me, or is this statement contradictory? "Contrary to popular belief, queries are any operation, not just SELECT. The most common operation in SQL databases is the query, which is performed with the declarative SELECT keyword." —Preceding unsigned comment added by 192.251.93.217 (talk) 19:33, 17 June 2009 (UTC)

This article is in pretty bad shape. I think it should be rewritten from scratch. Lfstevens (talk) 03:20, 3 July 2009 (UTC)

Null and Three-Valued Logic (3VL)

Added a section on 3VL based on the 3VL page however one of the three references didn't come over like the last two. Here is the reference if someone with more knowledge on how to do this can fix this error.

^ a b ISO/IEC (2003). ISO/IEC 9075-1:2003, "SQL/Framework". ISO/IEC. Section 4.4.2: The null value. http://www.iso.org. —Preceding unsigned comment added by Philippe Perrault (talk • contribs) 15:34, 3 July 2009 (UTC)

The rule of NULL

1. NULL doesn't answer to any compared operator, except IS NULL or IS NOT NULL; 2. NULL with any operator and other value will always return NULL.

In fact, you just have to think that NULL is "something", but you do not know what. That's why you can compare it anything else but NULL. NULL = 4 is not true because NULL is something you do not know, and it's not false either because of the same reason.

People who are mathematical notion of the infinity arythmetics will make a easy connection with the NULL and the infinity. —Preceding unsigned comment added by 69.70.11.19 (talk) 15:04, 29 July 2009 (UTC)

Stuff removed from Boolean data type article

The following section was removed from the article Boolean data type:
begin removed text

SQL supports three-valued logic (3VL), and comparison predicates in SQL can return any of three possible results: true, false, or unknown. The Boolean data type was introduced in the ISO SQL:1999 standard, which specified that in addition to the three possible SQL Boolean values, instances of the data type could be set to null[1]. For DBMSs that implement the ISO SQL:1999 standard, the following code creates a table which holds instances of the Boolean data type. 

CREATE TABLE test1 
(
  a int, 
  b boolean
);

INSERT INTO test1 
VALUES (1, true);

INSERT INTO test1 
VALUES (2, false);

INSERT INTO test1
VALUES (3, null);

-- The SQL:1999 standard says that vendors can use null in place of the 
-- SQL Boolean value unknown.  It is left to the vendor to decide if
-- null should be used to completely replace unknown.  The standard also 
-- says that null should be treated as equivalent to unknown, which is an 
-- inconsistency.  The following line may not work on all SQL:1999-compliant 
-- systems.

INSERT INTO test1
VALUES (4, unknown);

SELECT * 
FROM test1;

The SQL Boolean data type did not gain widespread adoption, owing to inconsistencies in the standard and lack of support from vendors. Most SQL DBMSs use other data types like bit, byte, and char to simulate the behavior of Boolean data types. Postgresql supports the standard SQL Boolean data type.[2]

end removed text
Is there a place for this text in the SQL-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 00:14, 31 December 2009 (UTC)

There might be B:SQL, V:SQL, and/or Book:SQL to home that contribution. — CpiralCpiral 03:12, 11 April 2013 (UTC)
It was reborn at v:Primary mathematics:Boolean logic. — CpiralCpiral 19:44, 11 April 2013 (UTC)
  1. ^ ISO/IEC. ISO/IEC 9075-1:1999 SQL Standard (pdf format). Section 4.4.3.3. 1999.
  2. ^ http://www.postgresql.org/docs/7.4/static/datatype-boolean.html

Text Color Hard on Eyes

The light-green text in the example SQL code can be difficult to see in its context. I'd suggest using dark-green instead, if possible. Thanks. —Preceding unsigned comment added by 66.120.226.81 (talk) 00:30, 14 January 2010 (UTC)

I aggree, syntax highlighting should _increase_ readability. The green is too bright for mee too. Thøger (talk) 16:21, 11 April 2010 (UTC)

Possible factual error in discussion of IS DISTINCT FROM

This excerpt from the article seems to me to be factually incorrect:

There is also the "<row value expression> IS DISTINCT FROM <row value expression>" infixed comparison operator which returns TRUE if both operands are equal or both are NULL. Likewise, IS NOT DISTINCT FROM is defined as "NOT (<row value expression> IS DISTINCT FROM <row value expression>")

One possible correction:

There is also the "<row value expression> IS DISTINCT FROM <row value expression>" infixed comparison operator which returns TRUE if except when both operands are equal or both are NULL. Likewise, IS NOT DISTINCT FROM is defined as "NOT (<row value expression> IS DISTINCT FROM <row value expression>")

MetaEd (talk) 21:02, 14 January 2010 (UTC)

http://www.passionforsql.com/p/home.html

JET-SQL (for Microsoft Access)

It would be usefull with a comment/details on JET-SQL for Microsoft Access (I don't know where it fits in the article). Should it be included in the table of "Procedual extensions"? Some info can be found in JET-SQL to T-SQL cheat sheat. Thøger (talk) 15:36, 11 April 2010 (UTC)

From http://www.devguru.com/Technologies/jetsql/quickref/jet_sql_intro.html :

The version of SQL created by Microsoft is called Jet SQL and it is the database engine behind Microsoft's Access.

Jet SQL has certain limitations compared to the other versions of SQL. In general, Jet SQL is not designed to manage a database, but rather, it is used to retrieve information from a database. To cite two limitations, Jet SQL, by itself, cannot create a database and cannot manage security . This is where the Microsoft Data Access Object, commonly called DAO, enters the scene. DAO contains libraries which are designed to manage databases. While, yes, you can use Jet SQL without DAO, you are effectively limiting your options to handle the data. For example, with DAO you can create a database and manage security. Likewise, Microsoft's Access offers the ability to create and maintain databases.

The value of Jet SQL (and DAO) is that it allows the developer to add databases to an active Web site.

Thøger (talk) 20:11, 12 April 2010 (UTC)

Pronunciation - IPA syllable marker?

According to the article SQL is pronunced pronounced /ˌɛs.kjuːˈɛl/, which I read as "es queue el", ie an acronym. Should it be pronounced /ˌɛs.kjuː.ˈɛl/, ie with a "syllabification" period between "Q" and "L"? Or am I just misreading something? (I'm not very familiar with IPA or Wikipedia:IPA for English) Mitch Ames (talk) 01:55, 16 April 2010 (UTC)

The pronunciation has now been changed by 123.243.64.137 to pronounced /ˌess-cue-el/, but is that IPA? I suspect not. Mitch Ames (talk) 02:33, 23 April 2010 (UTC)

No that is not IPA. There's a wikipedia article on IPA :) 60.242.167.82 (talk) 05:54, 20 September 2012 (UTC)

I don't think the "sequel" IPA is correct. The "əl" in IPA is as in "bottle", which is "le" not "el". It looks like the "ɛl" used in SQL should also be used here. 86.0.254.239 (talk) 17:49, 14 September 2010 (UTC)

Yeah, that's more or less right. /ə/ is schwa, the most common vowel sound in English, and is always unstressed. But when we pronouce "L" as a distinct word, it would have a stressed vowel sound. In this case it is rendered /ɛ/ according to Wiki's IPA spelling guidelines, although in practice the actual IPA transcription tends to reflect local dialect, so might be rendered differently in different schemes. 60.242.167.82 (talk) 05:54, 20 September 2012 (UTC)

Note that SQL grew out of its precursor SEQUEL and in my professional experience, most people call pronounce SQL "Sequel" at least some of the time. There should be an alternate pronunciation. --AlanH

Turing Completeness?

The statement about Turing completeness should really have a citation, and it also seems to be not quite as cut and dried. There are extensions and dialects of SQL which claim to be Turing Complete[3] and there is even a claim that the latest version with CTE and Windowing is TC[4]--Salix (talk): 22:13, 21 April 2010 (UTC)

I know it's a For Dummies book, but still it is published stating the opposite. So there is probably a need for more than just one citation because of it being stated the other way around. ANSI SQL 92 defines cursors I think, but I'm not sure if that makes it TC or not, and even so it would be original research. --Capnchicken (talk) 21:06, 23 July 2010 (UTC)

I don't know about the written standards, but in production dialects, TC-ness depends on the dialect (vendor). Perhaps it's best to avoid mention of TC because to "describe it right" opens a can of worms. Another approach is to say something like "TC-ness in practice depends on the specific dialect." Anonymous - --146.233.255.201 (talk) 01:45, 3 December 2011 (UTC)

Verions vs. dialects

I think that SQL92, SQL99, SQL2033 atc. are versions of SQL standard, whereas Oracle SQL, MS SQL etc. are dialects. This corresponds with overall notion of versions in computing. Helena.Palovská (talk) 14:44, 30 June 2011 (UTC)

X/Open

In addition to all the ANSI / ISO / FIPS standards, we also have a X/Open standard "Data Management: Structured Query Language (SQL), Version 2" published around March 1996 that probably should be added to the list of standards and classified. It is after SQL-92, but doesn't include all those features, it was based on FIPS "Transitional SQL". Version 1 might also be worth classifying. Modern versions of ODBC are in alignment with the X/Open SQL/CLI. Many X/Open standards (including this one) can be downloaded for free after filling out a registration form, so even if you don't have access to ANSI / ISO standards you can read, classify, and refer to this one. --70.166.132.50 (talk) 20:21, 4 August 2011 (UTC)

Do you have any sources?Jasper Deng (talk) 20:30, 4 August 2011 (UTC)

Numbers

The statement The precision is a positive integer that determines the number of significant digits in a particular radix (binary or decimal). The scale is a non-negative integer. A scale of 0 indicates that the number is an integer. For a scale of S, the exact numeric value is the integer value of the significant digits multiplied by 10-S. is inaccurate in two regards. The "10-S" at the end should be 10 to the -S power, whether that's written as an exponent in a suitable character set or it uses in-line notation to explain it more clearly. Second, doesn't that expression apply only if the radix is decimal? I'd think it would be 2^(-S) for binary or 2**(-S) if you prefer. 68.183.134.158 (talk) 20:52, 2 December 2011 (UTC)

External Link

I suggest to add new external link on SQL article: http://www.sql-ex.com/. This link leads to the SQL tutorial site. There are lots of interesting exercises. For each exercise there is separated forum where people who solved the exercise can discuss their solutions. Also there are two types of certificates available. Many people improved their SQL skills on this site. It can be interestion for everyone regardless of their level of knowledge, from beginners to experts. — Preceding unsigned comment added by 176.195.118.170 (talk) 11:35, 3 December 2011 (UTC)

It doesn't meet WP:EL. This is also now the third time in rapid succession that you've added it. Andy Dingley (talk) 11:44, 3 December 2011 (UTC)

Criticisms seem valid

As an experienced SQL developer I can say that the criticisms seem very valid, and I myself have experienced the date time issues between solutions (Oracle and SQL Server) so ... why is that tag still there? — Preceding unsigned comment added by LifeEditorLatinAmerica (talk • contribs) 19:57, 26 March 2013 (UTC)

1.5.4 Date and time

It could be useful to say unambiguously what the zero of date/time is, and whether the value is signed. 94.30.84.71 (talk) 11:39, 24 December 2011 (UTC)

Please add alternate pronunciation

It seems that it's been well-established that both "ess cue ell" and "sequel" are valid, accepted, and widely-used pronunciations for "SQL". The correct IPA representations for both should be included in the first line of the article. Could an established editor please make that fix? Thanks.... — Preceding unsigned comment added by 138.69.160.1 (talk) 23:18, 25 March 2013 (UTC)

Copy-paste move to Structured Query Language

I've reverted this move:

Andy Dingley (talk) 22:37, 13 January 2014 (UTC)

Success

Now that we have paragraphs about criticism and alternatives to SQL - how about some absolute and/or relative figures about the usage of SQL in the database field? How many percent of top 5000 companies use SQL as their main database language? How many percent of DB transactions in the US or Europe are performed with SQL? Sorry I do not have access to this kind of statistics, but someone else maybe. --Edoe (talk) 12:47, 9 June 2014 (UTC)

99. some nines %
There are a few hipster startups where SQL is not the main DB language. These don't generally make it into the Fortune 500. Otherwise it's Google and the NSA. Everyone else is still running on late-'90s Oracle, and lots of it. The dinosaurs of MUMPS and Pick have finally died off. If they're still around in a business, they're not processing the bulk of the transactions. DB2 is now only hanging in there because a site is still dedicatedly IBM. Andy Dingley (talk) 13:30, 9 June 2014 (UTC)

Premature Minutia

I don't understand why CASE statements and DECODE are the first examples. They are not a key concept and will confuse beginners. They should either be much further down or omitted. --146.233.0.201 (talk) 20:38, 19 June 2014 (UTC)

Semi-protected edit request on 25 December 2014

Please change 'Structured' to 'Standard'

The S in SQL stands for Standard

78.150.156.198 (talk) 08:32, 25 December 2014 (UTC)

Not done: please provide reliable sources that support the change you want to be made. There are currently 4 sources cited that refer to it as Structured. Cannolis (talk) 10:31, 25 December 2014 (UTC)

"Criticism" vs. "Design" Section

As someone who is not particularly knowledgeable about either SQL or the history of this article, the "Design" section looked pretty strange, since it's short and mostly devoted to aspects of SQL that have been criticized. So I wasn't surprised to see that this section was created only a few weeks ago, by taking most of the "Criticism" section, renaming it to "Design", and moving it up the page. I think that it would be preferable if either that section was fleshed out, or that change was reverted. I'm totally willing to believe that this was a good-faith effort to take useful information in the "Criticism" and de-politicize it by creating a more neutral/straightforward section out of it. But to an outsider, without looking at the history, it looks like someone is editorializing as part of some religious war about how useful SQL is. And it's not really detailed enough to give a useful overview of SQL design as-is. Quantheory 04:10, 25 June 2015 (UTC) — Preceding unsigned comment added by Quantheory (talk • contribs)

I think I agree with you. Reading that section, I'd expect something explaining the thinking behind SQL, how it was designed, etc. Instead it's just some short criticisms. It makes much more sense as a "Criticism" section lower down. I think in its current state, the article is giving more importance to criticism than if it was arranged like it used to be, because criticism is the first thing you read after the opening. —ajf (talk) 11:54, 25 June 2015 (UTC)

Include information on UNION and JOIN statements

There is no substantial documentation of the UNION and JOIN statements. — Preceding unsigned comment added by Liamzebedee (talk • contribs) 07:22, 7 July 2015 (UTC)

SIMILAR TO

I believe that SQL:1999 introduced SIMILAR TO, and a few other regular expression improvements. SIMILAR TO is implemented in Postgresql. I dont see them mentioned here or related articles. John Vandenberg (chat) 02:34, 6 October 2015 (UTC)

Controversy

I believe we need a controversy section, wherein the fact that Oracle stole the language that IBM developed has led to concerns that this might not constitute "fair use" under copyright law - and hence that Oracle could be required to disgorge all profits made since the '70s. — Preceding unsigned comment added by 75.165.39.75 (talk) 03:51, 28 May 2016 (UTC)

So, Mister IP editor, you got a source for your CONSPIRACY MONGERING?? -- Doctorx0079 (talk) 20:25, 29 May 2016 (UTC)

GROUP BY Projection vs. Selection

The current statement for GROUP BY is "The GROUP BY clause projects rows having common values into a smaller set of rows." According to many sources, (SAP for example), projection limits columns, while selection limits rows. Based on this understanding, it would seem that the correct statement should be "The GROUP BY clause selects rows having common values into a smaller set of rows." Can someone with a background in relational algebra confirm this interpretation? -- Dave Braunschweig (talk) 14:07, 13 July 2016 (UTC)

I feel "project" is more accurate if you think of it in its general mathematical sense. "Select" suggests you produce some rows as they are, which is not what happens in general. But GROUP BY is neither relational projection nor relational selection (it requires relational division), so perhaps a third term should be used. Rp (talk) 11:48, 17 July 2016 (UTC)

Discussion on whether to include SPL as a SQL language for Teradata

I removed the SPL reference to the Unix (Set Priority Level) Spl (Unix) because it clearly wasn't related to SQL, I can't find any reference to Teradata using SPL or a SQL derivative so I would like to recommend removing it entirely from the list unless someone has a better source. — Preceding unsigned comment added by Plachert (talk • contribs) 17:07, 30 October 2016 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:SQL/Archive_3&oldid=1088446930"