Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

Head First SQL 210

Anita Kuno writes "On a Sunday, a fellow user-group member suggested I learn SQL. The next day, an opportunity to review Head First SQL arrived in my email. Who was I to question? Prior to opening the couriered package, I had no knowledge of SQL, I knew databases were important, and I had seen the Head First website once or twice. Now, I can design and create databases, use mySQL databases, and understand questions and accompanying code posted to forums. The credit goes to Head First SQL's style, which introduces small bits of information, supported through multiple channels (such as photos with humorous dialogue, stick-men and stick-women, and input from critical personalities whose photos and input pop up throughout the book) regular tests and exercises so the new bit of data can find a home and settle into your memory. The regularly tested pieces of information are now in my brain so I don't have to look up the basic stuff." Read below for the rest of Anita's review.
Head First SQL: A Brain-Friendly Guide
author Lynn Beighley
pages xxxv & 571
publisher O'Reilly Media, Inc.
rating 9
reviewer Anita Kuno
ISBN 0-596-52684-9
summary A beginners foundation for SQL


Head First SQL is about RDBMS (databases) specifically mySQL (version 5.0 or newer) and includes features of other databases. The book defines a database, demonstrates how to navigate an existing database, and teaches how to create simple and complex databases, as well as how to let a database grow from simple to complex.

Foundational understanding of database construction and navigation is the focus. The target audience is those brand-new to the topic as well as those with an acquaintance with the subject and the need for a greater conceptual understanding of databases.

It focuses on the basics of databases, so the main information should remain pertinent until RMDBS get re-conceived. I think revisions, such as the reprint due out in December, will add to the strength of the book as typos and coding errors will be addressed.

The title accurately describes the contents and the subtitle "A Brain-Friendly Guide" describes the goal of the approach. The only requirements for working with the material are: a computer or access to one, the ability to identify your operating system, familiarity with downloading from the internet (links and instructions are provided in the book and the program mySQL community release is free (download instructions are given for Mac and Windows users, I believe that instructions for Linux are not included with the assumption Linux users can access the mySQL community release page and download the program without a play-by-play)), and the courage to learn a command line window user interface if you don't already know this.

Head First SQL is most useful to those who, like myself, have heard passing references to databases and other than knowing they are important have no grasp of what it is, means, or can do. Also, this will be a helpful tool for those who have some of the verbiage, enough to pass at a cocktail party, but who would feel the cold chill of horror if expected to design, construct, and implement a database in conjunction with any of their paid responsibilities.

This is the first book that I have read on the subject of databases and the first computer book that I have been able to finish. So much of the educational information about program x, language y, or application z, depends on a working knowledge of the other two variables. This is a great book for beginners. It talks about data types, it explains null, and then has null explain himself. It tells me the importance of the semicolon at the end. All basic stuff. All stuff that other books take for granted. Many times when I believed I wasn't absorbing anything, along came questions I could answer, a crossword I could complete and match-column-A-with-column-B exercises that demonstrated that I was actually learning much more than than I was giving myself credit for.

It includes illustrations, photos, clean layout, and bite sized pieces of information. All this comes from the goal of allowing both sides of the brain access to the information. It's exactly the kind of approach that I need to reinforce the terms and concepts as well as provide encouraging feedback to keep me progressing through the material. I'm also grateful that it entertains me and keeps me going back to finish the whole thing long after the first blush of excitement has worn away.

Links, to the mySQL program necessary to work with the material, are included in the book as well as a few other links in the appendices. The Head First website is a must in order to link to the forums, newsletter, blog and downloadable files to create various tables used in the book. Head First came out with a web app called Hands On SQL which I would encourage you to try. It won't work with all of the book's material but it is a good-looking tool.

You are welcome to read my submissions on the Head First SQL forum. My user name is anita. Also, the reprint that I mentioned above is due to be in stock as of December 3rd. I'm told by O'Reilly that it includes corrections for errata submitted thus far. Take a look at the Head First SQL homepage to download a sample chapter.

You can purchase Head First SQL from amazon.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.

Head First SQL

