SQL Fundamentals

Slashdot's own Robo takes a look at SQL Fundamentals, writing "This beginner book takes a traditional look at the ever-popular Structured Query Language. Never bothered to learn SQL? Here's your chance. SQL Fundamentals, by John Patrick, takes a 834-page beginners look at the application of SQL to Access and Oracle. Read more for SQL Fundamentals' strengths, weaknesses and everything in-between."

SQL Fundamentals
author	John Patrick
pages	800
publisher	Pearson Education
rating	7
reviewer	Rob ("robo") Oostendorp
ISBN	0130669474
summary	Truly a beginner friendly book for anyone needing a crash course in the basics of SQL; of limited but real use to those who already are familiar with SQL.

This beginner book takes a traditional look at the ever-popular Structured Query Language. Never bothered to learn SQL? Here's your chance. SQL Fundamentals, by John Patrick, takes the first layer of SQL in Access and Oracle [robo, I find this a confusing phrase, not sure how best to recast, but somehow] and sums it up in this 834-page manual. Read more for SQL Fundamental's strengths, weaknesses and everything in-between.

The Basics

SQL Fundamentals discusses the practical realities of extracting information from a database. Patrick shows the reader how to use SQL in both Oracle and Access. The book starts with a brief overview of the roots of SQL and relational databases; after this introduction, the book covers select statements and the basics of a query. Each chapter builds on the next, and the book follows a simple progression, adding complexity as it goes along.

This book is a very easy read -- it flows much better than a textbook, yet still conveys the information it promises. However, it's definitely for newcomers to SQL. So, if you have any experience in SQL this would not be the best choice. (Chapter 1 explains the concepts of a cell, row, column, and table, which might be enough to let you decide if this book is at the right level for you.) Throughout the book, the author relies on applying each newly introduced concept to a single relational database example. This hypothetical database (a table of employees trying to calculate their meal credits) makes the book feel consistent, and helps eliminate confusion about where the example information comes from, but it's also limiting for readers who want a broader range of examples.

One of the greatest strengths of this book is its wealth of code examples and accompanying tables. In contrast to many other manuals, this book illustrates queries along with their effects on the tables. Other SQL books (ones I consider going up to "layer 2" SQL) have many example queries, but some of them fail to show any sort of results from their example tables. Also, much of the code in SQL Fundamentals is well documented, with footnotes explaining any changes that occurred.

Caution: Beginner Book

The book is called SQL Fundamentals. However, in this case, the fundamentals are only as they apply to the Oracle and Access databases. It mentions the existence of other distributions at the beginning of the book: "Oracle, Access, DB2, MS SQL, Informix, SQL Windows, Sybase, SAS sql procedure, FoxPro, dBase, Tandem SQL, MySQL, SQLBase, Cold Fusion, SAP, Business Objects, ODBC, Ingres, Ocelot SQL, OsloData, PostgreSQL, Rapid SQL, XDB, SQL/DS, Mini SQL, Empress, Interbase, Progress, Supra, SQL Report Writer, Paradox, Delphi, VAX SQL, Essbase, Beagle SQL, GNU SQL Server, Just Logic/SQL, PrimeBase, Altera SQL Server, DataScope, and PowerBuilder." However, Patrick never speaks of them again; perhaps he should re-title this book SQL Fundamentals: Applied to Oracle and Access? Readers considering this book should keep this in mind. The book explains things well, but the book's overall logic is geared toward those using one of those databases, and the examples are relevant only in that context.

I primarily use MySQL and Progress, so a book explaining SQL fundamentals applied to Access and Oracle isn't going to help me unless I specifically take on projects which use these particular databases. Also, The book often goes into unneeded repetition of subjects: for instance, the first 150 pages are all about select statements. I've never seen so many select statements picking apart one table. I personally think it would benefit from being trimmed down, and leaving further study to the reader.

The Plug

I would recommend this book to a newcomer to SQL. It covers the fundamentals just like it claims. After finishing this book, you will have a grasp on things ranging from the most basic select statements to unions, self joins, & cross-joins.

Something to consider might be what SQL database you will be working with. If you'll be working with either Oracle or Access this book will be helpful. If not, I suggest looking at things like Managing Using MySQL by O'Reilly.

Finally, from the text comes this concise answer to the question "Who Should Read This Book?"

Everyone with an interest in getting information from a database can read this book. It can be a first book about databases for people who are new to the subject. You do not need to be a computer programmer. The discussion begins at the beginning and it does not assume any prior knowledge about databases.

That seems like a fair summary; with the caveats already mentioned, I can recommend it for newcomers to SQL looking for a thorough but not patronizing introduction.

---

You can purchase SQL Fundamentals from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

834 pages?!

[FyRE666]

How big is the typeface? I mean, come on, it's not that big a language after all and you could easily fit the basics into 50 pages at most...

SQL

[sql*kitten]

Something to consider might be what SQL database you will be working with. If you'll be working with either Oracle or Access this book will be helpful. If not, I suggest looking at things like Managing Using MySQL by O'Reilly.

I would suggest not, because you will learn bad habits, and they will be hard to shake once you start working on a real database (Oracle, Sybase, SAP-DB, etc). I have seen MySQL programmers do massively inefficient (and stupid) things like retrieve a list of keys from one table, store them in an in-memory array, then loop through the array executing a select for each key in another table - because they didn't know about subselects. I've seen them put all sorts of redundant validation crap in the middle tier because they didn't know about constraints and triggers. I could go on and on...

If you want to learn SQL, you first need a solid general foundation like this [amazon.co.uk] (I have an earlier edition) then later study the extensions that each vendor provides (Oracle PL/SQL, Sybase T-SQL, etc).

Re:834 pages?!

[micromoog]

