Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


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

SQL: Visual QuickStart Guide 198

Posted by timothy from the bingo dept.
objectboy writes with a review of Chris Fehily's SQL: Visual QuickStart Guide, writing "This book teaches ANSI SQL-92 programming to database beginners and intermediates. The publisher, Peachpit Press, publishes mostly end-user and novice titles that usually go unnoticed by professional programmers. Its Perl and PHP books, for example, are of little practical or tutorial use to an experienced developer. In fact, I noticed this SQL book only because a junior developer was using it for a course. The book's table of contents, index, and a sample chapter are posted on Amazon.com. The book's official web site contains errata and other information." Objectboy's review continues below.
SQL: Visual QuickStart Guide
author Chris Fehily
pages 424
publisher Peachpit Press
rating 9/10
reviewer objectboy
ISBN 0321118030
summary A lucid SQL tutorial and professional reference

What this book does right:

The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true: A lucid explanation of a difficult concept or clever algorithm is more valuable than a bug-free implementation of same.

Consider Ken Henderson's The Guru's Guide to Transact-SQL , a book full of useful examples but so marred by the author's bloated style and disrespect for the language that I cringe every time I'm forced to read the text rather than simply lift a code snippet. Henderson even goes so far as to include an introductory section, titled "On Formality," about how he is going to split infinitives (even though their syntax is a burden for the brain to parse) and how he is going to use "data" in the singular sense (even though doing so can cause confusion) and how he considers "record," "row", and "tuple" to be interchangeable terms (even though they're not) and on and on. Readers would be aghast to find such self-exculpatory nonsense in the pages of Donald Knuth or Patrick Henry Winston. As for SQL: Visual QuickStart Guide, the author, a statistical programmer, presents each topic with a mathematician's sense of restraint and order. I've found few typos, no technical errors, and consistent use of technical terms.

Almost every aspect of SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP is covered. What distinguishes this book is that every ANSI SQL statement -- and there are hundreds of examples -- was tested on six separate DBMSes: Microsoft Access 2002, Microsoft SQL Server 2000, MySQL 4.0, PostgreSQL 7.1, Oracle 8i, and Oracle 9i (8i and 9i differ considerably in SQL-92 compliance). The examples in each section increase in depth and complexity, so you can stop reading once you've learned what you need to know. When an ANSI SQL statement doesn't work as-is on a particular DBMS, the author shows you how to fix it or offers workarounds (which is particularly useful for MySQL, whose adherence to the SQL standard is poor). These DBMS-specific fixes are given as separate "DBMS Tips" apart from the main body of text, so they don't interfere with the conceptual flow. This organization is especially useful for consultants who have difficulty keeping track of how each implementation deviates from the ANSI standard, and is superior to the alphabetical, segregated approach of O'Reilly's SQL in a Nutshell.

This book was shoehorned into the publisher's Visual QuickStart format, which, as I implied earlier, doesn't work well for procedural languages, but does work for a declarative language like SQL. A two-column layout separates examples from explanatory text. Red type highlights the relevant portions of code and results. The book is extensively cross-referenced and has an 18-page index. This layout also makes the book a good quick reference for experienced programmers. Almost all the examples use a single, sample database (so there's no need to memorize multiple schemas). The code listings and sample database are available for download.

The derivative nature of programming books makes it difficult to determine whether the author truly has mastered the material. Writing a book is a difficult task (perhaps even harder than programming) but, at the risk of exaggerating my point, I suspect that any determined, organized, and competent programmer could write any O'Reilly Nutshell book by paraphrasing existing materials. But if an author establishes his credentials early, the reader gains a sense of trust that remains throughout the entire book. In the introduction to this book, the author avoids an error that almost every other SQL-book author commits: that SQL stands for structured query language. According to ANSI (the only legitimate arbiter here), it stands for S-Q-L and nothing more. Fehily even offers an amusing explanation of why structured query language is the worst possible description of SQL. Throughout the book, the author also scatters bits of practical advice (job candidates are wise to say my-es-kyu-el, not my-sequel), beginner-friendly insights ("Although SELECT is powerful, it's not dangerous: You can't use it add, change, or delete data or database objects."), and advanced topics (optimization, concurrency control, logical data independence). It is these asides and respect for basic research, rather than swaths of expository text, that lend authority.

This book describes the effects of nulls in almost every aspect of SQL, including the interpretation of null-contaminated query results. You can no more be a competent SQL programmer without understanding nulls than you can be a competent LISP programmer without understanding recursion. Particularly useful are the discussion of three-value logic (true/false/unknown) and an algebraic derivation of how a null can cause a subquery to return an empty result unexpectedly (which has bitten me more than once).

As a wizened developer weary of hand-holding users and junior programmers through routine queries, I've found it mollifying to give away copies of this book (it's cheap) to reduce my interrupt stack.

What's Missing:

Some missing items that I would have found useful:

  • A glossary
  • A quick syntax reference
  • A chapter about statistics
  • A chapter about advanced SQL "tricks"
  • DB2 coverage
  • Coverage of security commands (GRANT/REVOKE)
  • An expanded query-optimization discussion
  • Improved normalization examples
  • A little more mathematical rigor in the set-theory discussion
You can purchase SQL: Visual QuickStart Guide 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: Visual QuickStart Guide More

SQL: Visual QuickStart Guide

Comments Filter:

  • Excuse me? (Score:1, Insightful)

    by Anonymous Coward
    "The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true"

    So, you're saying... who cares if the code is wrong as long as you think you understand it? Personally, I'd rather have the right code.

    • Re:Excuse me? (Score:4, Insightful)

      by ajs ( 35943 ) <ajs&ajs,com> on Thursday July 31, 2003 @12:41PM (#6581658) Homepage Journal
      I would agree with the text that you cited, right up until he talks about the opposite.

      The two are equally important, and both are critical to a good technical book. You cannot have a good tecnical book that is poorly written. You simply cannot.

      I remember the original X reference set from O'Reilly, and the whole reason that they were a success was that they were essentially duplicates of the online X documentation, which was some of the best written toolkit documentation, ever.

      Had those been just as technically accurate, but even just a little harder to navigate and use, they would have been nearly useless, given the complexity of the topic.
    • You're better off buying a book targeted toward the platform you will be using. TransactSQL and PL/SQL have very different implementations of the same "standard". If you're using MySql or postgres just get some of their excellent manuals.

      I prefer PL/SQL but my job uses T-SQL :( I guess that's why I get paid, doing what the bosses want.
      • TransactSQL and PL/SQL have very different implementations of the same "standard".

        Is there actually a standard for stored procs? I'd always assumed that Oracle had invented PL/SQL, then Sybase copied it into their own version. Sybase was then gutted by MickeySoft and made into SQL sorta follow standards but have a really nice gui Server.
        • TransactSQL is the Sybase/MS implementation of SQL
          PL/SQL is the Oracle implementation of SQL

          Stored procedures are independent of the language implentation, they just execute the SQL.

          I like PL/SQL the best because I worked with Oracle extensively as my first Enterprise level database. Going from their implementation to the MS implementation was frustrating (for about a week, then it all sunk in, hell I'd probably be just as irritated if I had to go back to PL/SQL ;)
          • TransactSQL is the Sybase/MS implementation of SQL
            PL/SQL is the Oracle implementation of SQL

            I realize that. What they did tho is extend SQL to make stored procedures possible. The standard (SQL) offers nothing like the concept of variables and begin/end blocks. At least, not in the versions I've read. It's possible that it was added beyond SQL-99.

            For what it's worth, I much prefer Oracle myself. At least sequences make sense and are easy to use. Try getting back the proper @@IDENTITY from Sybase/MSSQL a

            • Re:Huh? (Score:2)

              by mal3 ( 59208 )
              SCOPE_IDENTITY() gets you the right identity every time. It's only in SQL Server 2000 though.

              Mal
          • Uhhh, I'd call PL/SQL the Procedural Language extensions for SQL, which implies quite a bit more than implementation, or perhaps I'm having a pedantic moment.
            I think your remark on frustrations is on the money. 80% of all programming languages are the same, the remainder being genuine feature differences and syntactic nuances.
            Never did a whole lot in PL/SQL, though. The one or two non-trivial modules I did write seemed so close to the underlying C code (I'm pretty sure that's the source language) that y
      • TransactSQL and PL/SQL have very different implementations of the same "standard"

        Wrong. Neither TransactSQL nor PL/SQL are implementations of SQL. Sybase and Oracle both implement SQL in fairly close compliance with the standard. In addition to providing SQL, they provide the procedural languages TransactSQL and PL/SQL, respectively.

        Of course if you just want to be a "Sybase programmer" instead of a developer who understands databases, then go ahead and just study "the platform you will be using".

    • Re:Excuse me? (Score:2, Insightful)

      by mrmez ( 585359 )
      Yes, it's more important to understand the language than to have good, solid code examples which I can't actually use because either they don't do what I need to do or I just can't understand them well enough to implement them where I need them. It's also more important to be able to write the best code for the job than to be able to grab some inefficient code which allows me to work around its inadequacies for my specific usage so that I can just about do what needs to be done. I choose comprehension over
  • book that I won't be purchasing; I already have 5 or so $50 books that are currently serving as expensive doorstops. Anything you can get out of these books can easily be grokked or googled for through the web. -

  • Mandatory Bookpool link (Score:5, Informative)

    by vasqzr ( 619165 ) <.vasqzr. .at. .netscape.net.> on Thursday July 31, 2003 @12:36PM (#6581606)

    Bookpool [bookpool.com] has it for $14.50

  • I like to keep beginner books around for reference. I think I'll keep my C J Date book on SQL. It has yet to let me down.
  • ...make sure you pick up a cross-platform [datadino.com] tool for working with SQL. SQL Server is particularily hard to use in a cross-platform way, but thanks to the jTDS [sf.net] and FreeTDS [freetds.org] projects, we now have drivers.

    Linux and Mac OS X users, unite! Or untie. Or something...

  • Peachpit press is kinda useful. (Score:5, Interesting)

    by crazyphilman ( 609923 ) on Thursday July 31, 2003 @12:40PM (#6581646) Journal
    I liked their javascript and XML quickstart guides; they're basically ways of getting up to speed on something really quickly, and for relatively simple subjects (like Javascript, html, and xml) they might be all you need outside of web searches. The xml book had some really nice info about stylesheets and XSLT, for instance, and I use the stylesheet reference even when I'm just doing some HTML.

    The books are cheap (twenty or thirty bucks) and small (easy to carry in a backpack). I think they're a really good value. Although, I wouldn't buy one for a more in-depth programming language, for the simpler stuff (html, xml) they're great.

    • I don't have any Peachpit books, but if you like small form factor, backpack-sized references try the Codenotes series [codenotes.com] of books. They're really small (roughly 5x8 inches), and get right to the point. They're very good references when you can't get to online sources. You need to have some passing familiarity with the material, however.

      I have the XML [amazon.com] and the Web-Based UI [amazon.com] ones. They're both very handy to have around, and easier to carry than toting O'Reilly books everywhere. They also cover more ground

  • What is the index like? (Score:4, Funny)

    by danormsby ( 529805 ) on Thursday July 31, 2003 @12:40PM (#6581649) Homepage
    If an SQL book isn't easy to search I'm not buying it.

  • I understand the convenience but... (Score:4, Insightful)

    by dhodell ( 689263 ) on Thursday July 31, 2003 @12:40PM (#6581650) Homepage
    ... doesn't it end up being easier reading the documentation for the SQL products themselves? SQL is one of the few languages I would argue actually does *not* need a book. Reading a PHP/Perl book about any RDBMS using SQL would enlighten one as to the basic functionality; all further research could be done on the site of the RDBMS of choice. Yes, this would imply that they end up learning implementation specific SQL, but as long as one sticks to the "basic guidelines" found in the aforementioned books, one should be able to write fairly portable SQL, and fairly quickly.
    • If you're a programmer, how much SQL do you need, anyway? You have to know inserts, selects, updates, deletes, and transactions, right? Maybe subqueries, but that's more of an art than anything else...

      Stored procedures used to be challenging, but (at least where I work) the DBAs are leaning towards cutting those out because they don't want to do the maintenance.

      Aside from a pocket-book (it's a novel-sized SQL 92 reference), I don't keep too much SQL documentation around. Most of it is in my head, these da
      • > If you're a programmer, how much SQL do you need, anyway?

        Enough to condense half of a corporate database down to one screenfull of information using only *one* select statement. That means case/switch statements, subslects, inner joins, outer joins, UNIONs, etc. Or maybe I'm too lazy to make more than one call to the database. ;-)

      • DBAs? (Score:4, Insightful)

        by MemeRot ( 80975 ) on Thursday July 31, 2003 @01:40PM (#6582088) Homepage Journal
        Uh.... where did you get your DBAs? Do they understand that stored procedures offer performance benefits by reusing a stored execution plan? That stored procedures encourage code reuse just like function libraries in the procedural language of your choice? That by isolating a block of code away from being embedded in code it's much easier to put in the finnicky lock control statements that you generally don't want mucked about with by junior programmers? That by moving back to embedded SQL you are probably giving up control of locking mechanisms whatsoever? That you are quite likely moving sorting/selecting logic out to your embedding code, and away from the database engine that is much more optimized for these operations, offering advanced tools like cursors and temp tables?

        If you're a programmer, you need to know how to specify what you want to feed into a stored procedure, and what you want to get out of it. If you can't write the proc yourself, you need to get someone to write it for you. Embedded SQL is a bad idea. You tie yourself to one table structure because you can't possibly change all the embedded code snippets. You miss out on debugging opportunities because you won't use PRINT statements in your sql. Etcetera, etcetera, etcetera. I don't want to do maintenance on my code either, but it IS my job after all.
        • Stored Procedures are overrated. They do offer some benefits in performance, but people have a nasty way of using them for anything and everything, thus making a general mess out of the database. Not to mention that embedded SQL is far easier to make dynamic than Procs. Remember, Web Apps are the name of the game these days. Most of them hardly require the level sophistication you're referring to. :-)

          Embedded SQL is a bad idea. You tie yourself to one table structure because you can't possibly change all
          • No offence but that's heresy where I come from. Everything must be an SP here. Would you want to recompile every line of app code before you execute it(java devs don't answer that). It's the same way with stored procedures.

            On top of that having stored procedures out where a good DBA can get at them in a moments notice so they can search them for dependencies, see their table usage, and analyze indexes without having to sort through a bunch of application code written in a language they may not understan

            • Re:DBAs? (Score:4, Informative)

              by AKAImBatman ( 238306 ) <`akaimbatman' `at' `gmail.com'> on Thursday July 31, 2003 @04:18PM (#6583145) Homepage Journal
              No offence but that's heresy where I come from.

              It's heresy where I'm working at right now. But that's only because the people who originally wrote the web-app f***ed things up by using ColdFusion for a complex business. CF offers you no good option for separating code, data, and SQL other than stored procs. Java on the other hand...

              Would you want to recompile every line of app code before you execute it

              SQL is not code. It does not compile down to any form of CPU instructions. It is a data structure designed to look like english. All "compiling" procedures does is pre-parse the query and do some statistical analysis that would otherwise be done at runtime. This is great for really complex queries. However, 90% of the queries in most systems are not seriously affected by "compiling".

              On top of that having stored procedures out where a good DBA can get at them in a moments notice so they can search them for dependencies, see their table usage, and analyze indexes without having to sort through a bunch of application code written in a language they may not understand.

              Having worked in an environment where we managed excellent performance without resorting to procedures, I can happily say that it comes down to your communication between your teams. If there is a rift between your DB people and your coders, you're going to have problems. Also, it helps a lot to get the database done right the first time. It really isn't too hard, but some DBAs seem insistent on denormalizing this for performance or doing this fun new winding data structure, or other weird crap instead of just *doing* it. Get the database done right and in production and worry about performance characteristics later. 99% of the time, you don't need to do anything about them anyway! (Beyond tweaking a few indexes that is.)

              • SQL is not code. It does not compile down to any form of CPU instructions. It is a data structure designed to look like english. All "compiling" procedures does is pre-parse the query and do some statistical analysis that would otherwise be done at runtime. This is great for really complex queries. However, 90% of the queries in most systems are not seriously affected by "compiling".

                Agreed on the compiling semantics. I use the term compile since that's the term my RDBMS uses even though it's not a true c

                • Re:DBAs? (Score:3, Interesting)

                  by AKAImBatman ( 238306 )
                  The difference may not be much but what you save in network bandwidth, and optimizer time adds up. Besides it's not like it's hard to write a simple stored proc in *any* SQL language.

                  But a list of procs is way more difficult to manage than a Java API (for example). Procs have no concept of package structure and as a result, they all end up in one big jumble with 3 or 4 different styles of naming (to get around the problem) competing for your visual attention. Bandwidth internal to a network is nothing whe
                  • But a list of procs is way more difficult to manage than a Java API (for example). Procs have no concept of package structure and as a result, they all end up in one big jumble with 3 or 4 different styles of naming (to get around the problem) competing for your visual attention.

                    Just like anything else there is a right and a wrong way to do anything. If you have poor naming standards and don't organize your stored procs they'll be a hassle. If you don't structure your Java API's correctly you won't be a
          • And firmly believe the data layer needs to be at least two separate layers itself.

            I know web apps are the name of the game. At the e-commerce dot com I used to work at we used all embedded SQL and it was a huge mess as processes locked with each other when the engine had too many simultaneous requests and none of the direct sql that was used bothered to specify WITH (NOLOCK) on the 98% of the code that was just doing reads. Maintenance went way down when we moved to stored procedures that had locking spe
        • I know what you're saying... Most of us programmers said the same things. Ah, well, what can you do? Go along to get along, etc.

        • Stored procedures break the three layer approach that many people is the most mature way to do application development. You have the presentation layer (the client facing app or web servers), the logic layer (middleware servers with the business logic), and the data layer (the SQL servers). This layout makes things easier to maintain and more independant. They may not perform optimally but they scale like nobodies business and given decent developers will perform pretty close to the optimized case.
          • But the 'business logic' (depends on your definition of business logic, really) is intrinsically tied to the data. Without it, your data is meaningless.

            That's the (well a major) whole point of a relational database management system. Your RDBMS is a series of axioms -- namely constraints -- a la business rules.

            The problem with traditional three-tiered architectures is that they are a throwback to 'roll-your-own' DBMSs that plagued the industry in the 50s, 60s, and 70s. At least many of the 'business ru
            • I find 'middle layer' getting very small in my apps now. The point of the middle layer is to allow for easy business rule changes but... I didn't want to hardcode in tax rates, so I move them to the database. I didn't want to hardcode in discount rates, coupons, promotion codes, etc. so I move all that to the database. Pretty soon my middle layer looks pretty skinny.
          • Each layer can be subdivided. I divide the database layer into 3 layers itself: tables, CRUD, complicated procs. It's all about code re-use and maintenance. You write the dumb CRUD procs to handle your basic inserts, updates, etc. You call them from the more complicated procs. The role of the complicated procs is to accept a big chunk of data and format it for the tables. Lets say your middle tier has a nice xml document representing the contents of a shopping cart. Fine, the business logic is done.

    • Why not to use the vendor-specific documentation (Score:4, Insightful)

      by brlewis ( 214632 ) on Thursday July 31, 2003 @01:08PM (#6581884) Homepage
      If you read Oracle's docs, they'll tell you to use NVL(). If you read MSFT's docs, they'll tell you to use ISNULL(). Both databases support the standard SQL function COALESCE() that does the same thing and is portable. There are other similar examples. Only use the docs that came with your database if your database is PostgreSQL. Except for backslashes within string literals, they pretty much respect the standard.
      • Because it's clear what isnull does just from looking at it. Coalesce isn't. I've never ported systems from one database engine to another, only to other versions (not counting upsizing access). So I don't see how portable could actually offers a benefit for databases. People are too damned scared to move them even when they should.
        • The other nice thing about coalesce() is that it takes an arbitrary number of arguments, and returns the first non-null, so you can do coalesce(a, b, c, d) rather than isnull(a, isnull(b, isnull(c, d))).
    • SQL is one of the few languages I would argue actually does *not* need a book.

      I agree at bottom with this statement. As a declarative, rather than procedural, language, for the basics SQL does not REALLY need a book.

      However, just as in Perl, TMTOWTDI. And often several of those ways, depending on the RDBMS you are using, and, usually more importantly, on the data themselves, are FAR, FAR worse than many of the other ways. That's why you need a good book, both on the principles of SQL (I highly recomme
    • I needed books. At university, I found relational algebra easier than SQL - it was taught as a formal introduction to SQL in DBMS course I took. However, I never really grasped SQL until later on when I had to work with it. The online documentation serves me as a reference now, but it took books with lots of esoteric examples (thanks Joe Celko) to help me get over the initial hump, and develop deeper insight. It's not just me - I've noticed other people who just can't get their brain working/thinking in

    • Re:I understand the convenience but... (Score:4, Funny)

      by metamatic ( 202216 ) on Thursday July 31, 2003 @02:02PM (#6582247) Homepage Journal

      ...doesn't it end up being easier reading the documentation for the SQL products themselves?

      I have a set of DB2 manuals on my shelf, and can therefore answer your question with a confident "No".

  • SQLCourse (Score:5, Informative)

    by Jucius Maximus ( 229128 ) on Thursday July 31, 2003 @12:40PM (#6581652) Journal
    If you just need an intro level starter to SQL and you've never even written a query before, you can't do much better than the free tutorials at SQLCourse.com [sqlcourse.com]. As long as you're generally adept at using computers and it doesn't scare you to learn a new language, it will definitely give you a good start.

    This is how I first cut my teeth in SQL, but I only developed 'real' skills when I started writing SAS code on a huge solaris system when I worked for a bank.

    • Re:SQLCourse (Score:3, Informative)

      by ryantate ( 97606 )
      I found SQLZoo.net [sqlzoo.net] an extremeley useful tutorial. One of the cool things is you can pick the SQL engine used for the exercises, including MySQL, Postgres, Oracle and SQLServer.

      Before going hands-on, Philip Greenspun's SQL for Web Nerds [greenspun.com] offers a relatively speedy but deep overview.

  • mhm (Score:2, Informative)

    by edmz ( 118519 )

    Barnes and Noble has it for $21.99 while Amazon has it [amazon.com] for $15.39 (unless they have some kind of dinamic pricing and not everybody sees the same price).

    Plus, there is also MySQL: Visual QuickStart Guide [amazon.com].

  • Good jumping off point... (Score:3, Insightful)

    by djrisk ( 689742 ) on Thursday July 31, 2003 @01:21PM (#6581967)
    I think that this book sounds like a good jumping-off and/or refresher product. Like any language, it's always good to have a couple of good references (both printed and on-line) available to you.

    For beginners, this sounds like a good book to learn the basics of querying and allow them to begin honing their skills.

    For professional (and soon-to-be professional) developers, learning STRONG SQL is a good idea. Many developers (esp. casual web devs) never take the time to get a good grasp on the language and write queries with a balance of effectiveness and efficiency.

    Another good book to keep in mind (if you're serious about development) is "Database Design for Mere Mortals" by Hernandez and Getz. I'm sure it's been mentioned a few times here already.

  • SQL In A Nutshell (Score:2, Informative)

    by rakanishu ( 670638 )
    O'reilly's SQL In A Nutshell is pretty good. It covers standard SQL and the differences between each database(Oracle, MySQL, Postgre SQL, MS SQL).
  • Is doing queries like:

    SELECT -1 as Sort_key, count( ID ), ''
    FROM tbl_some_table
    UNION ALL
    SELECT 0, ID, Name
    FROM tbl_some_table

    Your guaranteed to get something, if only a zero in the first row.
    You make one trip to the database, a cheap, yet noticable performance boost.
    You know exactly how many rows are in the result.
    You aren't too platform-specific.
    You can chain a truckload of these (keeping a weather eye on the Sort_key values).
    Are there any arguments against this strategy, beyond the usual "tha
    • What is the benefit to this? I don't get it. Well, I do, but I don't see how it is that entirely too useful.

      All it tells you is how many rows are in the particular table. The number of rows in the result is, of course, count( * ) + 1 since you have to account for the aggregate.

      I assume you're doing something like (some weird pseudocode):
      select * from table

      put first row into rowcount

      for( i = 1 to rowcount )
      output 'row ' + i + ' of ' + rowcount

      To the other guy who said it doubles query time that is
  • I've had the (mis)fortune of having to teach courses in Unix using the Visual Quickstart Guides. (I've also checked out several of the other books in the series.) The problem with these books is that they teach by example with very little theoretical background. There's nothing wrong with teaching by example, but if it isn't set in a strong foundation, you end up with students that might have breadth of understanding, but no depth. The books themselves become useless at this point, as the examples are of
    • You, as the instructor, could have filled in those gaps. It would be better if you didn't depend solely on the Visual Quickstart Guides. If that's all you had to work with in the course, you could have fleshed out the course more with your own instructional material and knowledge.

      I teach Microsoft developer courses (MOCs). The materials are often plagued with similar issues that you find with "teach by example" systems. That's where I fill in the gaps using the whiteboard, demonstrations, online references
    • Who cares, this isn't a $200 Calc text, it's ~$15 at most of the major online retailers. It's kind of like cliff's notes or dummies books, enough to get you started but not something you learn everything you need from.

  • SQL:1999 (Score:2, Interesting)

    by tarvin ( 644214 )

    SQL:1999 has been defined for years and some of the DBMSs have actually implemented some of its features. Yes, SQL:1999 is big and perhaps bloated in comparison with SQL-92, but it's not that bad if you concentrate on the core parts. Some of the news in SQL:1999 are actually clarifications on stuff in SQL-92.

    SQL:2003 will probably be agreed on this year.

    - So I find it strange to use the more than a decade old SQL-92 as the platform for a book published in the year 2002.

    Another thing: I'd say it's "ISO

Slashdot Top Deals

Any programming language is at its best before it is implemented and used.

Close