on peut partager la base des tiers entre les entités donc il faudrait un champ entité dans llx_subscriber afin de les différencier un abonné lié à un contact dans une entité ne sera pas forcément abonné dans une autre entité
Le 28/08/12 13:10, Marc-Henri Pamiseux a écrit : > 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev Cordialement, -- Régis Houssin --------------------------------------------------------- Cap-Networks Cidex 1130 34, route de Gigny 71240 MARNAY FRANCE VoIP: +33 1 83 62 40 03 GSM: +33 6 33 02 07 97 Web: http://www.cap-networks.com/ Email: [email protected] Dolibarr developer: [email protected] Web Portal: http://www.dolibarr.fr/ SaaS offers: http://www.dolibox.fr/ Shop: http://www.dolistore.com/ Development platform: https://doliforge.org/ ---------------------------------------------------------
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
