Talk:Structured Query Language

General comments

"Maybe it would be a good idea create an entire book about databases and reference that as a requirement for learning SQL.."

I agree. The same would also go for having a book about Computer Programming as a prerequisite for learning C++. Noldoaran 03:21, 17 Dec 2003 (UTC)

See Programming:Database Programming. --Lathspell 23:41, 6 September 2006 (UTC)

You need to introduce language elements in their properly defined categories (DDL / DML/ DCL). Also, the section on relational database history is out of place. If you're going to talk about databases in general, put that section BEFORE any information on SQL itself, so that you can introduce SQL in that context. Also, you might consider removing the references to the term "relational", since many would argue that SQL DBMSs certainly are not.

Done. I left "relational" though as SQL is about relational (in the math sense) databases although maybe not about "relational in the strict sense of Codds 12 rules" (which probably nobody I personally know has ever read :)). Or where are the violations? --Lathspell 00:11, 7 September 2006 (UTC)

It would be helpful for readers to preface the two tracks with information about to evaluate which track of the two tracks to read?. What is the distinction between the standard and classic tracks? --DeCage (discuss • contribs) 15:42, 25 March 2019 (UTC)

The 'classic' track is the first version of this book. When I created a complete new version around 2012, I refused to overwrite the old one and created the additional 'standard' track. But my intention was - and is - replacing the 'classic' track completely. All concepts, topics, and syntax elements shall be contained in the new version. Therefore my question: does the 'classic' track has some advantages over the 'standard' track (as of today)? Shall we transfer special topics of 'classic' to 'standard' and then delete this version? Kelti (discuss • contribs) 08:57, 28 March 2019 (UTC)

I've mostly been working with the standard track. I don't know the 2 tracks well enough to understand whether or how to merge the two. In a quick comparison it looks like 'standard' has more complete explanations and 'classic' has a more reference and graphical approach. Maybe each approach is useful to different readers. dCage (discuss • contribs) 21:05, 2 April 2019 (UTC)

SQL Syntax?

Should SQL keywords like SELECT, WHERE, JOIN, ect be in all capitals in the examples? Some of them are, while others are in all lowercase. I feel as though this would make the syntax more readable and it is pretty much standard to do so anyway. --Nick Manley 03:10, 17 October 2006 (UTC)

Definetly yes! --Lathspell 06:41, 28 November 2006 (UTC)

Should we drop all these empty sections?

I suggest we gank all the empty sections. In the beginning, we just should just accumulate as much SQL-related material as we can, and then later try to organize it.

No empty sections visible? Already removed? --Lathspell 00:11, 7 September 2006 (UTC)

DBMS's

We should also mention IMB DB2 and MS SQL Server since these are also two major DBMS's --Nathan 21:35, 16 November 2005 (UTC)

Done. --Lathspell 00:11, 7 September 2006 (UTC)

Factual Error?

Is text actually a SQL standard datatype?? --Nathan 21:34, 16 November 2005 (UTC)

No it's at least not in the SQL2003 standard. Replaced with "integer". --Lathspell 00:11, 7 September 2006 (UTC)

Revisions

I did some major revisions on the JOINS secion. I hope to continue and complete these changes --Nathan 20:35, 12 December 2005 (UTC)

I changed an error in the "ADDING DATA" section it was quantiy now it quantiy_available to match the code in the table creation. Also I note when I SELECT * FROM fruit; I get 1's in the second column. after checking the mysql reference it is probably due to not specifying the "precision and the scale" http://dev.mysql.com/doc/refman/4.1/en/numeric-types.html I'm not sure if this is common with most kinds of SQL as I am just learning but... perhaps a note should be made --Caleb Wed May 24 20:42:40 EDT 2006

I reordered the introduction so that it now goes from Databases -> Relational Databases -> SQL -> SQL servers. The language commands were tried to be grouped into DDL and DML to make it easier for other people to find the right point for additions. --Lathspell 00:11, 7 September 2006 (UTC)

From IP talk page

