Talk:SQL

From Wikipedia, the free encyclopedia

	This article is within the scope of WikiProject Databases.
Start	rated as start-Class on the assessment scale
Top	rated as top-importance on the assessment scale

To-do list for SQL:

edit · history · watch · refresh

Want to help? Here are some suggestions for improvements that can be made to this article: Expand article SQL doesn't have "commands". A discussion of "statements", "clauses", "predicates", "expressions", etc., might be in order. Add explanation of SQL datatypes Add discussion of SQL standards-defined functions and operators (aggregate functions, windowing functions, math operators, etc.) Add discussion of CTE's Add discussion of why no Boolean data type Add intro to tables, rows, columns, and cursors Add short introduction to NULL and SQL 3VL (thorough discussion provided at Null (SQL) Add historical discussion of "Embedded SQL" Add discussion of declarative versus procedural languages Add discussion of SQL/XML Add discussion of SQL/PSM Overview of the parts of the SQL Standard Discussion of vendor-specific and proprietary extensions (might be too detailed to discuss all the differences between the different vendors and the standards) What is a "standards-compliant" version of SQL? Source statements in article (in particular, the criticisms section, although others need it also) Locate and add images if possible and where appropriate (screen shots of queries and results?) Maybe add one more screenshot of query results? Clean up, editing Simplify language and grammar. Clean up intro

Archives

/Archive 1: Mar 2002 - Dec 2005 /Archive 2: Dec 2005 - Jan 2007

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

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)

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

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)

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

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

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

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

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

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

[edit] about sql

202.133.207.68 11:02, 25 June 2007 (UTC)whar are the commands used in the structured query language... pls. help me..

yours truly,

Jusfer John

Dude, read the article, it has the most frequently used commands, such as SELECT, INSERT, UPDATE, and DELETE, with links to longer articles on each command. JD Lambert^(T|C) 12:39, 27 June 2007 (UTC)

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

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

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

[edit] 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. --BlindEagle^{talk~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. --BlindEagle^{talk~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:

• http://www.W3schools.com/sql is comprehensive and should be included even though the ratio of content/ads is too high.
• http://www.techbookreport.com/ is not good enough. It is text heavy and not up to Wikipedia standard.
• http://sqlzoo.net is good enough. Its multi-platform and interactive nature provide unique benefits not available in Wikipedia.

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)

[edit] Pronunciation

(IPA: /ˌɛ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...

• • http://youtube.com/watch?v=MJNJjh4jORY ... SEQWEL
  • http://youtube.com/watch?v=ecNP8KBX_sc ... both S.Q.L. and SEQWEL
  • http://youtube.com/watch?v=OQ14NjbEXJM ... unbearable, I don't care what he says
  • http://youtube.com/watch?v=nLZlR3nSrsc ... SEQWEL
  • http://youtube.com/watch?v=gNagVQc4e6c ... SEQWEL

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)

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

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

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

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