Talk:Select (SQL)

Untitled

What is the justification for this page? I think this example should stay on the SQL page. Besides, the phrase "a select" strikes me as sloppy and uncommon. I would use "a select-from-where" or "a select expression" but never "a select". Moreover, the article on SQL should contain examples of SQL statements, so I don't see why these were moved and not just copied. -- Jan Hidders 16:02, 19 May 2004 (UTC)

The article begins "A SELECT statement ...". This refers to a particular kind of "statement", that kind which involves the keyword "SELECT". I don't understand your question, unless you think no SQL keyword should have a separate article? --Phil | Talk 16:16, May 19, 2004 (UTC)

I was trying to make several points. To begin with, indeed, I don't think there is at this moment enough justification for a separate page for select statements. But if we do, then the title shouldn't be simply "select" but it should be "select statement". And finally, having such a page does not mean that all examples of select expressions should be moved from SQL to this page. The SQL page should at least contain one or two illustrative examples of select statements. -- Jan Hidders

I think that we should also explain a few more details on the SELECT statement, namely:

• joins and the various join types
• set operations (EXCEPT, UNION, ...)
• subselects (it is there, but badly organized)
• relationship to cursors
• use of expression and host-variables

--Stolze 18:47, 24 October 2006 (UTC)

Many of these aren't here because they have their own topics. -- Mikeblas 18:00, 22 October 2006 (UTC)

Joins, UNION, and cursors are there; a proper link should occur in this topic here nevertheless. But the others are distinctively missing completely. Or do you have some links to those topics? --Stolze 18:46, 24 October 2006 (UTC)

I think that the introduction and example sections of this article are excellent, but that the other sections are not notable. The article should be concise. I believe that a discussion of how to limit rows returned in different vendor syntaxes is outside the scope that this article should aim for. A concise mention that syntax variations exists would be fine. 86.43.105.14 (talk) 12:03, 4 June 2008 (UTC)

Merge

Recommend merging UPDATE, INSERT, DELETE, MERGE and SELECT statements into DML article and redirecting these statements there. Comments? SqlPac 05:21, 17 May 2007 (UTC)

If the article on SELECT is moved, I am only concerned that SELECT is presented in a promient position (some sort of emphasis such as a leading section) because I feel that understanding how the SELECT works and operates is essential and fundamental to all DML and DDL statements in SQL. Right now I am happy with it being a separate article and would not recommend a merge into any other article. // Brick Thrower 18:13, 18 May 2007 (UTC)

SELECT is arguably the most important statement in SQL (definitely the most widely used), and would receive a prominent position. It would also encompass a large portion of the article as well. My main concern is that we have one or two paragraph stubs for the following DML statements and clauses: UPDATE, INSERT, DELETE, MERGE, FROM, WHERE, TRUNCATE, GROUP BY, HAVING, ORDER BY, etc. It doesn't make sense (to me anyway) to have a single article's worth of closely-related DML content spread out around a dozen or so separate 1-2 paragraph article stubs. SqlPac 18:53, 18 May 2007 (UTC)

I agree that we should merge WHERE/GROUP BY/ORDER BY/HAVING into the article for SELECT. Those are very closely related. I'm not convinced on UPDATE/INSERT/DELETE/MERGE articles. Those articles should be expanded first to include all the important content. For example, things like triggers, constraints, assertions, operations on views, indexing etc. are usually not discussed in the articles. Once the bulk of the content is available, we should revisit the merge discussion. Maybe it becomes obvious right away that the material would be way too much to be combined in a single article. TRUNCATE is another issue because that is not a standardized SQL statement IIRC. We have to figure out how to deal with such things in the first place. --Stolze 08:51, 19 May 2007 (UTC)

A lot of those items (triggers, constraints, etc.) have their own articles already. You are right, there is a lot of room to expand the existing articles, but I don't see a lot of room to expand some much larger than "super-sized" stubs. For example, I wonder how much there really is to say about DELETE that isn't covered in other articles that would be linked anyway? SqlPac 21:39, 19 May 2007 (UTC)

True, a lot of those items are covered already. But as with outer joins and NULLs, we should at least have one sentence here for each related topic and link to it.

DELETE is a statement where not much can be said about it. UPDATE and INSERT require a bit more explanations. I still think that we should first sort-of complete the content and then revisit the merge discussion again. At may indeed be the best thing to do. --Stolze 13:31, 20 May 2007 (UTC)

I'm not in a big hurry, just wanted to get the conversation going so it can be addressed. Keep in mind though, that adding WHERE to the SELECT article means that we don't have the option of adding WHERE to INSERT, DELETE, etc., where it is also a valid clause. The articles in question could all definitely be expanded, many with parallel content (sub-queries, EXISTS clauses, etc., come to mind). For now I'm happy to leave these DML-related articles as is, and revisit once we have expanded the existing articles.

What do you think of combining the DDL-related articles (CREATE, ALTER, DROP), by the way? Obviously those articles address a single keyword of complete DDL statements (CREATE TABLE, DROP VIEW, ALTER TABLE, etc.), and I think they would be better served by combining into one article as well. Thanks. SqlPac 19:43, 20 May 2007 (UTC)

Actually, we have the issue with the WHERE clause only for DELETE. In INSERT, one specifies a sub-select anyways, so we could simply point to the SELECT article. :-)