I think that the assertion that SQL is "a method for specifying the means of requesting data..." is convoluted and incorrect. SQL isn't a method: it's a language. SQL also doesn't specify the means, or how to accomplish the task Rather, it specifies the ends: the desired or expected result of the operation. I added a more descriptive definition of SQL as a declarative language to further clarify this point.

I also removed the paragraph that incorrectly stated that SQL is non-programmable. Of course SQL is programmable, since it is after all a database programming language. I think the original author may have confused this term with non-procedural, which has quite a different meaning. In any case, I added a reference to the characteristics of procedural database languages to further clarify how the contrast between SQL as a declarative language. Further expansion of this topic could be useful to show the steps to perform a query using dBase/xBase code vs. SQL.

I also think the term metadata shouldn't be used without a definition or reference to its meaning, since it isn't a term that readers should be expected to know.

Introducing foreign keys without first discussing primary keys is not a very good idea. Foreign key specifications won't work without primary keys, so the CREATE TABLE example with the REFERENCES clause wouldn't ever work. Creating tables without primary keys is also a very bad example. I also noticed that primary keys are being used later in the examples, but with no prior description of them.

(thanks for moving my comments here - I'm a Wikibooks newbie).

 —The preceding unsigned comment was added by 76.175.21.1 (talk • contribs) 16:34, 24 Dec 2006 (UTC) 

Expansion of SQL description

I added several examples of simple SQL commands to give the reader a quick overview of what SQL syntax actually looks like in practice. I also expanded the discussion of how SQL is used in context with other languages, with a brief introduction to two tier client/server processing and middleware libraries. Additional examples showing SQL used within these other language contexts might be useful, however it's probably time to create additional pages to go into these details. --Sqldbaguy 03:48, 25 December 2006 (UTC)

printable version problem

The queries example are in scroll panes on the printable version, they should be in regular wrappable cells. Please feel free to MOVE this notice to some other page but the problem should be addressed and I'd like to know where it should be. --DynV 00:43, 1 March 2007 (UTC)

Comment on proposed merging MySQL implementations into this book

I would recommend against discussing any relational database implementation syntaxes. It tends to become a black whole of comparisons, or separate segments of a chapter that would be better served as a separate version of the text. This book seems to focus squarely on the subject of the general concepts that are consistent the SQL standards, thus should be to all implementations. My feeling is that it is best to learn the standard then go on to learn implementation, of which I now have implemented projects on MySQL, Oracle & SQL Server. The MySQL book is developing on it's own. Merging MySQL has two problems, first it would make it more difficult for those trying find content only for MySQL and second it would make this book loose focus on what is common between all implementations of SQL. Compounding this is merging MySQL indicate content on Oracle, DB2, and SQL Server all need to be added since all three have larger market shares than MySQL (at least as of 2005). 69.149.16.104 02:03, 6 October 2007 (UTC)

Extensions

I have plans to create some more pages for our book during spring and summer 2012. You can find a first draft of TOC at my sandbox. Comments desired!

As I'm not a native English speaking person, I like to get your support concerning accurate phrasing. You may write directly into my sandbox. --Kelti (discuss • contribs) 12:45, 19 March 2012 (UTC)

Good news. I have several advices for you :)

• SQL:2011 has been published three months ago. You have the chance to write documentation for this latest specification instead of the SQL:2008 specification.
• I think you'd rather add your pages one by one directly in the final location instead of writing your pages in a sandbox. Each time a page is finished, you can add the page in the summary. The documentation would be improved in real time. If someone modifies an existing page, you won't have to merge the content. And you know "Motivation lack always strikes when it shouldn't" :) To be sure your work will be merged one day, merge your work constantly.

Good contributions. Ftiercel (discuss • contribs) 20:18, 22 March 2012 (UTC)

I have finished the first block of five additional pages and will integrate them to the book mid of May. Please review them (content and my poor english phrasing) by correcting the text directly in my sandbox and give me feedback in discussion pages. Here is the link: User:Kelti/sandbox --Kelti (discuss • contribs) 10:02, 9 May 2012 (UTC)

