Using SQL_variant data type for Value sends half of the article's concerns to rubbish.

Including data size calculations.

Filtering by comparing to a datetime value will show only records having datetime base type, no varchar values like 2012-01-21.

And if you do not know how to retrieve items with all 3 attributes having requested values it indicates weakness of your SQL skills, not EAV model.

To enforce data types for certain attributes you may simply use views, triggered if you use it for uploading data.

You simply define a data type in columns definitions and only appropriate values may be inserted into those columns. No additional coding required.

About locking.

When you update an attrribute in a traditional model you lock at least the row having that item.

Whole row. Including all attributes.

If another process is trying to update another attribute it has to wait until the previous update is completed and the lock is released.

And after that it will overwrite the whole row, including the just updated attribute, setting it back to previous value.

Unless you take special precautions for this case in your code - talking about additional coding!!!

And XML.

Oh, right XML!

Best alternative!

Hierarchical list of attributes with associated values.

Nothing like EAV!

And even better - attributes are named in a human language every time they are mentioned. Definitely less storage space than using integer ID's.

And values are all strings, no way around.

Especially good when you share the data with representative offices in Germany, Russia and Korea. Dates saved in local formats (even if you do not allow words for months, still mdy is "only in America" format).

To search against XML you need additional "XML index" - talking about duplicating data storage and extra CPU/IO load (to update the index you actually need to parse uploaded XML and rewrite the index pages).