Follow Slashdot blog updates by subscribing to our blog RSS feed

 


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

SQL Fundamentals 233

Posted by timothy from the grabbing-data dept.
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 More

SQL Fundamentals

Comments Filter:

  • Anyone Know? (Score:3, Funny)

    by laeraun2 ( 472996 ) on Wednesday November 06, 2002 @11:03AM (#4608184) Homepage
    When the SQL to this book will be out? Har de har har har.
  • This books sounds like a good read for those of us who know nothing about SQL databases. I am always up for learning new code and systems. I still consider myself a newbie on many computer topics so books like these always seem to help out.

  • 834 pages?! (Score:4, Insightful)

    by FyRE666 ( 263011 ) on Wednesday November 06, 2002 @11:07AM (#4608222) Homepage
    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...

    • Re:834 pages?! (Score:5, Insightful)

      by micromoog ( 206608 ) on Wednesday November 06, 2002 @11:32AM (#4608462)
      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.

    • 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.
    • Did you not read it includes working with Oracle? I am surprised they could get it in under 1000 pages.

  • The age old question... (Score:4, Interesting)

    by Mr Bill ( 21249 ) on Wednesday November 06, 2002 @11:07AM (#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!
    • 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)

      • Re:The age old question... (Score:5, Interesting)

        by sql*kitten ( 1359 ) on Wednesday November 06, 2002 @11:32AM (#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".
    • AFAIK almost everyone says sequel, not just M$ites. What really has me wondering though is, is it Lynnucks or Line-ex and how do you say that Bjarne guys last name?
      • Actually, usage changed sometime around 1994. Prior to that most people said "Ess - Que - Ell"; after that date people started saying "see-quell". Never did understand why the change occured.

        sPh

        • Actually, usage changed sometime around 1994

          I think it started happening before then. I was doing SQL stuff back in the 1990 timeframe (even interviewed at Ingres and Sybase) and everyone I knew was saying sequel even back then. It might have been a Bay Area thing though, or maybe even specific to the "upstart" db's, don't know what the IBM or Oracle camp was calling it.
      • "Linn uks" would be the closest American accent equivalent. In Torvalds' accent, it's "Leen ooks".
      • No need to respond to my linux or bjarne comment, I was joking, I've heard the pronunciations, please, stop :)

    • Re:The age old question... (Score:4, Funny)

      by beacher ( 82033 ) on Wednesday November 06, 2002 @11:16AM (#4608322) Homepage
      It's Microsoft Squeeeeeal! Server (say it in your best deliverance voice )

      Todd

    • I here you. I always get confused with 'C'. Is it pronounced "See"? Or as I like to refer to it: "C".

      My coworkers like to read the "Fack" when they need help. If people ask me, I just tell them to consult the "Fa" "Q".

    • It's always pronounced S-Q-L. However, Microsoft (and Sybase) call their product "Sequel" Server. You see, Microsoft "Sequel" Server is basically the brand name of a satabase server that uses S-Q-L, in the same way that "Orace Enterprise Edition" is the brand name of a database server that uses S-Q-L, or "Apache" is the brand name of an HTTP server.

      So, it's correct to refer to Microsoft "Sequel", as long as you understand that you're talking about the product, and not the language.
      • It's always pronounced S-Q-L.
        That's a pretty bold, and false, statement. Some people may pronounce it that way, but most DBAs and database programmers I know (myself included) pronounce the language SQL as 'sequel' and some implementations or extensions of SQL by their name plus the initials 'S Q L.' For instance, the database MySQL would be pronounced 'my S Q L,' PL-SQL as 'P L S Q L,' and so on.
    • Maybe good for a /. poll!
      And like most /. polls, my answer isn't listed.
      I pronounce it "squirrel". I worked in a place where everyone said "sequel" and I hated that name. The strange thing is, I don't know why. I just did.

    • Re:The age old question... (Score:4, Funny)

      by mtDNA ( 123855 ) on Wednesday November 06, 2002 @12:34PM (#4609100) Homepage

      Dear Slash-Dotters,

      I can't believe how clueless you guys are. Everybody knows it's Structured QUERy Language, or
      SQUERL, which is properly pronounced _SQUIRREL_.

      Sincerely,
      Steve

  • Learning Postgres Online (Score:5, Informative)

    by johnalex ( 147270 ) on Wednesday November 06, 2002 @11:09AM (#4608237) Homepage
    If you need to expand your SQL to include PostgreSQL, try:

    PostgreSQL: Introduction and Concepts [postgresql.org] by Bruce Momjian

    Practical PostgreSQL, by Command Prompt, Inc. [commandprompt.com] written by John Worsley and Joshua Drake of Command Prompt, Inc.

    Very practical definitions, examples, and procedures. I'm still scratching the surface of SQL, so I haven't found anything yet these sources can't handle.

    I've also found the Usenet Posgres groups useful.

  • SQL (Score:5, Insightful)

    by sql*kitten ( 1359 ) on Wednesday November 06, 2002 @11:09AM (#4608245)
    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:SQL (Score:3, Interesting)

      by joshv ( 13017 )
      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

      • Re:SQL (Score:5, Insightful)

        by NineNine ( 235196 ) on Wednesday November 06, 2002 @12:47PM (#4609251)
        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.
        • 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.)
          • I agree that DBA politics can be a bottleneck for developers at times

            In good teams of developers (in which I've only gotten to work a few times), the developers and the DBA's work very closely together. The DBA creates the sandbox for the developer to work in, handles backups, helps with occasional optimizations, etc. In most shops, developers think that they understand databases if they can write simple SELECT statement. They just have no clue, whatsoever, as to what databases can do and what they can be used for.

            I was lucky enough to learn the hard way... I was pushed straight into development with a very, very brutal Oracle DBA. He knew more than I've forgotten in my lifetime, so I learned the right way to write apps. Most programmers never get that opportunity, so you're right, they treat databases as nothing mroe than a data dump. Hell, most people have no idea as to the scope and size of just Oracle's product offerings that all work with their databases.

        • Re:SQL (Score:4, Informative)

          by pnatural ( 59329 ) on Wednesday November 06, 2002 @02:28PM (#4610361)
          No, no, no... how do I say this? NO!

          The OP is completely correct: triggers and such are rubbish (except to enforce data integrity when the integral RDBMS mechanisms cannot). DBs are for storage, period. You claim that a DB is a great place to shoe horn logic, but that leads to problems.

          1. The bloat is in a functional-programming layer (SQL) instead of a procedural/OO layer. Given a choice between lotsa logic down in a DB and lotsa logic in my app, I'll take the logic in my app any day of the week. SQL does not promote code reuse, whereas most procedural and OO languages do promote it to some degree.

          2. The more code you put in a DB, the less portable your schema is -- and I'm not talking about platform portability, I'm talking about RDBMS portability. Nothing is worse than [IBM|MS|ORA] database lock-in.

          3. The poor performance you site may be common in your experience, but code in the middle layer(s) is not the cause of that: bad design and poor testing are the causes. Don't confuse correlation with causation.

          These points are backed with experience: I've been programming for 15 years, 7 years of that using databases heavily. The company I work for now has terabytes of data stored in the schemas I've developed for my apps, and no one has ever complained about maintenance or performance on one of my designs.

    • Re:SQL (Score:2, Informative)

      by HunkyBrewster ( 578901 )
      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.

  • MySQL gains more users thanks to Apple (Score:3, Interesting)

    by ekrout ( 139379 ) on Wednesday November 06, 2002 @11:10AM (#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.
    • 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.
      • 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.
      • 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])

      • 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.

        The problem comes if/when you scale up. It is a pain to overhaul applications to accept a stronger DB from a different vendor.

        IMO, what OSS needs is a lite-duty DB and a heavier-duty one, but the smaller one is a clean subset of the bigger one. MySQL and Postgre have different conventions. It is not a matter of plug-and-play to switch. But, it *could* be if they coordinated efforts to make the language and features more consistent between them.

        Or, even an OSS Oracle clone. It might benefit Oracle to do such because people would use the OSS to get started, and later if they need more power then purchase the commercial version.

        The cost of incompatibility is often higher than the DB product cost itself. People want to be able to up-grade (and down-grade?) without overhaulling the application's SQL calls. Such a thing does not exist in OSS right now.
    • 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.

      Yes, the mindset of the fortune 500 lives or dies by what Apple does. "Hey I wouldn't buy any of their overpriced computers but if they think MySQL is great, it must be".

      MySQL is pretty good though. Ah hee ah hee hee
    • I'm a CTO and choosing product worth on what a particular vendor says would get me fired. Products stand on their own merit and are evaluated as such.
  • about the book:
    It mentions the existence of other distributions at the beginning of the book: "... and PowerBuilder."
    I know I stopped using PowwerBuilder with the version 7, and the version 9 is out, but at that time, it was not a SQL database, only a client for SQL databases.

    about SQL:
    SQL is a langage with which it is really easy to obtain a result that is not what you intended.

    • I know I stopped using PowwerBuilder with the version 7, and the version 9 is out, but at that time, it was not a SQL database, only a client for SQL databases.
      I'd place that in the same company as Access, which the book apparently talks about extensively. Sure Access has its own DB back end, but it sucks. People who need to do real work with it use it as a front end to a real database.

      Does anybody know if this book talks about using Access by itself, or if it treats Access more in the context of accessing Oracle?

  • When I first started making dynamic web pages, I used access. I used acces for various reasons. 1. It was on a computer at school. 2. I was running win 98 at the time. Not many good databases will run with 98. Even though I wanted a database to keep track of things, I only had one option.

    Even though I layed out the database in access, I didn't touch access after the file was created. I then moved to personal web server (an all the security holes that creates) to manipulate the database through ASP.

    I know there are many others that because of various reasons are unable to get their hands on other databases, if you get the fundementals of sql through access, you are able to understand the majority of sql statements having to deal with other databases. Even though,things do differ, you have somewhat of a foundation to understand sql.

  • Standard SQL? (Score:4, Interesting)

    by K-Man ( 4117 ) on Wednesday November 06, 2002 @11:16AM (#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.

    • Well, to start with, MySQL doesn't use anything even approaching standard SQL. As near as I can tell, some crack-addled monkeys briefly read a "Teach yourself SQL in 21 days" book before they wrote MySQL.

      I don't know what Access does now, but in the past it too basically just ignored the SQL standard. At least we can trust that the Microsoft programmers were aware of the existence of the standard while they ignored it.

      If you want a decent, reasonably compliant SQL engine, you'll probably use Oracle, Microsoft SQL Server, or PostgreSQL. Of course, once you actually use any of those, you'll quickly discover the huuuuuge differences in implementation... It turns out that following the standard hardly matters as much as anyone thought...
    • Most of the basic parts of SQL are the same on all platforms.

      Yes, but most of the deliciously interesting features of Postgres (and other systems) is the proprietary stuff... mmmm, regular expressions...

  • I think the SQL in a Nutshell is a great resource, but if you're just starting with SQL this sounds like a decent book, would be nice to have a comparision though. I've lost track of how many times I've had to explain what the first chapter covers (cell, row, column, table, etc). Maybe I should keep a copy around just to loan out in such cases. "Go read chapter one and come back later, then try tell me what you want done."

    PS: Amazon has it for $34.99 [amazon.com] [associate]
    • PS: Amazon has it for $34.99 [associate]
      And Bookpool [bookpool.com] has it for $29.95 [bookpool.com] and has the added benefit of having 95% less Evil than amazon. (That's a rough guess on the Evil count, btw, not a scientific measurement.)
  • Quick way (internet) Step 1: go to mysql.com and download mysql
    Step 2: go to google.com and enter:
    +mysql +sample

    Step 3: Spend some time reading, figure it out.

    Standardized way (book) The advantages of a good book are mainly in the way of standardization and security. While I've seen books that were crap in reference to this, most do a much better job of providing code samples than the underinformed indivuals writing "samples." That being said, major sites like Zend.com and php.net still provide good examples etc, but in that case you need some fore-knowledge to know what to look for.

    All IMHO of course. Many of us are "example learners" as opposed to "book learners".

  • For More Advanced... (Score:5, Informative)

    by glenstar ( 569572 ) on Wednesday November 06, 2002 @11:22AM (#4608385)
    For the more advanced, I *personally* would recommend Joe Celko's SQL for Smarties [amazon.com]. Celko is a rather bizarre character, but there is no problem that he cannot solve using ANSI92 SQL. None.

    If you want to make the developers/DBAs/bosses in your company think you are an absolute god, get a copy of Celko's SQL Puzzles and Answers [amazon.com].

    • Re:For More Advanced... (Score:2, Informative)

      by SPiKe ( 19306 )
      Yes, but Celko's examples tedn to shoot off in the acamedic (read: features not implemented by any vendor).

      If one wants a fairly good book on SQL (though oriented towards T-SQL, and a lot towards Microsoft), Ken Henderson's "The Guru's Guide to Transact-SQL" is good. Ken also lists Celko as one of his major influences.
    • Here another "Advanced SQL" books I can recommend for serious SQL developers: First book is the only good book about SQL standard I found. You can learn lots yourself and you can teach (if you are a teacher or a project leader) other developers.

      The second one very well explains when and why "pure" SQL doesn't work [well] anymore.

      By the way, Date is not less bizarre character than Celko, neither he is less productive author. Especially together with Darwen.

  • Learning SQL doesn't give you all the skills (Score:2, Interesting)

    by Anonymous Coward
    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.

  • I've just started teaching myself SQL a bit. Languages are easy, the problem is I don't have any formal training in databases, so while I can make a database do what I want I'm also probably doing it terribly inefficiently.


    If I wanted to learn the theory behind designing databases what would be a good book to read? I'm thinking more along the lines of learning from a text book v.s. learning from The Blithering Idiot's Guide to Database Design.

    • I'm thinking more along the lines of learning from a text book v.s. learning from The Blithering Idiot's Guide to Database Design.
      On a somewhat-related but quite off-topic note, is anyone else totally sick of "Idiot's Guide to This" and "Whatever for Morons" books? I'm not an idiot or a moron! I'm a reasonably intelligent person who just happens to have little experience in the field you're writing a book about! That's the kind of book I'd buy. The Reasonably Intelligent Person's Guide to Database Design.

      I refuse to give money to companies that try and make me feel like an idiot.

  • Does anyone else find their choice of databases funny? I could see MS SQL & Oracle, but aren't Access & Oracle two totally different beasts?

    Access is for small db's, usually personal ones or very small business databases. Oracle is a big enterprise database capable of storing huge amounts of data.

    Isn't that kind of like writing a book teaching you an introduction to writing batch files and mastering C++ all at once?
    • ...It's just the number of people that actually use MS Access is like 10000 times greater than the number of MS SQL implementers. Besides, if you know the SQL part of MS Access well enough, you'll already hit the ground running with MS SQL's T-SQL.

      Oracle too is used alot more than MS SQL, but Oracle's PL-SQL is a different beast from T-SQL. Hence, you get 'reasonable' coverage of the SQL spectrum...

      In an age where there's entire sections of bookstores dedicated to "Dummies" it's great to see authors giving due credit to their reader's intellect by showing them not just 'where to begin' but 'how far up you can go'.

    • i guess it shows you how to apply your newly found SQL knowledge on a small scale (access) and on an enterprise level (oracle)...also, i would think that access would be a good starting point for a someone who had no previous database experience...
  • 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 @11:48AM (#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.
    • DO NOT USE CHARACTER FIELDS to index or do searches on, USE NUMERIC, INTEGER, FIELDS!

      That's not necessarily correct. With many database systems short char fields work just as well for indexing as integers, with negligible performance difference. And sometimes are a lot more useful, for example, people can work with 4 and 5 character alphanumeric barcodes fairly well, but not necessarily with their numerical counterparts.

  • Try The Practical SQL Handbook: Using SQL Variants [amazon.com]. It's much shorter at 450 pages and is a very good book for the person just learning SQL and databases.

  • so a book explaining SQL fundamentals applied to Access and Oracle

    Wow! Oracle and Access mentioned in the same sentence without sarcasm or outright laughter. Someone please note the date and time.

  • Life query (Score:2, Funny)

    by DarkHelmet ( 120004 )
    select * from Programmers where MysqlKnowledge = 1 AND SexLife = 1;

    > Error, column SexLife does not exist in this table.

  • SQL is BAD (Score:2, Insightful)

    by HunkyBrewster ( 578901 )
    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.

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

    by avandesande ( 143899 )
    How is this a beginner's book? A much smaller book will do. Maybe K&R should write one.
  • I would like to see SQL overhauled. It could be replaced with a functional-like syntax (FP) where you reference stuff instead of only nest it. Nesting gets really messy for bigger stuff because it splits "lists" in halfs and separates the halfs by jillions of miles. Plus, you cannot reference repeating sections in SQL without writing views, which requires bothering the grumpy DBA.

    A functional syntax would also allow one to add extensions without worrying about ruining the parse tree. Thus, if Oracle had something that Sybase did not when you switched vendors, the DBA could write their own library function to match it. A shop can't add to SQL very easily on their own because of the complexity of the language. FP syntax is more modular.

    The longer we wait, the more SQL will become entrenched, due to books like this.
    • FP syntax is more modular

      I agree with you. Almost.

      But which FP syntax do you mean? Lisp? ML? Or Haskell? Their syntaxes are quite different. How would you define FP syntax?

      And why DB products with "ugly" SQL syntax are more popular than ""pure" FP DBMS FramerD [framerd.org]?

  • "Beginners" guide should really be these three lines:

    To select something
    select columnname1, columnname2 from tablename where columnname1 = 'thevaluetogetby';

    To add a line to the DB
    insert into tablename (columnname1, columnname2) values('value1', 'value2');

    To update a line
    update tablename set columnname1 = 'value1', columname2 = 'value2' where columnname1 = 'thelinetoupdate'

    THAT is a beginners guide. I don't know what the other 833 1/2 pages have... Sure some people consider all the different joins to be "beginner" but I'd call that stuff intermediate.

    Travis
  • Sure, this book will help you learn SQL syntax (maybe they ought to have named it "SQL-Primer Plus") and elucidate the schemas found in your favorite LAMP (linux, apache, mysql, perl/php/python) guides, but how will this help teach people the fundamentals of good database design? Sounds like this book will just churn out even more people who can just add "I know SQL and how to build databases" to their resume even though they will give you a blank stare when you ask about normalization. Like how using MySQL for 'learning' purposes leads to bad habits, I fear that this book might also promote loose discipline in web-based-database-applications. If I am contracting someone to build me an ecommerce site and know they have read this book, they won't be hired.
  • A book that I found very helpful for learning SQL is Sams Teach Yourself SQL in 10 Minutes [samspublishing.com]. When I first started learning SQL I mostly got everything from the early Slashcode sources and the MySQL manual as I needed it - not the best way to learn :-). I was a bit skeptical about the "10 minutes" approach, but each of the chapters actually did work out to about 10 minutes and the information was easy to understand (may have helped that I already knew some about SQL) and was fairly thorough. Another point that I really liked about it is that for the most part it only talked about the SQL standard, not just how one vendor implemented it. However, if an important vendor differed in their implementation, they would talk about it. This worked out great for me because I just wanted to know SQL basics and "best practices" and could figure out vendor specifics from their manuals.

Slashdot Top Deals

Whatever is not nailed down is mine. Whatever I can pry up is not nailed down. -- Collis P. Huntingdon, railroad tycoon

Close