Merci Régis,
C'est ce que j'avais compris oui. J'ai pu évoquer les tables llx_societe
et llx_socpeople pour illustrer mon raisonnement, mais je l'ai mal fait,
ce qui a provoqué cette incompréhension.
Je vais prendre pour exemple la définition d'une table d'abonnés.
Ce qui caractérise un abonné c'est le contenu de la table des contacts
(llx_socpeople). Ce qui caractérise l'organisme payeur d'un abonnement
c'est la fiche d'une société. Toutefois, pour des raisons de gestion, je
dois créer une table spécifique liée à la table des sociétés et à la
table des contacts.
Je vais donc créer une table spécifique (llx_subscriber) qui est liée à
la fois à la table de définition des sociétés et à la fois à la table de
définition ds contacts (llx_socpeople). Cette table va servir à étendre
les caractéristiques de base de l'abonné (le contact).
Le lien qui existe entre ces trois tables est une contrainte forte ce
qui fait qu'il ne peut pas exister un abonné si l'organisme payeur
n'existe pas et aussi s'il n'existe pas dans la table des contacts.
Dans cet exemple je n'ai pas besoin d'ajouter la colonne entité à la
table des abonnés. C'est aussi le cas pour les tables pivots qui ne
servent qu'à établir des relations N à N entre les objets.
Lorsqu'il n'existe pas de contrainte forte entre les tables, comme c'est
le cas dans la relation des contacts (llx_socpeople) avec la table des
sociétés (llx_societe), alors la colonne entité doit être présente pour
chacune de ces tables. En effet, il s'agit d'objet à part entière,
indépendant des uns des autres.
@ vous lire,
-------------------- electronic translation --------------------
Thanks Régis,
This is what I understood. I covered the llx_societe table and
llx_socpeople table to illustrate my argument, but I did it wrong, what
caused this misunderstanding.
I'll take for example the definition of subscribers table.
What characterizes a subscriber is the content of the contacts table
(llx_socpeople). What characterizes a paying agency for subscription is
the society table. However, for management purposes, I need to create a
specific table associated with the companies table and the contacts table.
I will create a specific table (llx_subscriber) which is related to both
the society table and both the contacts table (llx_socpeople). This
table will be used to extend the basic features of the subscriber (contact).
The relationship between these three tables is a strong constraint so it
can not be a subscriber if the paying agency does not exist and if it
does not exist in the contacts table.
In this example I do not need to add the entity column to the
subscribers table. This is also the case for pivot tables which only
serve to establish N to N relationships between objects.
When there is no strong constraint between the tables, as is the case in
the relationship of contacts (llx_socpeople) with the table of companies
(llx_societe), then the entity column must be present for each of these
tables. Indeed, it is an object of its own, independent of each other.
Hope to read you,
-------------------- electronic translation --------------------
Le 28/08/2012 11:45, Régis Houssin a écrit :
désolé je le fait en français :
tu as besoin d'un champ entité sur toutes les tables des objets
principaux (le lien avec la table llx_societe ou llx_socpeople ne compte
pas)
mais par contre tu n'as pas besoin de l'ajouter sur la ou les tables de
détails de cette objet si cette table est liée avec la clé étrangère de
cette objet
exemple :
llx_facture contient un champ entity
mais llx_facturedet non car liée via fk_facture
lorsque tu as un index unique :
UNIQUE INDEX (code)
tu dois rajouter le champ entity
UNIQUE INDEX (code, entity)
pour autoriser les doublons entre entité
lors d'un create() tu dois avoir un "global $conf" et tu utilises
"$conf->entity" pour remplir ce champ
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev