30,997
edits
Language and development rules: Difference between revisions
Jump to navigation
Jump to search
m
→Index performance
m (Typos) |
Tag: 2017 source edit |
||
| Line 264: | Line 264: | ||
Example: | Example: | ||
''idx_societe_user_creat'' is a performance index on table llx_societe for field user_creat | ''idx_societe_user_creat'' is a performance index on table llx_societe for field user_creat | ||
==Denormalized field== | |||
Fields that store a data that is result of calculation of other data already stored is a "denormalized field". It must be avoid if we can, and must be used only for performance purpose. | |||
In such a case, to allow developper to understand that the data is not the value that rule, we must prefix the nameof fiel with "denormalized_". | |||
For example the field "denormalized_lower_planned_end_date" to store the ending date of the last membership of a member. We already have the information, but doing search or filter on it is difficult as it is store into a nother table into another level, so we can duplicate the information into a such field. | |||
If this happen, we must : | |||
- check the any import profile has a function to update the denormalized value during import. | |||
- have a taks in the repair.php to recalculate the value and align the data with the original source. | |||
==SQL Coding rules== | ==SQL Coding rules== | ||