The perceived virtue of entity-attribute-value tables is that they will assist in creating a simplified schema (less tables = simplicity in some peoples' minds). The other perceived benefit is that there will be a performance gain due to less JOINs.

Neither of these are real. These tables are not typesafe and all-but-impossible to constrain, thereby destroying any simplicity come maintenance time. Furthermore, if and when the database grows beyond its test size, the single-table solution will almost always result in performance issues due to table scans.

Projects I've seen that utilized these tables shared some common traits: The databases were designed by junior team members, the projects were under budget, and by the time I got there the tables had corroded into massive problem areas that no one wanted to touch. One particular project had a table of this sort with a "datatype" flag. One of the flags was 'bool', which according to the data dictionary (which had not been updated for three years), should be '0' or '1'. Of course, with no constraints in place, this wasn't maintained. When I showed up, I discovered: '0', '1', 'Y', 'N', 'T', 'F', 'Yes', 'No', and NULL. Various applications that had been coded against the database all relied on their particular token value, so fixing the issue took months.