danycxxx wrote:
> Yes, I've looked at it, but id doesn't create the desired output. After more
> research I've found that I my design is similar to Entity, Attribute and
> Value(EAV) design and I think I have to redesign. Any suggestion regarding
> EAV? Is there any other approach?
EAV is controversial. I am uncomfortable with it because it implements
keys as values.
I suggest that you not use EAV. Its putative flexibility comes at a large
implementation price.
The other approach is relational database design. You model an entity as
a collection of tables, each of which represents an aspect of the data
pertinent to the entity. Each table has columns, the labels of which
correspond generally to the names of attributes for that aspect. Each
row of each table provides values for its respective named columns.
So a table roughly models what I'll call an "entitylet" - a cohesive piece
of the entity model.
The rules to decompose entity models into relational data models
constitute "normalization". I suggest you create a relational data model
normalized to at least third normal form.
--
Lew
