sounds right to me. another point - if we're talking about a dbms, the
main 'con' is that it is basically a con game.  sometimes it's sold to
the customer as a 'framework'.  really a shell game where the the dbms's
ability to manipulate the customer's model of the customer data is
discarded and the dbms is demeaned becoming not much more than a
physical access method.  so it's up to the 'framework' to invent new
verbs, catalog et cetera.  whether these are complete, sufficient, safe,
portable and so forth is entirely up for grabs, which results in the
main 'pro' - "jobs for the boys" as the consultants' union might say.
meanwhile the customer believes, wrongly, that his investment in the
system software has long-term value but he is actually being screwed.
doubtful whether there is any "schema" that can be discussed logically
- maintenance becomes either a very crippled proposition with limited
choices for extension or every new function becomes a separate adhoc
effort.  normalization and other advantages are thrown out the window
along with the baby and the bath water - might as well invent your own
dbms from scratch.

p

bill of material processors (now mostly referred to as ERP because they
include Job Control) use just this kind of data structure.  there really
isn't much choice if the software producer wants to sell to more than
one company in one industry.  if you're building a system for one
business, then you can build specific tables to the business process
definitions.

BTDBB

This becomes the moot point with PIVOT/UNPIVOT operators. Translating
complex queries is straightforward: take EAV "schema", unpivot it into
the proper relational schema, query it, pivot the result back.

Next comes the performance issue. Clearly, in order for EAV to have
something as basic as multicolumn index, it has to materialize the EAV
data unpivoted into normal relations. Therefore, in principle, it is
possible to have the data stored as EAV with materialized views making
the data appeared as relations. There are a lot of techinicalities,
however. For example, materialized views have to be incrematelly
refreshable (refresh fast on commit). Then, what about concurrency? MVs
are notorious for low transaction throughput.

Thank you all for your replies. I want to thank you, Tony,
specifically, since you pointed me to a discussion that I can refer to.

Also, now I know that the common name for this construction is EAV
(Entity-Attribute-Value), it has been easy to find out more about it.

The best statement I read about it, from a theoretical point of view,
is the following:

"basically, it's Extreme generalization saying that every entity is
made up of attributes, and that "made up" is the relationshsip, and
that attributes may be on several entites"
(http://www.sqlteam.com/Forums/topic.asp?TOPIC_ID=40371)

Interpreting it as follows: Since you force this relationship onto your
model, there is no room for any conceptial relationships to be enforced
anymore.