Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Sunday April 22, 2007
05:52 AM

Why I Didn't Buy Your Book

[ #33064 ]

I was browsing a book store the other day and I picked up a book about database design (I can't recall the name). I flipped through the index and it seemed reasonable. There were interesting points regarding using surrogate keys for tables (I prefer surrogate keys, but not everyone does and there are valid arguments each way). I saw some great examples of database design flaws and how to correct them, but I was a caught a bit short when the author wrote that the two reasons for having a NULL in a column are when the data are unknown or inapplicable. There appeared to be absolutely no discussion about how the presence of NULLs can lead to incorrect query results or how to provide greater information about why the NULL is in the database in the first place. Still, this is about par for database books, so I didn't pay it a lot of attention.

The discussion about normalization came rather late in the book, but the author explained that this was because normalization had already been applied throughout the book, but now they were going to get to the underlying rules. OK, that sounds like a valid approach. Then they recap what they've learned before:

  • Each class is a table
  • Each object is a row
  • Inheritance is supported by ...

The book went back on the shelf. This was supposed to be an implementation agnostic database design book.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What! I won't be able to sleep now! : )
    • ... sucking up to your rich uncle.

      Where there's a will, there's a relative.

      Seriously, the book was suggesting using other tables for subclasses and foreign key constraints against the original table. This, however, can lead to very clumsy code, though in practice, this is what is generally done. What if you want to save changes to a class? You class code needs to keep track of all tables which are affected and update them accordingly. I've done this and it can get quite complicated.

      That being sai