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
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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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 *************************
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
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 *************************
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
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 *************************
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
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...
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...