Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[POSTGRESQL] Héritage ou table complémentaire.

2 réponses
Avatar
Etienne
Salut.

Alors ma question du jour est plutôt une question de conception.
J'ai une table de client.
Hors notre extranet est utilisé par toutes les entités de notre groupe.
Et évidement un besoin non prévu originalement vient de faire surface, à
savoir avoir dans la fiche client des informations différentes selon que
le client est un client de telle entité ou de telle entité.

Donc là je m'interroge sur la bonne solution à déployer.
En gros j'ai 3 (ou 4) possibilités:
- soit j'ajoute tous les champs demandés par chaque entité du groupe
dans la fiche client quitte à avoir des tas de champs inutiles pour
telle ou telle entité.

- soit je crée une espèce de table complémentaire (à raison de une table
par entité) dans laquelle je colle les info demandés.

- soit je crée une sorte de table d'attribut et chaque champs
additionnel est une entrée dans cette table avec un type définissant de
quel champ il s'agit. Genre

CREATE table client_attrib(
idclient references client(idclient)
idattibut refercne attibute(idattribut)
ivalue integer,
tvalue text
);

alors là, bonjour les jointures à chaque requète, mais c'est sur que
c'est souple.

- ou enfin, l'héritage. Là le principal problème est la gestion de la
modification. il va falloir que je fasse une table client_entite1,
client_entite2, ... puis que je déplace dans ces tables les clients
existant actuellement dans la table client.
L'autre problème est que si je défini aujourd'hui une colonne
numero_siret dans la table client_entite1
et que demain cette donnée devient nécessaire pour une autre entité, je
serait bon pour faire des grosses manipulations compliquées pour
remonter ce champ dans la table client.

Bref...
Quelqu'un a t-il une idée ou plutot une expérience dans ce genre de
problème ?

Merci
Etienne

2 réponses

Avatar
SQLpro
l'héritage se justifie lorsque l'on interrogent pas les mêmes éléments
racine ensemble. Par exemple un héritage de l'entité personne à employé
et client se justiufie parfaitement car on n'aura ni les mêmes requêtes
ni les mêmes traitements sur les clients (commande, facturation) que sur
les employés (salaire, planning).

Donc, différencier des entreprises par leur genre (SA, SARL..) ne ma
parait pas à priori bon, sauf si vous êtes le site web societe.com !

A +

Le 27/10/2010 10:11, Etienne a écrit :
Salut.

Alors ma question du jour est plutôt une question de conception.
J'ai une table de client.
Hors notre extranet est utilisé par toutes les entités de notre groupe.
Et évidement un besoin non prévu originalement vient de faire surface, à
savoir avoir dans la fiche client des informations différentes selon que
le client est un client de telle entité ou de telle entité.

Donc là je m'interroge sur la bonne solution à déployer.
En gros j'ai 3 (ou 4) possibilités:
- soit j'ajoute tous les champs demandés par chaque entité du groupe
dans la fiche client quitte à avoir des tas de champs inutiles pour
telle ou telle entité.

- soit je crée une espèce de table complémentaire (à raison de une table
par entité) dans laquelle je colle les info demandés.

- soit je crée une sorte de table d'attribut et chaque champs
additionnel est une entrée dans cette table avec un type définissant de
quel champ il s'agit. Genre

CREATE table client_attrib(
idclient references client(idclient)
idattibut refercne attibute(idattribut)
ivalue integer,
tvalue text
);

alors là, bonjour les jointures à chaque requète, mais c'est sur que
c'est souple.

- ou enfin, l'héritage. Là le principal problème est la gestion de la
modification. il va falloir que je fasse une table client_entite1,
client_entite2, ... puis que je déplace dans ces tables les clients
existant actuellement dans la table client.
L'autre problème est que si je défini aujourd'hui une colonne
numero_siret dans la table client_entite1
et que demain cette donnée devient nécessaire pour une autre entité, je
serait bon pour faire des grosses manipulations compliquées pour
remonter ce champ dans la table client.

Bref...
Quelqu'un a t-il une idée ou plutot une expérience dans ce genre de
problème ?

Merci
Etienne




--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Avatar
WebShaker
Le 29/10/2010 18:22, SQLpro a écrit :
l'héritage se justifie lorsque l'on interrogent pas les mêmes éléments
racine ensemble. Par exemple un héritage de l'entité personne à employé
et client se justiufie parfaitement car on n'aura ni les mêmes requêtes
ni les mêmes traitements sur les clients (commande, facturation) que sur
les employés (salaire, planning).

Donc, différencier des entreprises par leur genre (SA, SARL..) ne ma
parait pas à priori bon, sauf si vous êtes le site web societe.com !



Hum.
j'ai finalement opté pour mettre tous les champs dans la même table et
n'utiliser que ceux dont j'ai besoin...

Etienne