And UPDATE :) SqlPac 04:15, 22 May 2007 (UTC)

Combining CREATE/ALTER/DROP TABLE or CREATE/ALTER/DROP VIEW would be a good thing, I believe. Especially for the DROP statements, there is not much to say, except that the object is removed and what else may be impacted (views becoming invalid etc.) --Stolze 18:07, 21 May 2007 (UTC)

Yeah that's sort of what I'm thinking too. There really isn't all that much to say about them individually. Together they'll make a decent article. SqlPac 04:15, 22 May 2007 (UTC)

Hey guys, here is how the page might look really good. Check out the POSIX signals page. http://en.wikipedia.org/wiki/SIGKILL. The sql/mysql commands could each have their own page, but all the pages could have a neat table of commands like they did with the sig* interrupt page. If no one gets to it by this summer, I'll throw a table on them. Caalip (talk) 18:15, 23 November 2007 (UTC)

POLICY DEBATE: Use of source code and other examples in articles

Someone started a policy debate concerning the use of source code in articles, that seems to directly impact this (and possibly other Database articles). See below for details:

I have opened a debate on the use of source code and other examples in Wikipedia articles. It seems that many pieces of example source code etc. currently in Wikipedia violate Wikipedia policy, so we need to either clarify or change the situation. Depending on the result of the discussion, this may result in a number of source code examples being summarily removed from computing articles!

Please reply there, not here, if you wish to contribute.—greenrd 10:50, 18 May 2007 (UTC)

Thanks.SqlPac 15:10, 18 May 2007 (UTC)

That discussion is now archived at Wikipedia_talk:Attribution/Archive_17#Explicit mention of examples (source code, math, etc.). - Jmabel | Talk 23:29, 21 January 2008 (UTC)

Performance

Although this may vary between implementations of SQL, is it worth explaining that SELECT * from xxx does have performance impacts on the way that the database has to work out the table size on the fly, whereas explicit declaration is quicker?

I don't think that's really a factor--working out the table size on the fly shouldn't have a significant impact, since SQL implementations that follow ISO standards store metadata about the tables involved in the database anyway. Also SELECT * could perform worse in some situations or better in other situations. For instance, SELECT * returns every column in the table--even columns that may not be needed for the task at hand which could impact performance negatively. On the other hand, an optimized SQL query engine may be able to optimize the way in which it retrieves rows by using an index to retrieve rows when one is available, which can be more efficient than a simple table scan in some implementations. It's really implementation-specific behavior. SqlPac (talk) 01:25, 24 March 2008 (UTC)

Pretty minimal

No discussion of nested selects. No link to any in-depth discussion on Wikibooks, though I presume one exists. External links provided are almost useless: one is to a decent overall article on Oracle, but it's in Spanish (and it isn't particularly about the Select statement). The other is to a short manual page on the Select statement that doesn't seem to have much significant content not already in the article. - Jmabel | Talk 23:26, 21 January 2008 (UTC)

WP:BB SqlPac (talk) 03:26, 21 March 2008 (UTC)

SELECT <> DML

In the opening for the article it states that SELECT is the most commonly used DML command. SELECT is actually not a DML statement. The ISO 9075:2003 standard specifically divides up the landscape like this:

Data-Language Statements
|
+----Query Statements
|      |
|      +----Multirow SELECT Statements
|
+----Data Manipulation Language
       |
       +----INSERT, UPDATE, DELETE, MERGE, Cursor Statements
       |
       +----Single-row SELECT INTO Statement

In all fairness, the single-row SELECT INTO statement is included in DML, but multirow SELECT statement is not. SqlPac (talk) 01:33, 24 March 2008 (UTC)

References

I added a couple references and accordingly removed the Unreferenced|date=May 2007 & September 2007 tags. If anyone with more sql knowledge thinks there is still unreferenced content by all means point out where or re-add the tags --Faradayplank (talk) 05:30, 24 March 2008 (UTC)

"In most applications, SELECT is the most commonly used Data Manipulation Language (DML) command." No reference is given. ISO/IEC 9075:2003 (the SQL:2003 standard) can be used as a reference that contradicts this statement. SqlPac (talk) 22:52, 24 March 2008 (UTC)

SELECT *, col1

Maybe mention that one can do

SELECT col1, col1 FROM bla;

but not

SELECT *, col1 FROM bla;

apparently for no good reason. Jidanni (talk) 04:42, 28 March 2009 (UTC)

PICK-style?

Another example would be the "SAMPLE n" format used by Unidata (likely other PICK style systems, most of whom have a SQL interface)

66.46.252.68 (talk) 16:43, 5 March 2010 (UTC)twalter@rogers.com

Window functions first example

The first example in Window functions isn't very good: summing the population partitioning by city would only make sense on a "suburbs" table. A better example would be to sum the salary partitioning by department on an "employees" table. Colin 't Hart (talk) 14:00, 8 August 2013 (UTC)

"SELECT INTO"

i got here by following a link for "the 'select into' variant" but that is not described here. — Preceding unsigned comment added by 204.8.27.140 (talk) 18:44, 4 November 2013 (UTC)

"Generating Data in T-SQL"

What's the purpose of this section? Why add beginner SQL coding tips, labeled as T-SQL "feature"? — Preceding unsigned comment added by Fjerdingen (talk • contribs) 20:46, 24 May 2017 (UTC)