The Case for the Special Case

I found myself today strugglingly immensely with modeling "typical" business data. If this isn't a sign of a true novice, I'm not sure what is...

Essentially, from a database perspective, I'm struggling with look-up tables - those values like 1 = DVD, 2 = Book, 3 = CD, etc. to use Products and Product Types as an example. So I have a Product class and and Product Type class, but I realize that not all data for a DVD will go with a Book or CD, so the different Product Types become subclasses of Product. Am I right in calling these an occurence of Fowler's Special Case EAA Pattern?

At this point, depending on the application, I might ask myself: "well then why in the world do I have a Product Type class?!" In one application, I realize that I still need the Type class because I need those boolean, read-only properties like "IsBook". This, however, leads to a more intensely puzzelling dialouge that I have yet to close knowing that I've explored it thoroughly: so do I store those flags in the database? But if I do, those data members shouldn't be mutable...should they?? What's the point in having all those ProductType classes (or classes that implement an IProductType interface) if I'm going to have 1 per record in the database? If the user adds a new type, won't I have to create a new class that implements that IProductType interface as well?!

I have to say that, while I was writing this, the debate was continuing to swirl about in my head and I came up with yet another question: so, if I have all those different IProductType objects, I could only store the necessary data in the database (e.g. name, PKID, description, etc.) and then have the immutable boolean properties to determine whether or not it is of the type I'm looking for (e.g. IsBook), but I still have to create another object for every new type that's created. Granted, a product catalog, and other applications with similar models, have a lower probability of being modified. If I'm Amazon, sure I'm going to have books, CDs, movies, etc. and maybe every-so-often I'll update my product line so that I can offer my customers more items. I suppose that's the risk involved - knowing that the model is only as good as the defined application and data requirements.

Maybe these are extremely simple questions, but I feel I'm not looking in the correct places for answers. I checked out an older version of NHibernate (0.3.0.0) and noticed their IType interface for working with the various types used in defining properties/member data. Almost immediately, I reverted back to my arguments: it doesn't matter, they don't have to ever pull those ITypes from a persistant medium!

I feel as though this would be a rather all-to-common problem/scenario in Agile/Domain-Driven Design and that there's gotta be some-sort-of formal response to the questions out there that the GoF or Fowler just copy and paste to people like me when I mentioned the points I've raised here. I'd love to find some sort of article or two to at least hear rebutals to my arguments and answers to my questions...