Not having seen the book, I'm assuming much of it is dedicated to relational database concepts, explained via SQL. 834 pages is about right for an introduction. "Real" relational database design is a lot more complicated than most people (programmers particularly) realize.

You could list and explain all of the syntax for C++ in just a few pages, but I wouldn't call you a C++ programmer after reading it.

Underestimating the complexity of SQL?

[JohnDenver]

First of all, you do have a point. SQL isn't a big language with a lot of features, but if you had really spent a lot of time working with SQL, you would know that SQL is a language usually implemented with A LOT of nuances, and that many problems that are easy in procedural languages that take a lot of work with SQL.

SQL is a powerful tool, but solving many problems with SQL can be very daunting at times, especially when you're dealing with vendor specific nuances.

Re:834 pages?!

[sphealey]

I'd say a good intro to ANSI-standard SQL could probably be done in 30 pages.

SQL is like chess: 1 hour to learn. 8-12 hours to figure out how to play. 5000 hours to determine whether or not you actually understand it.

Don't get me wrong - you can do useful work in SQL with 20-30 hours of practice. But if you think that SQL can be taught in 30 pages you do not understand it.

sPh

Re:834 pages?!

[Usquebaugh]

Rubbish, chess is a very poor analogy for SQL.

SQL is a tool to interrogate RDBMS. For most IT people it takes a couple of hours to get to grips with basics of select, update etc Joins, sub queries come next.

You can do useful work in one hour of tuition. We have users using SQL after maybe two hours. 20-30 hours of practice, what the hell are you trying to do?

SQL is BAD

[HunkyBrewster]

You would be much better off starting with an introduction to relational database theory. (Notice I did *NOT* say SQL database theory.)

I have found http://www.dbdebunk.com/ [dbdebunk.com] very informative. If you insist on cutting down trees, I would recommend any of the books that this site links to.

There are fundamental problems with SQL. You may well be forced to work with it but you should at least know what its limitations are.

Hopefully, once you truly understand the problems with SQL, you will see the light, rebel, tell Oracle et al to go screw, and help develop some nice good Open Source alternative to the crappy SQL language.

If you disagree, you are welcome to touch me lower.

Re:SQL

[NineNine]

hahahahaha... After 10 years of doing development, all of it with databases in the back end, I know people like you very well. People who don't understand databases don't know how to use them, and code all of the logic into the middle tier. Very typical. It leads to horrendous bloat, very poor performance, and occasionally, complete project collapse. In one case that I was involved in, the company closed because their project couldn't be done on time since they decided to listen to this "expert" who spouted off similar stuff like what you're saying. The project became an OOP mess that was impossible to debug and maintain. More importantly, performance was never acceptable, so the project and the company died.

Databases, especially "grown up" ones like Oracle and DB2 are designed and optimized to do a hell of a lot more than data storage. If you want storage, use flat files. You should maybe, I dunno... pick up a book. You can write entire applications in nothing but PL/SQL that perform several times better than a similar C++ or Java app.

In fact, so much development is done in the databases themselves, that Oracle has a certification just for that, called the Oracle Certified Application Developer. But alas, generally these days everyone is still running around screaming "middle tier! middle tier" while the real database gurus just sit back and laugh as projects implode.

Re:834 pages?!

[lostboy2]

IMHO, comparing learning SQL (or m/any technical subjects) to learning chess is a good analogy:

For most IT people it takes a couple of hours to get to grips with basics of select, update etc
This coincides with the sphealey's "1 hour to learn"

Joins, sub queries come next.
This seems to fit with "8-12 hours to figure out how to play".

The "5000 hours to determine whether or not you actually understand it" may be an exaggeration, but the point is that the nuances take a long time to master.

"you can do useful work in SQL with 20-30 hours of practice" sounds like a ballpark figure to me, but seems reasonable. "useful work" might be a bad choice of words, but I think the point is valid.

In my opinion, it's like the difference between someone who knows how to follow a recipe and someone who knows how to cook: after a couple of hours, one could be trained to follow recipes -- but it takes longer than that (and a lot of hands-on experience) in order to be a good cook.

Re:SQL

[pnatural]

there's a middle ground between all or no logic in the "storage layer"

of course. brilliant observation.

tables thems selves contain application logic

not my tables, and not any tables from the developers on my team.

checking row types, etc.

this isn't application logic, it's data integrity.

"hey, you're using that querry quite a bit, how about we just compile it all up in the database for you and speed things up a bit, eh?".. bang, code reuse.

sorry, that's not code reuse at all, not even close. give me a [stored proc|view|table] that i can inherit from or subclass, and that would be reuse.

but those who spend 500,000$ for their RDBMS software package will keep it around for a tad.

and one of the reasons that they'll "keep it around" is because they paid so damn much for it. why lock in an implementation decision for so long? it doesn't promote agility, nor does it promote flexibility. quite the opposite, it encourages poor SQL coding (i.e., vendor-specific features). it's called the "Golden Hammer" Anit-Pattern. look into it.

most companies have terabytes of data stored in their schemas

um, no. gigabytes, maybe, but most companies have databases in the terabyte range? i don't think so.

you might find that if you take out all those i's and use lots of we's for the good of the compnay, you'll still get some credit

funny, it sounds as if you haven't read _The Mythical Man-Month_, wherein Brooks asserts that the best software systems come from a single mind. if you're a professional software developer (it's hard to tell from your post), i strongly suggest you read it.

as to credit, i'm not in it for that. rather, what motivates me is implementing solutions that help achieve the objectives of the company for which i work. see, i'm a stock holder as well as an employee, and i'm just as motivated by profit as the CEO.

on another point, maybe should note that a great sense of ownership leads to pride in work and higher quality. (to be sure, there are pitfalls associated with too great a sense of ownership, but experienced developers know when and how to cut the cord, so to speak)