Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming Books Media Book Reviews IT Technology

SQL Fundamentals 233

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.

This discussion has been archived. No new comments can be posted.

SQL Fundamentals

Comments Filter:
  • by Mr Bill ( 21249 ) on Wednesday November 06, 2002 @12:07PM (#4608228)
    Do you pronounce it Sequel or S-Q-L???

    To me it is Postgres-Q-L and My-S-Q-L, but I think the Microsofties call it Microsoft Sequel Server...

    Maybe good for a /. poll!
  • by ekrout ( 139379 ) on Wednesday November 06, 2002 @12:10PM (#4608246) Journal
    With OS X came a bundling of MySQL, and CTOs (Chief Technology Officers) across the country thought to themselves that "Hey, if a big profitable company puts this package of OpenSource software into their flagship OS, it must be OK to use. Let's stop dishing out tens of thousands of dollars a year to Oracle and let's just use this free RDBMS implementation. (Sure, PostreSQL is a bit more weathered, but both are pretty nice considering their price).

    Wider acceptance of MySQL and its related products/technologies is a good thing, and books such as this are only a good thing in my mind.
  • Standard SQL? (Score:4, Interesting)

    by K-Man ( 4117 ) on Wednesday November 06, 2002 @12:16PM (#4608323)
    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.
    A statement like this needs a bit of support. Does the book use proprietary features of Oracle and Access? Most of the basic parts of SQL are the same on all platforms.

  • by sql*kitten ( 1359 ) on Wednesday November 06, 2002 @12:26PM (#4608411)
    Let's stop dishing out tens of thousands of dollars a year to Oracle and let's just use this free RDBMS implementation

    For the last few years, my career has largely been based on Oracle products, so I have as vested an interest as anyone (save maybe Uncle Larry) in seeing Oracle continue to be the #1 choice for corporate databases, but I've got to say, if you even can run your application on MySQL, you really shouldn't have bought Oracle in the first place, because you've completely wasted your money. Only buy a product like Oracle (or Sybase, DB2, etc) if you know that you need its capabilities. If your application doesn't need subselects, triggers, real transactions, etc, then you might as well use MySQL, or even CSV on the filesystem!

    Oh, and the R in RDBMS means "relational". Correct me if I'm wrong, but MySQL needs a plugin to even do foreign keys - you should really say just DBMS.
  • by Anonymous Coward on Wednesday November 06, 2002 @12:27PM (#4608419)
    There is an element to database design that is a subfield of calculus. Just learning the syntax for CREATE TABLE and SELECT doesn't really get you very far. Understanding why relational sets are powerful, and being able to leverage that power to problem solving ends, is a far bigger learning process than simply understanding the syntax of SQL.

    In order to fully comprehend, say, the works of E. F. Codd, one really needs a background in automata and in abstract algebra.

  • by sql*kitten ( 1359 ) on Wednesday November 06, 2002 @12:32PM (#4608459)
    It in fact is Postgres-Q-L and My-S-Q-L, but you use "sequel" to query both of those. I haven't seen anyone in a long time pronounce the language name S-Q-L, the names of the two products you mentioned are dictated by their respective developers, so it's a different matter. (incidentally, I'm as far from a Microsofty as it gets)

    It is properly S-Q-L because Sequel is something different (Structured English Query Language, an IBM project that never went anywhere). But the term "sequel" for SQL has come into common use, so it's the de facto pronounciation.

    Microsoft people just call the product "SQL Server" which IMHO is like calling Windows "Operating System" but it comes from the old days when Sybase and Microsoft cooperated (circa MSSQL 4-6/Sybase 10). Sybase's product was called "Sybase SQL Server", but people just call it "Sybase" (akin to calling Windows "Microsoft"). When they split, MS kept the rest of the name.

    You can easily spot a hardcore elite database guru by the fact that these people pronounce it "squirrel".
  • by SailorBob ( 146385 ) on Wednesday November 06, 2002 @12:43PM (#4608573) Homepage Journal
    I use technical books to learn new subjects quite often, and a book that has 834 pages can't be considered a descent beginners book, prima facia. Something that big is more on the level of a reference book.

    A beginners book should be concise. Take Kernighan's, The C Programming Language [amazon.com]. 272 Pages for learning one of the most important languages in computer science. Just you, the language, a few demonstrative exersices and that's it.

  • Newbies and SQL (Score:3, Interesting)

    by boy_afraid ( 234774 ) <Antebios1@gmail.com> on Wednesday November 06, 2002 @12:48PM (#4608620) Journal
    Great, another book for dummies. I'm in a group where everyone thinks they know SQL and are gurus. Hell, the don't even know what an index is used for? In fact, there is not one index in their entire 60 GB database, that's why I'm here, tuning the system. But, with this new "Fundamental", you need to get the user off on a good start. I think the first half of the book should be dedicated to the methodology or go through each methodology and have an example for each one. Okay, I can understand showing a newbie how to creat a SELECT statement, but also show how creating an index will greatly speed up said SELECT statemement.

    Oracle is NOT a good system to start of with SQL, I think MS Access nice start, but Access SQL is syntax slightly differenct than the standard SQL-92. Also, Access has the PIVOT keword which does not exists in T-SQL and doesn't do the same think in PL/SQL. PIVOT is great, but is not a standard. This book needs to also show common problems and how they are solved using standard SQL, not propietary.

    One thing I think Access has that is better than any other enterprise database system is it's query creation tool. I know MS SQL has finally added such a tool, but it comes nowhere near as easy to use as MS Access. And for strength of SQL I think Oracle wins, hands down, but for administration, you can't beat MS SQL Server. For turning, you can make a career out of Oracle. Granted, I have used Informix, Sybase, and Approach as well as Access and SQL Server, so my comparisons are going to be with Oracle, SQL Server, and Access.

    Newbies need to learn how to design databases, drill them into they are spouting normalization on the streets. Also, get the newbies to learn to use lookup tables, DO NOT USE CHARACTER FIELDS to index or do searches on, USE NUMERIC, INTEGER, FIELDS! All the training in SQL is not going to do a bit of good if it takes an hour to retrieve a dataset that could have taken a few minutes with the correct indexes.
  • by MattRog ( 527508 ) on Wednesday November 06, 2002 @12:57PM (#4608726)
    Having FK support does not make one a Relational DBMS. To those who are 'in the know' [dbdebunk.com] Oracle, MS SQL Server, even my beloved :) Sybase ASE etc are SQL-Based DBMS. SQL, to put it mildly, butchers most relational tenets and is not how Codd wanted it to work in the first place (enter IBM and SQL language).

    But in the least case MySQL supports relations (tables) so it has, to some degree, a relational background. FK support is required according to Codd, but virtually all DBMS also break some of his other rules as well, so it depends on how deviant a product must be before it is declared non-relational.
  • Re:SQL (Score:3, Interesting)

    by joshv ( 13017 ) on Wednesday November 06, 2002 @01:15PM (#4608916)
    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...

    Validation logic belongs in the middle tier. The storage tier is just that - storage. It shouldn't be smart, and it very definitely should do anything else than storing the data I tell it to store.

    Triggers, constraints - bah. All very vendor specific and they lead to application logic being strewn all over the tiers. Application Logic should be in the middle tier, period.

    -josh
  • by Frater 219 ( 1455 ) on Wednesday November 06, 2002 @01:24PM (#4609008) Journal
    Oh, and the R in RDBMS means "relational". Correct me if I'm wrong, but MySQL needs a plugin to even do foreign keys - you should really say just DBMS.

    Actually, I've heard some folks take issue with the "M", on the grounds that a system that does not ensure relational integrity and transactional atomicity is not providing database management. Considering that many mySQL supporters bracket their support by saying that it is strongest for read-mostly databases (placing it in a category with LDAP's slapd), I would feel comfortable calling mySQL a "database daemon".

    (For my own reasons to choose PostgreSQL, and some links on the subject, see my Slashdot journal [slashdot.org] about my current work project.)

    For what it's worth, I'm glad that the mySQL folks have largely quit telling untruths about relational databases. A few years ago, they were saying in the mySQL documentation that foreign key constraints are for lazy programmers, and that anything that can be done with transactions can be done just as reliably with application code. (Imagine here Jamie Lee Curtis saying "Those are all mistakes, Otto. I looked them up." [imdb.com])

  • 834-pages ? (Score:2, Interesting)

    by avandesande ( 143899 ) on Wednesday November 06, 2002 @01:48PM (#4609266) Journal
    How is this a beginner's book? A much smaller book will do. Maybe K&R should write one.
  • by Tablizer ( 95088 ) on Wednesday November 06, 2002 @02:10PM (#4609479) Journal
    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.... [emph. added]

    It seems that many OO fans have a desire to create their own "database" from scratch via programming code, and treat the RDBMS as mere "persistence". They end up using array-like things to manage their own indexes for one-to-many and many-to-many relationships, for example.

    This is a widely accepted practice in the OO community. I really don't want to maintain such code.

    It seems many OO fans want "control". If you use the database for such things instead, then you are more dependent on the DB vendor and DBA's, and that bothers them.

    I agree that DBA politics can be a bottleneck for developers at times (would make a great ./ topic), but the proper solution is NOT to write your own database and index managers from scratch. If you want to get out from under the DBA's thumb, then try some other approach besides using arrays for indexing and manually-written joins.

    (Note that I did *not* say that *all* OO fans avoid or mis-use databases. I am only saying that it is too common a practice. Thus, I am not really bashing OO here, but a bad practice often found in OO shops, for whatever reason.)

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...