Short version: this book's information density could be much improved.
Long version: I picked this up because I am building a database app (a little snippet app which the devs on my team could use for status reports), and I needed to learn about SQL Server. I never used it before, so the book looked like a match: I am both a dev, and a database novice.
On the positive side, this book does provide information. On the negative side, the information it provides could be packed in quarter of the space. It is very, very verbose. While reading it, I could not shake off a feeling that the author was trying to fill (contractually?) pre-determined number of pages.
The book is actually very basic: it shows you how to create a database, but does not go into depth on any topic it discusses: best practices, performance considerations, and SQL 2008 specifics are some times mentioned, but never covered.
It does show you how to create a database (using UI and TSQL), add a table, set up basic relationships, back the database up, and add data: the minimum one must know to start using the database, but not enough to make one a database developer.
Lacking the depth (and breadth), the author compensates by sheer verbosity. Every dialog used is presented as a screen shot (no less than 25% of the book consists of these screen shots). Every parameter of a SQL statement is given a description, usually a perfunctory one:
- DESCRIPTION: A description of the backup (p.193)
Sometimes, it gets to ridiculous proportions. On page 191 there is a half-page template for the BACKUP DATABASE statement. In the next paragraph, the same half page of text is repeated again - with one line added to specify a file group parameter.
Here is its description of the SQL backup modes, page 188:
"The first possibility, full backup, is straightforward. Selecting the Full option ensures that the whole database will be backed up. All the tables, the data, and so on are backed up if we use this option. We also back up enough of the transaction log (transactions committed via code, but not physically applied to the relevant tables at the point of backup). This backup would be seen as any starting point for a restore from a database failure.
The second possibility is the differential backup, also known as an incremental backup. Use the Differential backup option when the circumstances are such that a full backupis either not required or not possible. This just performs a backup on data changed since the last backup. For example, we may take a full backup on the weekend and then a differential backup every night. When it comes to restoring, we would restore the weekend full backup, and then add to that the latest differential backup taken from that point. A word of warning here: if you do take a week's worth of differential backup, and you back up to magnetic tape rather than a hard drive, do keep at least enough different tapes for each differential backup. Therefore, use a complete backup when necessary and then in the interim, use a differential backup."
What this says in so many words is: full backup backs up the entire database (duh!), and differential backup backs up the data changed since the full backup. What it does not say is when is differential backup really should be used (other than "when appropriate"), how does the system guarantee the consistency of the data on backup (it does it by using VSS), etc.
How annoying all this really is depends on how the individual reader processes the information. I ended up in a mode where I was quickly scanning through the text in search of information. I lost a bit of time doing this, and I probably glossed over a thing or two that was important, and worth knowing. The book is still probably better than reading the documentation, but if I were buying it again, I would buy something else.
No comments:
Post a Comment