Edit Question - KnowledgeHub

Title Body

I'm working with the new version of a third party application. In this version, the database structure is changed, they say "to improve performance". The old version of the DB had a general structure like this: TABLE ENTITY ( ENTITY_ID, STANDARD_PROPERTY_1, STANDARD_PROPERTY_2, STANDARD_PROPERTY_3, ... ) TABLE ENTITY_PROPERTIES ( ENTITY_ID, PROPERTY_KEY, PROPERTY_VALUE ) so we had a main table with fields for the basic properties and a separate table to manage custom properties added by user. The new version of the DB insted has a structure like this: TABLE ENTITY ( ENTITY_ID, STANDARD_PROPERTY_1, STANDARD_PROPERTY_2, STANDARD_PROPERTY_3, ... ) TABLE ENTITY_PROPERTIES_n ( ENTITY_ID_n, CUSTOM_PROPERTY_1, CUSTOM_PROPERTY_2, CUSTOM_PROPERTY_3, ... ) So, now when the user add a custom property, a new column is added to the current ENTITY_PROPERTY table until the max number of columns (managed by application) is reached, then a new table is created. So, my question is: Is this a correct way to design a DB structure? Is this the only way to "increase performances" ? The old structure required many join or sub-select, but this structute don't seems to me very smart (or even correct)...

Tags (comma-separated) Cancel