Slashdot Mirror

Fabian Pascal has written this work on issues that come up in database administration and recommendations for solving them. It's not really a practical guide, despite the title, but probably many administrators would benefit from reading the book and keeping it handy somewhere. Yes, I mean you, the one who's got a copy of Filemaker Pro at home and thinks he knows it all.

Practical Issues in Database Management author Fabian Pascal pages 256 publisher Addison-Wesley rating 7.5 reviewer Michael Sims ISBN 0-201-48555-9 summary Not a practical, hands-on book at all; contains high-level database problems and theoretical solutions

Most of the time, when a computer book has the word "practical" in the title, it means one thing: examples. Lots and lots of real-world, cut-and-paste examples intended to solve the exact problem you're facing. This book departs from that stereotype by containing little in the way of practical examples. I don't think it even mentions any specific database products. Instead, it mainly discusses the platonic ideal of a database from a scholarly standpoint, and never touches actual examples of database products. As such, it is a relatively timeless book, but it is not what I would describe as "practical".

Essentially, it is a scholarly overview of the whole concept of databases, some common pitfalls that database administrators (DBA's) run into, and where actual database systems fall short of the platonic ideal. It would be a good book for an "Intro to Databases" class (and I don't mean a How to Use Excel course, I mean a CompSci course).

Let's skim through the chapters. I'll try to make this review accessible to all readers, even those who don't know much about databases.

Chapter 1 discusses datatypes (how data is stored in the database), and suggests that DBA's should not fall into the trap of using complex, proprietary datatypes over standard character and numeric fields. Chapter 1 also includes the oddest section of the book: 20 pages of Webpage print-outs whose sole unifying theme seems to be "Look what weird stuff people want to put in databases - and here's a ZDNet printout to prove it!". This section almost turned me off the book entirely, but thankfully it wasn't repeated. I don't know what they were thinking...

Chapter 2 discusses integrity rules. Integrity constraints are rules that your data should obey - enforcing the rules is the problem. For instance, no two employees should have the same employee number. Essentially, the author's advice boils down to implementing integrity in the database itself rather than via triggers or external logic.

Chapter 3 discusses keys. A key is a field in a record with data that you plan to use to pull that record from the table - for instance, if you were getting information about employees, you might use that employee number as a key, because one employee number should correspond to one record and one employee. The author discusses the various types of keys and makes obvious recommendations.

Chapter 4 talks about duplicate rows. It's actually an insightful discussion about a serious flaw in many databases designed by amateurs, and the author provides a few possible paths for how to do something that is surprisingly difficult in large tables: getting rid of duplicate rows. A valuable chapter.

Chapter 5 discusses normalization. Good overview, good recommendations.

Chapter 6 discusses entity subtypes and supertypes - essentially, what do you do when you have items to store in a database that have some traits in common but some not in common. The nomenclature was a little confusing. He discusses some oddities in the most recent SQL standard, which mostly went over my head.

Chapter 7 discusses data heirarchies and trees. In a nutshell: there are no trees in SQL. The author is distressed by this.

Chapter 8 covers redundancy, more or less an extension of chapter 4. Good coverage, mostly seems to be common-sense, but then I've seen plenty of databases that lacked this common sense, so perhaps it isn't as common as one would hope.

Chapter 9 is about quota queries, a common task in any database project, and one that usually seems to have exactly one example in any set of documentation. (Not enough!) Some good tips are hidden in here, and it should be helpful to many DBA's.

Chapter 10 covers missing information, the difference in database-land between a field with (say) Yes, No, an empty string, or a null value, which has given everyone who does any sort of database programming problems at one time or another. The author's analysis is sound and useful.

To sum up, it's a decent book covering a wide range of areas pertaining to databases from a scholarly viewpoint. Perhaps it could be compared to Sun Tzu's Art of War - it doesn't really discuss YOUR situation, but it gives a lot of tips, and if you pay attention, you'll probably find something in there that will help you in your present crisis. The author is more of a scholar than a hands-on instructor, but he obviously knows what he's talking about. The book title should probably be "The Zen of Databases" or something like that, though, rather than implying it will be some sort of practical guide to administering SQL Server 7 or anything along those lines. Probably the people who will get the most benefit from it will be DBA's who have learned database administration from the school of hard knocks - learn by doing - but find themselves doing it more often than they would like, and want to get a little book-learning in to help them past the problems they are encountering. Novices won't get a lot out of it because they won't have hit the problems he describes. Experts will already know the solutions he recommends, although they'll probably get something out of it nonetheless.

The author has a website, Database Debunking, which has a similar tone to the book. There is also online errata for the book.

Purchase this book at Fatbrain.

