Talk:Structured Query Language
From Wikibooks, the open-content textbooks collection
Contents |
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