OK. Ftiercel (discuss • contribs) 01:07, 11 May 2012 (UTC)

Further Extensions

I plan to merge the book at end of 2013 with the content of my sandbox and its subpages. There are ten new pages, which overlaps in form and content with existing pages. As my work is not finished I leave the old pages 'as is'. In the new version preliminary there will be two tracks: the 'classic track' with the unchanged, actual pages and the new 'evolving track' with the new pages. I/we shall move the classic track to the evolving track, so that it gets superfluous one day.

Some more comments:

• I use a new data model with 4 tables. I think this one is easierer to understand and at the same time an example of all possible relationships: 1:n and n:m.
• I have tested all statements against MySQL and Oracle. If possible, please test against MS SQL Server, db2 and postgres.
• The new pages focus on textual explanations, examples and exercises. The SQL syntax is of course also presented, but is not a priority.
• Please review the new pages (content and especially my poor english phrasing) by correcting the text directly in my sandbox.

--Kelti (discuss • contribs) 19:51, 16 December 2013 (UTC)

I will read that. Ftiercel (discuss • contribs) 21:18, 16 December 2013 (UTC)

Who is supposed to be target audience of this wikibook?

Because it looks extremely hermetic - mostly for tech geeks and academics. Nimdil (discuss • contribs) 10:06, 14 December 2017 (UTC)

In fact we tried to find a compromise between technical accuracy and feuetonistic length of the textual representation. This is done in the hope to address the (expected) typically reader of an IT related Wikibook: persons with a mid-term or even long-term interest on the topic ('junior geeks'). They differ from a typical Wikipedia user which seeks for a short-term explanation, e.g.: DB2 return codes, and from a Wikiversitiy user which seeks for general principles, e.g. relational algebra.

At the same time we focused the content to the books title: pure SQL standard - no implementation aspects, no performance aspects, no theory.

How can we improve the book?

• More detailed explanations in the text?
• More examples?
• Something else?

My observation is, that the more complex issues like 'window functions' are retrieved only by few readers. The basic issues have a higher page recall.

Kelti (discuss • contribs) 09:19, 15 December 2017 (UTC)

Standard and Classic Tracks : integration or maintain : discussions and actions

Hi all, This topic is created to discuss how to move forward with the Standard and Classic tracks.

In the Extensions and Further Extensions topics on this discussion page, a plan to merge the two tracks is described. This seems like a good plan to move forward with. Both tracks have positive features and cover the same knowledge domain.

The Standard track uses a consistent set of example tables throughout. This is helpful to the reader. The examples are nice. The exercises at the end of sections is helpful. The shorter sections are useful for the reader to learn a bit at a time.

The Classic track has a good introductory overview of relational databases. It also has a more visual display of tables and displays results so the reader can verify the commands on their own database system. Also the classic track is organized on by the main sections of the SQL language: Data Query Language, Data Manipulation Language, and Data Definition Language.

Each of the above distinctions are positive qualities and there are probably others too. Integrating these 2 tracks could make a stronger single track by combining these positive features.

Does this look like a good thing to do or are there other approaches?

DeCage (discuss • contribs) 17:44, 16 May 2019 (UTC)

I'm in favour of such a merge. The topics listed by DeCage are important - and I want to add a minor aspect. If you check the number of readers, you will recognize that only the first and second page of the classic track shows significant interest of the public. Therefor we can concentrate our efford to this two pages. And the last page 'DB2 Return Codes' shall not be part of the SQL wikibook - it describes an issue of one specific implementation. Concerning return codes SQL uses SQLSTATE. --Kelti (discuss • contribs) 14:05, 29 May 2019 (UTC)

The new start-page is reduced to the standard track. It contains two pages with introductory information about relational DBMS; it is structured for DQL, DCL, DML, and DDL; the used four tables are visualized in an ER-model; the tables are used in a consistent way for all examples and exercises. IMO we don't miss any critical text of the classic track. Please let me know if you believe that something important is lost. --Kelti (discuss • contribs) 10:08, 6 June 2020 (UTC)