To make our life easier at the moment, we should probably have the generic approach added in addition to the the skinny one, thereby reducing the need to rewrite all the search queries. Though the data entry into the skinny tables should happen in a lazy fashion, meaning that the website should return once the value has been stored in the generic storage and not wait for the values to be safed in the skinny storage as well.
1) I think we might not have to think too hard about it. I do agree this problem exists, but if someone really hits this constraint, then we can add the person1, person2 extension.
2) Though this might sound strange, why don't we store the content *always* in text/html. We can do a conversion before storing if the mime_type was text/plain.
3) Bad idea with the one column per option. I would save the selected options in a list within the generic storage. Though the benefit only works with simple display, on edit we need to work with the option_ids again...
4 + 5) Yeah. This also helps us with the searches (as the searches work on revisions anyway and the live revision is in the skinny tables anyway).
All in all I think we should go down this way. Now the question which arises for myself could we do the generic storage using dynamic types? I mean, this is what dynamic types does in the first place or did I miss something here?
