I think part of the problem with these kind of designs is that you can have cases where the logical model is fairly simple on paper but then it gets pretty gnarly when doing the physical implementation.
In your scenario, a lot of times people lean towards doing subtyping in some way. That's all well and good and make sense but the physical implementation can often lead to very complex queries. The other approach I've seen is using an EAV model of some sort. In a nutshell have a lookup table of attributes and then have the attribute IDs and respective values for the attributes of the objects, like those you can see in some of the bigger ERP type of applications. But having worked on both complex subtyping and ERPs with a ton of flexible attribute type of designs, they both give me a headache when I think about it. Both approaches are probably good for different scenarios but sometimes simpler approaches can be better. It really depends on the grand scheme of the project being worked on.
I just found a couple of basic examples of using both which might give you some ideas in those arenas to think about, some discussions about the pros and cons of those approaches as well:
EAV:
http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/what-is-so-bad-about-eav-anyway.aspx
Subtyping:
Sue