To expand on tuinstoel's suggestion (avoid generic entity-attribute-value structures): While I generally like this structure for light use, excessive (whatever that means) usage will degrade performance as noted. Such structures cannot be well indexed. I wrote and supported one such system. By the time we had 50,000 "entities" each with 10-100 keys it was SLOW even on midrange hardware).
However, they are very useful and fairly easy to implement. So if there's a need for many arbitrary "extra fields" to be added on a per customer basis, then it may make the most sense.
Another possible option might be to add a number of unused generic column in appropriate tables to be used by clients for their own purposes. Some enterprisy applications do just this. A Sales table might have ten or twenty CUSTCODE01 to CUSTCODE10 columns which each deployment of the application can use in different, wholly custom way.
This may at first look horrid, it may also be a happy medium. There is a fair amount of room to customize on a per-customer basis without a) "just adding a column" and disrupting the application or development process, or b) implementing a potentially slow generic system. You only get a limited amount of felxablity, though, and there is a lack of self-documenting column names (but column descriptions can be customized as needed).
