My opinion is to always use rowid column as foreign key named fk_xxx. Code column seems to me to be an old way of doing it.
Bien cordialement, -- *Maxime KohlhaasConsultant associé**ATM Consulting <http://www.atm-consulting.fr>* *+33 6 33 42 92 43* *NOUVELLE ADRESSE* *ATM Consulting* Technosite Valence-Agglo 26 rue Barthélémy de Laffemas 26000 Valence 2014-10-24 14:13 GMT+02:00 Florian HENRY <florian.he...@open-concept.pro>: > Hello all, > I wondering something about best practice with dictionnary dolibarr > implementation. > > I take two exemple about thirdparty. > llx_societe.fk_prospectlevel : a foreign key on > llx_c_prospectlevel.code > The dictionnay llx_c_prospectlevel don't have rowid column > > llx_societe.fk_typent => a foreign key on llx_c_typent.id > The dictionnary llx_c_typent have a id column (should be renamed > into rowid by the way) but also get a code column > > What is the best strategy, to your mind, with dictionnary : > > 1 : > llx_dictionnary_1 (rowid,code,label,active) > llx_table.fk_dict1 => llx_dictionnary_1.rowid > > 2 : > llx_dictionnary_1 (rowid,code,label,active) > llx_table.fk_dict1 => llx_dictionnary_1.code > > For me the best option is 1 but in this case what is the purpose of a > "code" column ? > > Regards. > > -- > Florian Henry > +33 6 03 76 48 07 > florian.he...@open-concept.pro > http://www.open-concept.pro > Twitter : @_Open_Concept_ > Google+ : https://www.google.com/+Open-conceptPro > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
