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 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