Fabian Pascal has written this work on issues that come up in database administration and recommendations for solving them. It's not really a practical guide, despite the title, but probably many administrators would benefit from reading the book and keeping it handy somewhere. Yes, I mean you, the one who's got a copy of Filemaker Pro at home and thinks he knows it all.

Practical Issues in Database Management author Fabian Pascal pages 256 publisher Addison-Wesley rating 7.5 reviewer Michael Sims ISBN 0-201-48555-9 summary Not a practical, hands-on book at all; contains high-level database problems and theoretical solutions

Most of the time, when a computer book has the word "practical" in the title, it means one thing: examples. Lots and lots of real-world, cut-and-paste examples intended to solve the exact problem you're facing. This book departs from that stereotype by containing little in the way of practical examples. I don't think it even mentions any specific database products. Instead, it mainly discusses the platonic ideal of a database from a scholarly standpoint, and never touches actual examples of database products. As such, it is a relatively timeless book, but it is not what I would describe as "practical".

Essentially, it is a scholarly overview of the whole concept of databases, some common pitfalls that database administrators (DBA's) run into, and where actual database systems fall short of the platonic ideal. It would be a good book for an "Intro to Databases" class (and I don't mean a How to Use Excel course, I mean a CompSci course).

Let's skim through the chapters. I'll try to make this review accessible to all readers, even those who don't know much about databases.

Chapter 1 discusses datatypes (how data is stored in the database), and suggests that DBA's should not fall into the trap of using complex, proprietary datatypes over standard character and numeric fields. Chapter 1 also includes the oddest section of the book: 20 pages of Webpage print-outs whose sole unifying theme seems to be "Look what weird stuff people want to put in databases - and here's a ZDNet printout to prove it!". This section almost turned me off the book entirely, but thankfully it wasn't repeated. I don't know what they were thinking...

Chapter 2 discusses integrity rules. Integrity constraints are rules that your data should obey - enforcing the rules is the problem. For instance, no two employees should have the same employee number. Essentially, the author's advice boils down to implementing integrity in the database itself rather than via triggers or external logic.

Chapter 3 discusses keys. A key is a field in a record with data that you plan to use to pull that record from the table - for instance, if you were getting information about employees, you might use that employee number as a key, because one employee number should correspond to one record and one employee. The author discusses the various types of keys and makes obvious recommendations.

Chapter 4 talks about duplicate rows. It's actually an insightful discussion about a serious flaw in many databases designed by amateurs, and the author provides a few possible paths for how to do something that is surprisingly difficult in large tables: getting rid of duplicate rows. A valuable chapter.

Chapter 5 discusses normalization. Good overview, good recommendations.

Chapter 6 discusses entity subtypes and supertypes - essentially, what do you do when you have items to store in a database that have some traits in common but some not in common. The nomenclature was a little confusing. He discusses some oddities in the most recent SQL standard, which mostly went over my head.

Chapter 7 discusses data heirarchies and trees. In a nutshell: there are no trees in SQL. The author is distressed by this.

Chapter 8 covers redundancy, more or less an extension of chapter 4. Good coverage, mostly seems to be common-sense, but then I've seen plenty of databases that lacked this common sense, so perhaps it isn't as common as one would hope.

Chapter 9 is about quota queries, a common task in any database project, and one that usually seems to have exactly one example in any set of documentation. (Not enough!) Some good tips are hidden in here, and it should be helpful to many DBA's.

Chapter 10 covers missing information, the difference in database-land between a field with (say) Yes, No, an empty string, or a null value, which has given everyone who does any sort of database programming problems at one time or another. The author's analysis is sound and useful.

To sum up, it's a decent book covering a wide range of areas pertaining to databases from a scholarly viewpoint. Perhaps it could be compared to Sun Tzu's Art of War - it doesn't really discuss YOUR situation, but it gives a lot of tips, and if you pay attention, you'll probably find something in there that will help you in your present crisis. The author is more of a scholar than a hands-on instructor, but he obviously knows what he's talking about. The book title should probably be "The Zen of Databases" or something like that, though, rather than implying it will be some sort of practical guide to administering SQL Server 7 or anything along those lines. Probably the people who will get the most benefit from it will be DBA's who have learned database administration from the school of hard knocks - learn by doing - but find themselves doing it more often than they would like, and want to get a little book-learning in to help them past the problems they are encountering. Novices won't get a lot out of it because they won't have hit the problems he describes. Experts will already know the solutions he recommends, although they'll probably get something out of it nonetheless.

The author has a website, Database Debunking, which has a similar tone to the book. There is also online errata for the book.

Purchase this book at Fatbrain.