Breaking up a table vs. NULL values

[Ryan Barninger]

The database for an application I am currently working on is setup so that product information is stored in multiple tables. There is a base table for all products which includes attributes common to all products. Since there are multiple product types, and some product types have unique attributes, another table has been created for each product type that "extends" the base product table in a one-to-one relationship. This table holds all on the unique attributes for that particular product type. This was done in an effort to eliminate NULL values.

FOR EXAMPLE:

PRODUCT TABLE
productid
description
typeid

PRODUCT_TYPEA TABLE
id
productid (foreign key from PRODUCT table)
unique_column1
unique_column2

PRODUCT_TYPEB TABLE
id
productid (foreign key from PRODUCT table)
unique_column1
unique_column2

I created a view for each product type which joins everything up, and a stored procedure which conditionally selects from the appropriate view based on the typeid. Everything works well with this arrangement. However, this seems overly complicated - it involves multiple tables, views, stored procedures - and after all that I end up with the same data I would get if I rolled everything into one product table and used NULL values to indicate that an attribute doesn't apply to a particular product.

Is it appropriate to use NULL values to mean "doesn't apply" as opposed to "unknown"? Also, most of these NULL values would be NULL foreign keys.

Thanks for any advice.