Your option 2 gives you a lot of flexibility, but makes retrieving the data that relates to a single source record rather painful (multi-table joins). If your application is going to fetch this data a lot then I wouldn't use that schema.
Option 3 works well, as long as you don't need to refer to the serialized data in any SQL statement (i.e. in a WHERE clause, for example.). An alternative to serializing the data is to store an XML block with the additional "columns", something that is becoming fairly common, with DBMS engines that are able to generate pseudo columns from the XML with an internal XML parser.
All in all my hunch is to go with the most straightforward solution (your Option 1), though I obviously don't know all the details of the app to gauge whether this might be too limiting.
Michael
In reply to Re: (OT) Database design: omitted partially filled fields.
by mpeppler
in thread (OT) Database design: omitted partially filled fields.
by BUU
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |