This really is one of the worst computing books I've ever read: it's very badly structured, poorly written and not too hot on the facts either.



Reading this book is like being sat down with the bumbling office grunt who has just been told to give you an introduction to a piece of unfamiliar software: he sits there pointing at anything and everything he sees, as he sees it, telling you lots of inconsequential detail and saying that he'll tell you more later (or that he's not going to tell you anything at all because it's not a beginner's topic, even though he's just been pointing out all the buttons for it). As a result, you're on page 119 before he gets around to showing you how to define a table, and you have to wait until page 245 before he starts talking about how to insert data into it and perform select queries! If you already know something about databases, this approach is just frustrating and irritating; if you don't (i.e. you're one of the beginners this book is aimed at) it's confusing as well. There's no point being told the function of every button on a toolbar (he takes a hundred words to tell us about the Open, Save and Save As buttons) or every option in an Options dialog, before you've seen basic queries in action (e.g. he tells us that "Pressing this button brings up a dialog box to change the values in each of a template's parameters" well before he shows us queries, let alone code templates!). If you're going to set up a production database, then of course you need to know about security and administration tasks before you do so, but this is supposed to be a book for beginners (and beginner database developers, not administrators, for that matter): it's safe to assume that they'd read through quite a lot of stuff in a more logical order and experiment on a test installation before embarking on proper work!



And here's a sample of his convoluted writing about a pretty simple concept (deciding whether to enforce referential integrity on already existing data when adding a new relationship between tables): "By creating the relationship, you want the data within the relationship to work, therefore you would select No if you were going to go back and fix the data after the additions. What if you still miss rows? Would this be a problem? In preceding our scenario, there should be no transaction records without customer records. But you may still wish to add the relationship to stop further anomalies going forward." Here's some more linguistic spaghetti: "However, when including key column(s) from a clustered index in a nonclustered index, because the row pointer is actually the clustered index key, SQL is smart enough not to store the information twice in the nonclustered index, and you can explicitly define the order of the clustered index keys as they are used in the nonclustered index." If you already understand the concepts he's trying to explain, you can usually make sense of this stuff (unless he contradicts himself in the space of a few sentences, that is), but this is a book supposed to be aimed at beginners and should present the ideas clearly.



If you want to read something like this, i.e. with little or no thought about how to present the most important ideas simply, quickly and clearly without distracting detail, you might as well save your money and read the Microsoft help files (which are more accurate and better written!). If you're going to spend money, look elsewhere.