A sound coverage of typical SQL schema mistakes, with a useful exposition of the choices available in implementing inheritance. Less useful to a practitioner than I was hoping because he shies away from taxing the reader too much - thus normal forms are vaguely explained and no precise meaning is ascribed to them. Dinged also for nothing on de normalization and what you need to be careful about when doing tbis, after all de normalization can look like an anti pattern. First, this is based on B6.0 printing, version 2010-4-1.I was hoping to get a little more out of this book. I bought it because I saw the excerpt from the chapter "Naive Trees" and the statement "most developers aren’t SQL experts, and most of the SQL that gets used is inefficient, hard to maintain, and sometimes just plain wrong," on PragProg Bookshelf. Not wanting to create poor SQL, I knew I needed this book.I struggled for a long time with a database that had a large tree structure, so I'm always looking for better ways of dealing with trees in databases. After a lot of work, I finally ended up with what basically equates to the Enumerated Path pattern. I wish I'd had this book a few years ago when I started that project; it would have saved me a *ton* of time.I think the chapters are well written, and seem to cover a lot of issues a developer might encounter in his first few years of development. The author uses good, real world, examples written in clear language.If you're a developer struggling with database problems, I'd say, pick this book up. If you've been developing for upwards of 10 years, you can probably skip it, hopefully, you'll already know most everything he covers.
What do You think about SQL Antipatterns (2010)?
A collection of practically-minded and cogently expressed advice about how not to design databases.
—abby
The book could be 3 times thinner if only "useful" information would be included.
—summerinx
