As Lynn pointed out, it stands for "Entity, Attribute, Value" which identifies the general structure of the EAV table. These tables offer incredible flexibility because the table structure doesn't need to change to "add a column" like a normalized table would. As is true with many other things, such flexibility comes at a great cost when trying to use the data. For example, most people make the mistake of storing the data as character based data which causes the meta-data for the data type of the data to be lost. And, as you've just seen, unless you work with pre-aggregated Cross Tabs or Pivots, the data can be quite difficult to interogate. For the most part, you can also forget about DRI (Declared Referential Integrity) and other forms of check constraints. The big advantages are, of course, the flexibility to add attributes (virtual columns, in this case) to the entities (individual templates for items, in this case) without any structural changes ever as well as only having to worry about a single, well formed index (although, an index on the data itself will be impractical if it exceeds 900 bytes in width). Another advantage is that there's never the need for a NULL in an EAV.

In most cases, such tables should generally be avoided because the benefits usually don't come close to outweighing the benefits of normalized tables.

In the case of the post production template table you have, the TemplateID is the "Entity" that will have many attributes (columns). The SpecID column is actually the attribute identifier or "column name" that the data would be stored in if it were a normal table. Of course, your Data column is the "Value" column.

Again, these types of tables should generally be avoided because they violate most practical rules for relational databases, including but not limited to even the most basic rules of normalization. They're almost as bad as XML or any other tagged data structure when it comes to normalization and DRI. 😉