Database design - one table with many fields, many tables with one field, or abstract tables?

I have to design a schema to store objects that have many properties, but few in common.

I found some solutions here, but I'm still not convinced about the best thing to do. I see four ways of doing it :

1. One table with many fields : this may lead to many NULL values, and a hard time when the need comes to add some properties or modifiy some datatypes.
2. Creating a new table for each property : this makes adding and updating columns easy, and preserves the searching capabilities, though each SELECT will result in lots of JOIN.
3. Creating a table for each type of property, eg: tags, quantities, intervals, etc. I'm not sure in that case if I need to distinguish floats, decimals, integers, etc.
4. Creating abstract tables (I read here it's called Observation Pattern), that store the properties name and datatype.

Which criteria should I follow, which questions should I answer to choose开发者_如何学C between those solutions ?

Thanks

---

I would say that this depends on the ORM technology you are using and the serialization capabilities of your objects.

Generally, I prefer abstraction and flexibility.

---

It depends on what you need to do with the properties. If the properties are of only indirect interest, then 4 is a very flexible and compact solution. What do I mean by an indirect interest? If you need to retrieve and display the information in the properties this is indirect. If you need to do calculations or detailed manipulations with the properties then this is more direct. In other words, if the only method you're likely to use on the properties is ".ToString()" then you can get away with 4. This schema has the significant advantage of allowing you to add new property types without changing your database schema, since these are just new row inserts into your property type table.

If on the other hand, the different property types need to be manipulated in ways which depend on their data types, then it will be a pain to store the different types of properties in one field. If this is the case you could do 3., but this is also a problem because it requires you to know which table to go to to get a value of a particular type. This isn't an insurmountable problem but it isn't elegant either.

Instead of 3. you could try a sort of hybrid aproach where your single property table has multiple columns, one for each data type, and preferably one other column - maybe a calculated column - that acts as a "ToString". This way your indirect uses can go to the simple, predictable spot and only your more involved applications need to worry about which column to go to for a particular property type.