Good next-step in growth of understanding
I found this to be a good practical growth step in understanding database design. He explains the basics and steps into good illustrations. The book is not focused on any one db vendor. The second half of the book is a case study.
Very, *very* poorly written book
This book is horribly written. The English here is perhaps the worst in any published work that I have ever seen -- it feels like the effort of a not particulary bright ESL student. No effort at confusing the reader has been spared, and often what should be a simple subject-verb-object statement has been twisted and gnarled and randomly punctuated so its meaning can only be gleaned by context, careful repeated readings, and a few drops of Jolt in the eyes. There are so many errors that should have been caught by the cursoriest of glances that I doubt there was any proofreading done at all. I'd tend to blame more the publisher than the author for this fiasco (Wrox sux?), primarily for exacting a book of someone who shouldnt be writing anything more complicated than his initials.
For Beginners Only
Potential readers should pay attention to the title -- this is definitely a beginner's book. However, it's among one of the better intro texts on databases on the market.
Overall, the guidance provided by this book is sufficient. Experienced readers will find some valuable knowledge, but can probably skip the case study.
The section on normalization, while not 100% accurate, includes meaningful visuals that help explain normalization in an approachable way.
This book, along with the "Mere Mortals" books, is a pretty good introduction to practical database design.
Anyone considering to learn database programming should read this book.
The following is an unaltered email I sent to Gavin Powell. I sent it because before I read his book about a year ago, I programmed only front end code and it has not only helped me understand what I was dealing with when sending / receiving data between client and server, but enabled me to design a smart MySQL database that otherwise would have been over normalized, therefore saving myself hours and hours of writing and testing join queries.
So I wanted to thank him.
I'm posting the email I wrote because I hope someone in a similar position will benefit.
Hi, Gavin.
First, I'm a huge fan. I read the book you wrote for Wrox - '
Beginning Database Design' and use it as a reference - not usually for
technical reference, but more often to remind me why and how...
we should design data models. I'm still a novice in comparison with
real pros, but I have a solid foundation. It's a very important book
to me.
I finally had time to look at your site and was really surprised and
impressed by your dedication to music. I'm a guitar player and have
been for 26 years. It was my primary (also was tending bar) profession for a
few unpleasant years. I can tell you've been playing for a long time
too.
Music led me to become a programmer. Keeping track of albums, their
authors, the songs on them, the other albums on which the songs may or
may not appear depending upon the country in which the album was
released (i.e.The Beatles collection) taught me the need for abstracting elements that change
from sets of elements that don't.
The sad part is that since I began relying on programming for
subsistence, I rarely indulge in writing music anymore ( nearly 3
years). I intend to change that...
So basically, I just wanted to send a fan letter to let you know
you've affected another real person. Thanks for a very well written
book and reassurance/evidence that human minds are NOT either logical
or creative, but both.
Thanks,
Brandon Aikin
Experience
In my experienced, the things that this author repeats over and over again are the most common mistakes in data modeling. I have seen over normalization in over 27 projects in my 15 years of experience. The author is simply trying to make sure that data modelers don't make these same mistakes again. For example, the most common performance problem with most relational databases is over normalization. That means that an application developer may have to do dozens of joins to produce the resulting data. I have seen people use as many as 22 joins, group by, and all kinds of business logic in SQL in order to produce one short sentence of data. That also means that some of the business logic will be shifted to the third or data tier and not kept in the correct tier, middle tier, application tier, etc. This ruins the performance paid for by developing the multi-tier system in the first place.
That is fine if the system will be used by one user, but multiply that by 10 million unique users in 12 hours on an enterprise database, and one has a big problem.
One must always consider the purpose of the model, and how the data will be taken out of the model as well as data integrity, security and normalization.
(15 reviews)
