Hi ,

On Page 106 we learned that ... calories between 30 and 60 will return drinks with 30 and 60.
On Page 108 we learned that ... drink_name between 'G' and 'O' will not return drinks with 'O'

Shouldn't drinks with 'O' have been included just like calories with 60 are included. Not sure I understand.

cheers
David

The example on page 129 (for the delete statement) shows the rows in a table for 'Zippo' the clown. According to the first paragraph we are trying to get rid of duplicate records. The exercise on the page is 'Delete Statement Magnets'. The solution shown on the next page (130) shows a delete statement to {DELETE FROM clown_info WHERE activities = 'dancing';} To my mind, this would delete the one non-duplicated row from the table on page 129. However, the table on page 131 shows an entirely different set of records in the table. Admittedly, it does highlight the one row which is actually deleted if the statement (for the solution on 130) is used on the table shown on that page. However, the whole solution has pretty much nothing to do with duplicate records or the example table on page 129.

I reread the 3 pages several times before I realized that perhaps I did not read the instructions for the exercise on pg 129 closely enough; it stated 'a simple command that we could use to get rid of 'ONE' of the Zippo records'. I had assumed the exercise followed from the table above it, especially since the paragraphs at the top of pg 129 stated 'we should only have one row per clown' and we should 'get rid of some of the old Zippo records'. Just above the exercise it even shows the 'rows for Zippo' again', with many duplicated records. I thought the exercise was in reference to that table.

I did understand the 'delete' statement - page 131 alone showed that. I guess it was pages 129 and 130 that threw me off. My understanding of the exercise and the solution on page 130 were so different and the results on page 131 so unexpected, things didn't 'compute' at first. My confusion could certainly have been due to the way my mind works, but things would have actually been clearer if pages 129 and 130 had not been there at all.

I'm sorry this is so long, it is hard to convey confusion!

Page 304 has the following statement:

"Foreign keys don’t have to be unique—in
fact, they often aren’t."

So I don't see how the following comment on page 309 logically follows:

"These tables also have a one-to-one relationship, since
the primary key of the employee table, employee_id, is
being used as the foreign key of the salary table."

[Nit: since --> because, above]

In fact, the interests table, which is the subject of the previous pages, has the same setup but is a one-to-many (i.e. many contact_id's in the interest table that map into one contact_id in the my_contacts table).

The exercise asks us what the database relationship is between a book and a publisher (ie is it One to Many, or Many to Many).

The answer given is One to Many, on the assumption that modern books only have one publisher. Usually, this is right.

But what about books like the Bible, or Dickens, or Shakespeare? Some books with lapsed copyrights are published by multiple publishers. Perhaps you could add a pencilled note to the answer mentioning this to avoid confusion.

Thanks. Head First SQL is awesome. Lynn Beighley is my hero :)

It would be great if the answers provided some context as well. For example, when I saw the doughnut_rating table (taken in isolation) it appeared to be a one-to-one relationship. I was assuming the following layout:

doughnut_type|rating
-------------+---------
glazed |excellent
boston_cream |good
...

where doughnut_type is a unique, primary key. I'm not sure what the authors were thinking in terms of how this information gets used by other tables. I have the same comment for the other examples too.

[Flipping back through the book (e.g. page 78) shows that doughnut_type is not a primary key, so again, not sure what the author intended, here.]

The book is explaining what functional dependency is. On page 323, functional dependency is defined as "When a column's data must change when another column's data is modified, the first column is functionally dependent on the second".

One example given is that a superhero's initials are dependent on their name. (I agree. If you change your name, you can't help but change your initials)

But other examples given are that the superhero's powers, weakness, and arch-enemy are also dependent on the name. This seems to imply that if superhero changes her name, she'd have to change power, weakness, and arch-enemy, just like she'd have to change initials.

I don't understand why that is true. Couldn't a superhero get a new arch-enemy? And if the superhero changed her name, couldn't her arch-enemy remain the same? And if so, then in what way is arch-enemy functionally dependent on superhero name?

I may have missed something. If there's a simple answer, could you include a "There Are No Dumb Questions" section in the next edition?

The 2NF definition uses "partial functional depencies" (PFD), but there's no definition for PFD on this page. Probably should add one to this page.

I believe using DISTINCT versus GROUP BY would make the examples clearer. For example:

SELECT status FROM my_contacts GROUP BY status ORDER BY status

versus

SELECT DISTINCT status FROM my_contacts ORDER BY status

An alternative solution to:

SELECT p.profession FROM my_contacts mc
INNER JOIN profession p ON mc.prof_id = p.prof _ id GROUP BY profession ORDER BY profession;

is

SELECT DISTINCT p.profession
FROM my_contacts
NATURAL JOIN profession p

which seems to me to be more explicit and more concise.

Why isn't job_listings.zip linked (i.e. foreign key) to zip_code.zip_code?

"... But first, he wants to pull out all the
Web Developers with ..."

This statement implies to me that the query should look for people who are currently web developers versus people aspiring to be web developers (which is what the provided solution looks for). Also, the provided solution doesn't check for years of experience, so the requirement needs to be dropped from this page or fixed in the query.

The two graphic, query examples seem identical and have similar annotations, so I don't see what purpose they server. What am I missing, here?