Okay ... for your problem domain, pull them back into the Death and Wedding table (but name them something better than xxx_1 and xxx_2 --- groom_first and bride_first may become un-pc but I'd worry about the downstream maintenance dev finding my home address than a PC fascist).

Actually, it's a lot closer than you think :) With gay marriage being legalised and given the number of homosexuals who are internet oriented, I suspect that a lot of our wedding announcements are going to come from that quarter. My own, for instance...

I've been burned way too many times by meta systems that make adding a new type fairly easy but asking a simple question like "how many deaths notices did we have for November" caused a monster headache of building a slew of objects and then asking each object are you of type "death" and did you occur in "november." While a straight sql to answer that question would take milliseconds - going through the object hierachy takes hours.

I couldn't agree with you more. Which is why I'm leaning toward option number 3.

The one difference of opinion I have is that I think I should be designing the interface first, then the implementation, rather than the other way around. Putting the implementation first, in my experience, tends to produce data driven interfaces that can map poorly to application.

I know what I want it to do, but now I want to figure out the best way of implementing it