Language and development rules: Difference between revisions

Jump to navigation Jump to search
m
Tag: 2017 source edit
Tag: 2017 source edit
Line 246: Line 246:


==Foreign keys==
==Foreign keys==
Name of a foreign key must start with the prefix <tt>fk_</tt> followed by the table name (i.e. name of the referencing table) (this is required to avoid duplicate names in project that are not allowed even if in different tables by some DBMS like Postgresql) then the field name (i.e. name of the referencing field) (this is to allow to have several foreign keys in same table).
The name of a foreign key must start with the prefix <tt>fk_</tt> followed by the table name (i.e. name of the referencing table) (this is required to avoid duplicate names in project that are not allowed even if in different tables by some DBMS like Postgresql) then the field name (i.e. name of the referencing field) (this is to allow to have several foreign keys in same table).


Example:
Example:
''fk_facture_fourn_fk_soc''  is a foreign key in the table llx_facture_fourn for the field fk_soc in this table (that references the rowid field in another table)
''fk_facture_fourn_fk_soc''  is a foreign key in the table llx_facture_fourn for the field fk_soc in this table (that references the rowid field in another table)


Note: If you develop your own external module, it must have no hard foreign keys that point to Dolibarr standard tables. This will break standard dolibarr upgrades, repair, backup and restore tools and may also break standard features. Foreign keys must be soft foreign keys so managed by the code with no database contraints.
Note when using a foreing key:
- Do not add a hard foreign key (a foreign key controled bydatabase) when the link is not important. This generates more trouble than solution. For exemple, a link to a user table to follow the author of creation of an object is NOT an important link. If parent object,the user, is deleted,the child record will be orphelin but this is not a problem. Record will appear with a cretion author that is "unknown" and that is the truth if we have deleted the parent user.
 
- If you develop your own external module, it must have no hard foreign keys that point to Dolibarr standard tables. This will break standard dolibarr upgrades, repair, backup and restore tools and may also break standard features. Foreign keys must be soft foreign keys so managed by the code with no database contraints.


==Alternative keys==
==Alternative keys==

Navigation menu