引用那些认为是errors not to make之一的人：

So what are the benefits that are touted for EAV? Well,there are none. Since EAV tables will contain any kind of data,we have to PIVOT the data to a tabular representation,with appropriate columns,in order to make it useful. In many cases,there is middleware or client-side software that does this behind the scenes,thereby providing the illusion to the user that they are dealing with well-designed data.

EAV models have a host of problems.

Firstly,the massive amount of data is,in itself,essentially unmanageable.

Secondly,there is no possible way to define the necessary constraints — any potential check constraints will have to include extensive hard-coding for appropriate attribute names. Since a single column holds all possible values,the datatype is usually VARCHAR(n).

Thirdly,don’t even think about having any useful foreign keys.

Finally,there is the complexity and awkwardness of queries. Some folks consider it a benefit to be able to jam a variety of data into a single table when necessary — they call it “scalable”. In reality,since EAV mixes up data with Metadata,it is lot more difficult to manipulate data even for simple requirements.

The solution to the EAV nightmare is simple: Analyze and research the users’ needs and identify the data requirements up-front. A relational database maintains the integrity and consistency of data. It is virtually impossible to make a case for designing such a database without well-defined requirements. Period.

The table goes on like that and currently has 100+ columns,but in general a single pet will only have around 1-8 of these attributes.

这看起来像一个归一化的情况：将表分解成多个,例如一个用于喇叭,一个用于机翼,所有这些都通过外键连接到主实体表.但是请确保每个属性仍然映射到一个或多个列,以便您可以定义约束,数据类型,索引等.