When you need to display different descriptions for Products based on culture, you're doing an EAV even though you've defined the columns very specifically to Products, and in most minds it's a 1-to-Many design, it's underlying concept is still EAV.
No, that's 1 to Many. EAV abstracts out the type of the data. If you have a table like: StringID, LanguageID, DisplayText to handle internationalization, that is not EAV.
If you have a table like: EntityID, AttributeID, AttributeValue where the various attributes addressed by AttributeID are unrelated and/or AttributeValue can contain multiple types of data then you have EAV.
When you get on a roll normalizing your database and abstracting everything, it becomes tempting to keep abstracting until you end up having abstracted the database out of your data, that is where you find EAV.
Having a few untyped fields for the customer to use for reporting is acceptable, but building your database that way isn't.
@jj B
As has been mentioned, your survey design isn't EAV (under most circumstances). It is normalized. My survey databases look very much like that described by tymberwyld with a couple of caveats:
There are two multiple choice types: Choose One and Choose Many
True/False questions are multiple choice questions (Not special). This allows for No Answer and Not Applicable responses.
I have two value columns, one for choices and one for free texts.
To handle Choose Many I set the "value" associated with a response as a power of two and then store the sum of the selected values. This is a little more work on the front end but allows for easily finding surveys with the exact same answers. It does make it more difficult to find "all surveys that selected B", but not that much.
Also note that my survey sets are very small so I don't notice any performance problems that may exist.
--
JimFive