Comments Filter:
  • Strange (Score:4, Insightful)

    by a_n_d_e_r_s ( 136412 ) on Wednesday November 21, 2007 @04:25PM (#21439503) Homepage Journal
    why does this reads so much like an add for the book ?
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      why does this reads so much like an add for the book ?

      I don't think I've ever seen a harsh review here on Slashdot. Perhaps the editors are of the opinion that a book need not be mentioned unless the reviewer thinks it's good, and since the has already been established to be good, the reviewer can go all out with hyperbole in praising it. If you want to see more critical opinions on a book reviewed here, check out the Amazon listing [amazon.com], where among the bogus reviews that often appear immediately for tech bo

      • Re: (Score:2, Informative)

        by chromatic ( 9471 )

        I don't think I've ever seen a harsh review here on Slashdot.

        I thought Inside XML needed editing [slashdot.org], and I certainly don't recall giving it a numeric score. Timothy probably added one just before posting it.

    • by spun ( 1352 ) <loverevolutionary&yahoo,com> on Wednesday November 21, 2007 @06:02PM (#21440777) Journal
      Head First! Apply directly to the SQL!

      Head First! Apply directly to the SQL!

      HEAD FIRST! APPLY DIRECTLY TO THE SQL!


      Okay, I didn't say it was a good ad for the book...
    • Comment removed based on user account deletion
      • Re:Strange (Score:4, Informative)

        by mysqlrocks ( 783488 ) on Wednesday November 21, 2007 @06:42PM (#21441287) Homepage Journal

        I'd stick with O'reilly or some publisher that focuses on computers personally.

        The Head First [oreilly.com] series is published by O'Reilly. I think it's a great series of books - even for advanced users.

        • Re:Strange (Score:4, Insightful)

          by CodeBuster ( 516420 ) on Wednesday November 21, 2007 @06:55PM (#21441433)
          You beat me to the post by by a couple of minutes. I agree that even advanced users can get good stuff out of the Head First books, but it is important to remember that the bad jokes, stock characters, and corny vignettes presented in the books are not there as part of some misguided attempt to be cute, but rather as a research proven cognitive aid for helping us, the readers, absorb the most information possible into our brains in the least amount of time with the minimum amount of re-reading, backtracking, and resorts to external commentaries.

          Note for GP: Understand what you are buying when you pick up a Head First book and why or else the wealth of useful information which they contain will be lost upon you simply because you cannot get past a pre-conceived notion about the presentation.
          • Re: (Score:3, Interesting)

            by aztracker1 ( 702135 )
            Personally, I've been recommending the Head First HTML book for those starting out with X/HTML, simply because it is probably the best book for beginners I've seen... Not great for those who are already knowledgeable and able to hand-code HTML though. I have honestly been looking for a similar book to recommend for those looking into Javascript more... I like the JS Bible, but it's a bit cumbersome at this point, and should probably be broken down a little... Most of the O'Reily books are not best for inst
        • Comment removed based on user account deletion
      • Re: (Score:3, Informative)

        by CodeBuster ( 516420 )
        I'd stick with O'reilly or some publisher that focuses on computers personally.

        Actually, Head First Labs, the label under which the Head First series is published, is a subsidiary of O'Reilly Media Inc so the Head First series is published by O'Reilly.
  • who benifits? (Score:4, Insightful)

    by techpawn ( 969834 ) on Wednesday November 21, 2007 @04:34PM (#21439649) Journal
    This sounds like a good intro book but nothing of use to a seasoned DBA. It reads as though you gain basic knowledge of the subject of SQL and some basic mySQL syntax but the day-to-day operations of a database are probably not covered since those are very version specific and generally done with odd T-SQL statements or GUI interface.

    It sounds like a learn SQL in 24 hours book more than a SQL cookbook type resource, may be good for a developer who is starting out in the relational database world but I don't think DBAs will get much. At least, not from what the reviewer says.
    • It sounds like a learn SQL in 24 hours book more than a SQL cookbook type resource

      What would you expect from a book called "Head First SQL"?

      And a minor nitpick: a seasoned DBA should know it is MySQL, not mySQL. That will be all.
      • Re: (Score:2, Insightful)

        by Anonymous Coward
        No, a seasoned DBA should have forgotten as much as possible of MySQL and moved on to Postgresql or some other *R*DBMS.
        • Re: (Score:3, Insightful)

          by moro_666 ( 414422 )
          Proper DBAs will just get a major headache from people who read a book and screw up their db servers thinking that now they have "god mode" on.

          People, unless you have more experience with databases than "my little php page with mysql", don't touch "real" databases. You will go in with a grand idea that was avoided before by real DBAs that knew where locks, indexes, replications, transactions. backups and failovers matter. Newbies come in, create a shiny little script that makes the rest of server c
    • Re: (Score:3, Insightful)

      by YrWrstNtmr ( 564987 )
      This sounds like a good intro book but nothing of use to a seasoned DBA.

      And a book good for a seasoned DBA will be way over the head of a newbie. Not everyone is at the same level. Not every book should be written for 'everyone'.

      Having said that...reading one book in a couple of days does not a SQL developer make.
      • The book [...] teaches how to create simple and complex databases, as well as how to let a database grow from simple to complex.

        Trust me, you don't need to read a book to make that happen ;-)

        But back onto the topic: Of course you're right, no book will suit everyone in the audience. But, does the world really need any more reviews of "Teach yourself <insert a dicipline it'll take you a life-time to master properly> in <insert a ridiculous short amount of time>", reviewed by absolute beg

        • But, does the world really need any more reviews of "Teach yourself in ", reviewed by absolute beginners?

          Reviews written by people that have read the book and are in the target audience seem like the most useful reviews possible.

          Admittedly, it'd be better if we could have the beginner read the beginner-focused book, go on to have a full career in the field, and then write a retrospective review of the influence of the book on their career and beam it back in time, but absent the time machine to make the la

    • Basically, it covers some basics of normalization, but no real background about the concepts or RDBMS's. IMO, one needs to cover, at very least, the fundamental concepts of relational math, and the mathematical definitions of SVD, FD's, MVD's, and the normal forms. Otherwise the book is actually teaching people to use RDBMS's wrong (MySQL is great at doing this too, so it is no surprise).
      • They want to drive the car, not build it.
        • In that case, if you want to drive a database, not build it, leave out the bit about DDL (create table and such). Stick with SELECT, INSERT, UPDATE, and DELETE operations (the DML statements). Include a sample database that people can practice with.

          If you want to cover the DDL, then you are teaching people how to build it and theory is therefore a good thing!
        • They want to drive the car, not build it.


          I think it would be more accurate to say they are teaching how to (among other things) build it, but not how to design it.
    • Re: (Score:2, Informative)

      by dHagger ( 1192545 )

      My experience with the "Head First" series of books (I have read a few, not this one however) is that they are very good beginners books. Easy to read and easy to grasp the basic concepts of the subject they cover. Without loosing interest after a few pages (which in my experience is way too common with other books). And once you know the basics, you can go on and explore more advanced topics somewhere else.

      On the other hand, once you know something about the subject, they are, well... not that good. You

    • This sounds like a good intro book but nothing of use to a seasoned DBA.

      While there's certainly overlap, there is a difference between a DBA (administering the actual database server) and an SQL programmer. This book looks like it's about SQL programming, not database administration.

  • by Vellmont ( 569020 ) on Wednesday November 21, 2007 @04:35PM (#21439659) Homepage

    On a Sunday, a fellow user-group member suggested I learn SQL...

    Now, I can design and create databases


    Database design and creation isn't something you pick up over 3 days. Sure, you can make something that works very quickly, but that doesn't mean it's a good design and isn't flawed. Designing a good database structure takes experience with the tradeoffs between full normalazation and added complexity, forseeing future needs, etc.
    • by techpawn ( 969834 ) on Wednesday November 21, 2007 @04:46PM (#21439789) Journal
      IMHO Creating a database is one thing, Designing is another entirely!

      Making DDL scripts to run in the database is easy once you learn the syntax. Knowing their interaction with each other using Foreign keys, Indexes, and planning their future growth is a completely different set of skills that's only gained with experience with your data.
    • by magarity ( 164372 ) on Wednesday November 21, 2007 @04:53PM (#21439879)
      Database design and creation isn't something you pick up over 3 days
       
      Dude, it's FAR more terrifying than that. From the forums on that site:
       
      anita Joined: 07 Oct 2007
      Posts: 23
      Posted: Sun Nov 04, 2007 1:30 am
      Post subject: CREATE a TABLE with a FOREIGN KEY
      I never noticed until this evening while building a database for a customer to use with her business, but I can't seem to find the place in the book where the code for creating multiple tables from two foreign keys exists
       
      WTF: from 'I don't know anything about databases' to 'building a database for a customer' what amount of time? We don't know when "sunday" was, but even so it seems rather abrupt given that 'anita' has only joined the forum in October and is now designing databases for (presumably) paying customers. This HOWTO book must kick serious ass.
      • by Tim Browse ( 9263 ) on Wednesday November 21, 2007 @05:10PM (#21440103)

        WTF: from 'I don't know anything about databases' to 'building a database for a customer' what amount of time?

        Well, she did say:

        "On a Sunday, a fellow user-group member suggested I learn SQL [...]"

        Maybe it went like this:

        I never noticed until this evening while building a database for a customer to use with her business, but I can't seem to find the place in the book where the code for creating multiple tables from two foreign keys exists

        FFS, learn SQL!

        Just a guess. :-)

      • by magarity ( 164372 ) on Wednesday November 21, 2007 @05:25PM (#21440331)
        Re:Don't get in over your head... (Score:3, Funny)
         
        It's not 'funny' dammit! It's 'customer getting taken for a ride'. The question is generated because she's using a joining table to solve a many to many between her customer and address tables and has named the constraints herself the same on each table instead of letting the system generate them. But WTF?? Address record goes to ONE customer record! If some other customer registers the same address just duplicate the %$#@ing 200 bytes of text but don't m-m it with the customer table!
         
        Frack! Now I'm going to have to follow adventures of Anita The HOWTO Book Data Architect on that forum in the way one can't help but watch a train wreck in progress.
        • I wonder if her name was Anita Bean? Brillant!
        • M-M in customers/addresses can make a lot of sense in many cases. In general, I would M-M them unless I had good reason not to do so. However, I have also seen people do this sort of thing badly and hence one has to understand that this is is something which is more difficult than just duplicating the information (actually I would probably decompose addresses into several other tables-- city, country, etc but that is another matter). Also it usually isn;t as simple as a M-M mapping. Instead you have a c
    • So far, I have almost always found heavily normalized designs are almost always a technical win when looking at future needs etc.

      Note I am talking about normalization as a mathematical process based on data domains, functional dependencies, etc. This means building a database which is mathematically and semantically solid rather than working on program requirements (i.e. the structure of the data in the db should *not* be based on the program's data structures but rather on the inherent internal structure
      • by Ed Avis ( 5917 )
        Agreed, and never mind future needs, just for current ones having a normalized schema is the way to go. There isn't really any tradeoff between normalization and complexity. So far, every schema I've seen that was designed by some cluebie who decided to duplicate data 'to make it run faster' has ended up making code much more complex, because the same data is in several places and you have to remember to update all of them and what do you do if it gets out of sync (as it will)?

        Granted, if you have at leas
        • Also, I am not sure that summary data always means denormalization. Normalization definitions in relational algebra doesn't seem to address questions of values which could be calculated from other values in a set (except where functional dependency is an issue) though obviously good engineering practices would keep these at a minimum.

          For example, suppose we have an accounting application which accepts hundreds of thousands of invoices per year. After 10 years, we want to go find the balance of one busines
    • by tuomoks ( 246421 )
      Very insightful. IMHO this is the problem today, learn a little of one product dialect and you are the master of information management, yeah, great! Vellmont is absolutely right, database design is much more and corporate information management in those databases is even more. Even if a good start can be found in books it needs years, most often very specific industry knowledge and every day learning before you can master it. SQL dialects, structures, tables, even normalization are easy but really the futu
      • The problem is that today's approach of software integration over software development means that you have to know a lot of different technologies to accomplish your goals. If today's "developers" had to understand all the technologies they use to the same depth as you suggest for database design, nothing would ever get finished.
        • by tuomoks ( 246421 )
          Yes, you are right. My gripe is that too often it is the integration without planning / design. It is not the developers / DBAs fault but how the management sees it and buys all the marketing hype "this product solves all your business problems"! Information management, what any database is supposed to be part of, is really not an easy thing but I still think there should be someone in company responsible of that. Nothing new, same with security, performance, development environment, etc. We still too often
    • by sootman ( 158191 )
      Reminds me of the old joke: "Last week I couldn't even spell 'engineer', now I are one."

      Who needs books? You can learn as much as you need to know for basic web apps from Philip G. [greenspun.com] (That's a great online book, and there's another here [greenspun.com].) And he, too, is entertaining. Here's a bit comparing flat files and databases:

      What's wrong with a file system (and also what's right)

      Despite its unobtrusiveness, the file system on a Macintosh, Unix, or Windows machine is capable of storing any data that may be represented i

    • Re: (Score:3, Interesting)

      by Tablizer ( 95088 )
      Database design and creation isn't something you pick up over 3 days. Sure, you can make something that works very quickly, but that doesn't mean it's a good design and isn't flawed. Designing a good database structure takes experience...

      Agreed. Some of my best DB knowledge comes about from observing what didn't work, especially as changes were accumulated over the years.

      Even something as simple as an Address table (or Contact table) can have gajillion different ways to do it, and gajillion different ways
  • Hmmmm... (Score:4, Funny)

    by Anonymous Coward on Wednesday November 21, 2007 @04:35PM (#21439661)
    "This is the first book that I have read on the subject of databases and the first computer book that I have been able to finish."

    Sounds like your aversage Slashdotter, doesn't it?
  • I have a question (Score:5, Interesting)

    by stoolpigeon ( 454276 ) * <bittercode@gmail> on Wednesday November 21, 2007 @04:41PM (#21439731) Homepage Journal
    How does one go about just getting technical books mailed to their home for review?
  • Yeah (Score:5, Funny)

    by geekoid ( 135745 ) <dadinportlandNO@SPAMyahoo.com> on Wednesday November 21, 2007 @04:42PM (#21439743) Homepage Journal
    another person that learned database work from a book. Just what we needed.

    • The RIGHT book('s) would be fine, but they should be preaching normalization right from the get go to make damn sure the reader covers it, and is at least aware that if they don't normalize their data they will absolutely suffer. (yes sometimes you need weigh things up as another poster has mentioned, but that's part of it, and you damn well have to know about it in depth to make those judgements effectively)

      This review doesn't so much as mention normalization once, so the only conclusion can be the book i
      • I'm about to google it, but what's database normalization?
    • by afidel ( 530433 )
      Yeah that was my thought too. Just enough knowledge to be really dangerous. Instead of using the enterprise servers costing tons of $ and maintained by highly paid, very knowledgeable professionals you get someone who's an amature that wastes tons of not quite as valuable time doing it themselves. And in the end the database(s) created by the amatures end up needing to be unraveled by highly paid developers and the same DBA's that should have handled it in the first place at the cost of many times what it w
    • We learn by doing but we can't do unless we understand the syntax.

      Additionally, I would highly recommend Codd's Papers, and CJ Date's books on the subject. These will help to provide a theoretical framework for understanding what an RDBMS is all about.
      • Given that most commercial RDBMS weren't designed to follow the relational model, I don't think it's accurate to say that it provides a framework for understanding what a RDMBS is. It's a bit like saying that you can't perform simple arithmetic without a deep understanding of number theory.
        • Actually, I think that Codd made a few mistakes as well in the relational model. While these seem like minor mistakes and should be put in the perspective of the fact that Codd founded the field (so of course there were going to be some oversights that need to be addressed later), they haunt the industry to this day. Chief among them is the definition of NULL which introduces semantic ambiguity into databases.

          For the most part, SQL is an imperfect approach at writing relational algebra in plain English.
    • by julesh ( 229690 )
      another person that learned database work from a book. Just what we needed.

      I take exception to that. I learned databases from a book, and have never had much trouble because of it. Of course, the book in question was The Relational Model for Data Base Management by E F Codd, but still...
  • by magarity ( 164372 ) on Wednesday November 21, 2007 @04:43PM (#21439767)
    Prior to opening the couriered package, I had no knowledge of SQL ... Now, I can design and create databases
     
    As a database designer/developer who occasionally does DBA duties as well I initially found this quote terrifying in the extreme. But as long as this experimenting about is done on your own PC for at least the next few months, it's great that you're getting a start on a new (to you) class of software tools. Way too many people plough on using spreadsheets where they should be using at least Access. I encourage anyone with accountant or small business owning friends to pass on this review.
    • Re: (Score:3, Funny)

      by LurkerXXX ( 667952 )
      Basically she's just saying she's another regular MySQL user. That's already terrified me for a long time.
    • Re: (Score:2, Insightful)

      by jayp00001 ( 267507 )
      Can we get an AMEN here? How many of us have seen these ridiculously complicated spreadsheets users are sharing across the network that should be some flavor of database instead.
  • by MilSF1 ( 710927 ) on Wednesday November 21, 2007 @04:46PM (#21439791)

    [pedantic mode: on]
    Had a hard time with the blurb for that matter. if you are going to mention the name of a product several times, please learn how it's written!

    MySQL
    Not mySQL. For that matter, not mySQL, MYSQL, MY-SQL, or mSQL (that's another program actually)

    It's all over their website [mysql.com]. Something that simple will help keep you from sounding amateurish as a reviewer.
    [pedantic mode: off]

  • by Foofoobar ( 318279 ) on Wednesday November 21, 2007 @04:53PM (#21439903)
    Databases are a bit more than just queries. I find that most people new to databases start screwing up because thy don't understand that everything can't be stored as a varchar or that it's amazingly stupid to have every column in a table set as a key. Normalization is another big thing to knock into newbie database developer brains as well as naming conventions.

    Personally, I stand by 'Database Systems' by Connolly and Begg. Not simple, not for newbies but it coveres everything you need to know including doing ER diagrams for your structure... something every DB admin needs to do more of.

    • by ErikZ ( 55491 ) *
      I can see how some of those other problems could happen...but not normalizing?

      Normalization is as integral to databases as SQL. If you're not normalizing your databases, you might as well not have them.
      • I couldn't agree more but I have seen it in every shop I have gone to; tables all over the place in second and first normal form. I consider myself lucky if 50% are in 3rd normal form.
  • ...until your carefully crafted union of two huge tables fails, taking down a mysql server common to over 400 sites and incurring the wrath of your previously friendly hosting company.

    Mental note - test locally first.
    • by afidel ( 530433 )
      If you were doing real database work on a well run DB you wouldn't have been able to take the DB down =) Real DB's have resource limiters that allow the DBA to insure that no one user can exhaust resources to the point of taking the DB down. We even limit the percentage of system resources a user can take just to make sure that one bad report doesn't slow down OLTP processing. I'm not the DBA but I know enough to know that there are toys and then there are real business tools.
      • If you were doing real database work on a well run DB you wouldn't have been able to take the DB down =) Real DB's have resource limiters that allow the DBA to insure that no one user can exhaust resources to the point of taking the DB down. We even limit the percentage of system resources a user can take just to make sure that one bad report doesn't slow down OLTP processing. I'm not the DBA but I know enough to know that there are toys and then there are real business tools.

        Indeed. This was a mysql database that I had previously tested long queries on. I was monitoring the progress of the query when the server went unresponsive. All hell broke out from there.

    • You don't do real database work on MySQL.
      You haven't done real database work until you report an original bug in PostgreSQL.
      • BTW, the one original bug I reported in PostgreSQL was back in 7.x, and involved ways of building tables so that they were write-only (i.e. the db server couldn't read them). Had to do with handling tuples as attributes in tables.
  • I wonder if this book covers what's really importent. How to design systems that use databases. I've seen way to many system designs where the DBMS is grossly abused. For example to self-educated programer did not know about "joins" so he searches one table, holds the value in a variable andthen looks it up in a related table. Of corce he also does not think about locks, deadlocaks and transactions. You be surprized to see how common this is. I've seen tables design be people who must have never read
    • Take a look at the SQL-Ledger schema sometimes.

      No normalization (some tables are not 1NF).
      No RI enforcement.
      No NOT NULL enforcement in critical areas (chart_id is NULL. Where did the money go? UNKNOWN!)
      Ambiguous foreign keys (as in a foreign key that references any of a number of possible tables)
      Dangerous abuse of data types (double precision floats for storing money)
      Using custom triggers where ON DELETE/ON UPDATE events and foreign keys would be better
  • I'm reading a lot of negative comments about this book, maybe that's to be expected due to the technical nature of /. readership.

    However, as a DBA and DB dev myself, I know one person that I am personally going to buy this book for, maybe as a Christmas present.

    My boss, of course! I spend hours per week trying to explain to him why I do things certain ways. This is because he has a slight technical background in SAP, and has just enough knowledge to be dangerous. I would love for him to read this book, i

  • Apply directly to the forehead!
  • Yes people will be able to use a database quickly, but do we want them to?

    Most people I have seen using a database have not had any understanding of what they where doing and it was basically and advanced filepointer. I have seen a lot of people using MySQL with MyISAM and happily thinking they got a consistent dataset. I have seen people using databases for communication between servers and using stuff like a time stamp for identifying a row (time stamp generated on local server).

    Leave databases to people
    • Yes people will be able to use a database quickly, but do we want them to?

      Yes. Because you don't get to real understanding until you can start using them.

      The problem, of course, is people developing databases that you have to later work with before they've gotten enough understanding, but that's going to keep happening in any case. In fact, there will be more of it if you narrow the field of people with even a basic understanding of the field. (If its not bad databases, per se, that get built this way, it'l

      • by Splab ( 574204 )
        I don't mind people with less experience working on them, in fact I find it appalling that only people with 100 years of experience should touch it - I do however expect people to have at least a basic understanding what computing is and why ACID is very important.
        • by jc42 ( 318812 )
          ... I find it appalling that only people with 100 years of experience should touch [SQL] ...

          Well, on a number of projects, I've often wished that they'd restricted the DB part to people who had 100 years of experience with it. That would have solved the DB problems we had quite handily.

          I do however expect people to have at least a basic understanding what computing is and why ACID is very important.

          Most of us who survived the 60s understand this. Timothy Leary taught us well.
      • I think that one of the problems is that you can't approach database design like programming in terms of logical structures. This is especially true when trying to do OO programming against RDBMS's. Hence if you don;t teach people theory, they build bad databases because they approach relations like classes (which they clearly are *not*).

        Yes, theory is extremely important. If you don't have good theory both in the DML and DDL side, you are going to run into problems. But these are not extremely difficu
  • empowering (Score:2, Insightful)

    I saw this book a Borders and have recommended it to the Network Support Technicians at my company. These guys run our helpdesk and often refer basic questions about network performance to me. I've created a bunch of systems that store data for reports in mysql (current status, roundtrip response time, throughput, usage etc.). People are often amazed that I'm able to produce ad-hoc charts and tables about all sorts of aspects of the network's well-being. All I'm doing is simple queries on simple data and if
  • ...are generally aimed at those new to { insert book's technology topic } and not seasoned programmers / developers / architects.

    Many of the comments so far are negative, doubting how someone can become a data architect / DBA from the book... which is not the target audience... IMHO

    As one who has seen quite a few programmers use unstructured text files, excel spreadsheets and access (as if it were a spreadsheet) for data storage, I welcome a resource that offers a painless introduction to the "magic" of

  • by GreggBert ( 89663 ) on Thursday November 22, 2007 @11:08AM (#21446047) Homepage Journal
    It would be helpful to include your own background when doing a review. While I know not everyone works with SQL every day, it might help to put the review into context if we knew what level of technical or development experience the reviewer had. It would make it easier to possibly recommend the book to others if we knew what background the reviewer had in relation to those we might possibly recommend the book to.

"If it ain't broke, don't fix it." - Bert Lantz

Working...