[AC-2003] Plusieurs tables ou une seule ? [Résolu]

[minot83]

Salut

je suis indécis sur la conception de quelques tables : il s'agit de "sites" bâtiments ou voiries ou ouvrages maritimes ou sites de transport, etc...

Ces sites seront concernés par des devis, bons de commande, marchés, factures...

Par ailleurs ces sites sont déjà présents dans une application chargée de gérer les interventions et de détailler les niveaux d'équipements (ascenseurs, accessibilité, DPE, ....) Dans cette appli, ils sont dans des tables différentes (batiments, voiries...)

Dans l'appli compta, je me demande s'il est préférable de les réunir dans une seule table ou de les conserver également dans diverses tables.

Merci de vos lumières

[Richard_35]

Bonjour Minot83,

Eh bien, cela dépend de la liste des champs pour chacune de ces entités : si elles comportent exactement les mêmes champs, il est plus judicieux de ne créer qu'une seule table avec un champ qui spécifie le type de site. Soit, par exemple :

Table Sites :
- Id_Site (clé primaire, numéro auto)
- Id_TypeSite
...

Table TypesSite :
- Id_TypeSite (clé primaire, numéro auto)
- Libelle (bâtiments, voiries, ouvrages maritimes, sites de transport, etc...)

Relations :
TypesSite 1----n Sites, via Id_TypeSite.


La question ne se pose même pas la liste des champs nécessaires est différente.

[minot83]

Bonjour Richard_35

Merci pour ta réponse.

En fait, la liste des champs est différente au sein de l'application "technique" et ne comporterait que 3 champs identiques au sein de l'appli "comptable".

[f-leb]

Bonjour,

Une structure à héritage me semble adaptée à la situation:

Site-1--------1-Batiment
Site-1--------1-Voirie
Site-1--------1-OuvrageMaritime
Etc…

Selon la règle de gestion :
Un site est soit un bâtiment, soit une voirie, soit un ouvrage maritime etc.

Dans la table générique Site, tu mets les propriétés communes à tout type de site (Nom du site, adresse du site,…).

Voir Héritage dans une base de données Access

[minot83]

Bonjour f-leb et merci,

je ne suis pas sûr d'avoir compris...

j'aurais donc :

dans ma dorsale "gestion technique"
- T_batiment(Id, Lb, Surface, ascenseur, volume, chauffage....)
- T_voirie(Id, Lb, longueur, accotements, revetement, etat....)
...

dans ma dorsale "gestion financière"
- T_Sites(Id, Lb, type(bat ou voirie))

Et T_Sites est l'addition de T_batiments et de T_voiries.

[Richard_35]

Bonjour Minot83 et F-leb,

dans ma dorsale "gestion technique"
- T_batiment(Id, Lb, Surface, ascenseur, volume, chauffage....)
- T_voirie(Id, Lb, longueur, accotements, revetement, etat....)...

==> à la vue des tables existantes, deux autres solutions, à ajouter à celle de F-leb (que je salue, "au passage"...) :

1. Ajouter tes champs "comptables" dans les tables existantes (mais, peut-être, ne le peux-tu pas) ;
   
   
   
2. Adapter la première proposition de la manière suivante :

Table Sites :
- Id_Site (Id de T_batiment ou de T_voirie ou etc... )
- Id_TypeSite (type de site, donc la table d'où provient l'Id_Site)
- ChampComptable1
- ChampComptable2
...
==> ATTENTION : la clé primaire doit être le couple Id_Site/Id_TypeSite.

Table TypesSite :
- Id_TypeSite (clé primaire, numéro auto)
- Libelle (T_batiment, T_voirie, etc...)

Relation :
TypesSite 1----n Sites, via Id_TypeSite.

[minot83]

Tout-à-fait d'accord avec ceci Richard.

La question c'est est-ce réellement mieux de gérer les sites dans une seule table au sein de l'appli "compta" ou dans plusieurs?

Les sites seront successivement concernés par des bons de commande, factures...

Sera-ce indispensable? pour réaliser des états ou formulaires?

Et pour les mises à jour?
Si je créé des sites du côté "compta" ou du côté "technique" je vais me retrouver avec des id identiques à tort.

[f-leb]

re,

Qu'est-ce que la réplication?
La réplication de bases de données est une technique qui crée un ensemble de copies de la base de données et de ses données et qui les maintient synchronisées. Ces différentes copies peuvent être utilisées par différents utilisateurs, peuvent être situées sur des ordinateurs distincts; il n'est pas nécessaire que ces copies soient toujours connectées entre elles...

c'est ce genre de techniques que tu recherches ?

[minot83]

Envoyé par f-leb

re,
c'est ce genre de techniques que tu recherches ?

Re, disons qu'entre plusieurs applications, certaines tables sont communes.
Je me suis demandé s'il était mieux de créer une dorsale "commune" afin d'y gérer les tables liées avec les autres dorsale. Mais non car je perds l'intégrité référentielle.

Par conséquent, je réfléchis sur comment telle base fera "profiter" à telle autre base, de ses tables, mais en pouvant d'un côté comme de l'autre, modifier les données.

Et de plus ces tables n'ont pas la même utilité d'un côté et de l'autre, c'est pour cela que je souhaitais fusionner en sites les différents domaines (voiries, bâtiments....)

[f-leb]

j'essaye de comprendre le besoin...

Pourquoi ne pas choisir UNE seule dorsale avec toutes tes tables reliées par l'intégrité référentielle et DEUX frontales (compta, technique) ?

[minot83]

Envoyé par f-leb

j'essaye de comprendre le besoin...

Pourquoi ne pas choisir UNE seule dorsale avec toutes tes tables reliées par l'intégrité référentielle et DEUX frontales (compta, technique) ?

Pour éviter que le nombre d'utilisateurs simultanés soit trop élevé.

En gros je suis à 10 utilisateurs par base en permanence, si je réunis tout, je passe à 30.

[Richard_35]

Bonjour à tous,

Il me semble que tu as plusieurs solutions à adapter à ton besoin : pour cela, il faut rentrer, réellement, dans le détail, ce que, toi seul peut faire, dans l'état actuel des choses.

Néanmoins, certains de tes propos me rendent perplexe, par exemple :

Si je créé des sites du côté "compta" ou du côté "technique" je vais me retrouver avec des id identiques à tort.

==> c'est ton processus qui remplira correctement les Id. C'est pour cela que Id_Site (Id de T_batiment ou de T_voirie ou etc...) n'est plus en numéro automatique.

Ajouter tes champs "comptables" dans les tables existantes (mais, peut-être, ne le peux-tu pas)

==> le peux-tu ?

[minot83]

Envoyé par Richard_35

Bonjour à tous,
Il me semble que tu as plusieurs solutions à adapter à ton besoin : pour cela, il faut rentrer, réellement, dans le détail, ce que, toi seul peut faire, dans l'état actuel des choses.

==> c'est ton processus qui remplira correctement les Id. C'est pour cela que Id_Site (Id de T_batiment ou de T_voirie ou etc...) n'est plus en numéro automatique.

Oui je saisis bien, mais c'est là que je parviens pas encore à me décider. Si je conserve chaque type de site dans une table différente, quel sera l'impact ou la difficulté d'exploitation ultérieure? En fait je n'en vois pas particulièrement, si ce n'est des requêtes un peu plus lourdes...
Par ex : lister toutes les factures sur une commune, dans l'ordre chronologique.
On aura la T_fact, les T_bat, T_voirie, T_ouvrages_maritimes, T_ouvrages_montagne ainsi que la T_Commune.

Si je regroupe, je n'aurais que
T_fact, la T_sites ainsi que la T_Commune.


==> le peux-tu ?
Je n'y ai pas vraiment d'intérêt, je pense, vu que je vais gérer les "actions" comptables principalement dans des tables intermédiaires entre les sites et les factures par exemple. Sachant qu'une facture peut concerner plusieurs sites. Et qu'un site est forcément concerné par n factures.

[Richard_35]

Je n'y ai pas vraiment d'intérêt .../...

==> eh bien, l'intérêt, c'est que, au lieu d'avoir des relations 1 pour 1 (qui, en fait, désigne la continuité d'un même enregistrement), tu as tout dans la même table.

Sachant qu'une facture peut concerner plusieurs sites. Et qu'un site est forcément concerné par n factures.

==> ce sera pareil avec tes tables intermédiaires avec les relations 1 pour 1.

Par ex : lister toutes les factures sur une commune, dans l'ordre chronologique.
On aura la T_fact, les T_bat, T_voirie, T_ouvrages_maritimes, T_ouvrages_montagne ainsi que la T_Commune.

==> si tu prends la solution de la table unique (post #6), tu n'auras qu'une seule table "comptable". Mais, de toutes manières, si tu as besoin, pour une raison ou pour une autre, d'aller chercher des informations dans la table "non comptable", tu seras obligé de distinguer ces différentes tables "non comptable".

[minot83]

Richard, je ne vois pas comment je pourrais contenir plusieurs factures dans une table site?

Fact 1------n Fact-Site n------1 Site

[minot83]

Allez je mets ça en image

http://hpics.li/d647c54

[Richard_35]

Bonjour à tous,

Excuses-moi, mais il y a deux choses différentes :
- une table unique ou plusieurs tables ?
- comment facturer ?

L'une est liée à l'autre, bien sûr. Mais, il y a une partie "analytique" (structure des tables) et une partie "processus" (formulaires). Si ce que tu appelais "les champs comptables" sont, en fait, les champs de facturation, alors il me semble qu'il y a erreur sur la dénomination.

J'avais compris, et sans doute mal compris, que les "les champs comptables" pourrait être, entres autres, le compte comptable associé au site.

La solution que je t'avais suggérée est donc le choix 2 de ton schéma, soit :
T_Sites :
- Id_Site (Id de T_batiment ou de T_voirie ou etc... )
- Id_TypeSite (type de site, donc la table d'où provient l'Id_Site)
==> ATTENTION : la clé primaire doit être le couple Id_Site/Id_TypeSite ;
==> que représente le champ Lb_site (j'espère que ce n'est pas le nom du site que tu veux recopier...).

Table TypesSite (manquante dans le schéma) :
- Id_TypeSite (clé primaire, numéro auto)
- Libelle (T_batiment, T_voirie, etc...)

Relation :
TypesSite 1----n Sites, via Id_TypeSite.

Voilà pour la partie "analytique" qui me semble pertinente (mais je peux me tromper).


Pour la partie "processus" (facturation), tu dis :

Sachant qu'une (même) facture peut concerner plusieurs sites. Et qu'un site est forcément concerné par n factures.

==> donc, effectivement

Fact 1------n Fact-Site n------1 Site

et tu as donc répondu, toi-même, à ta question, il me semble :
Table T_Fact :
- Id_Fact (clé primaire)
...

Table TR_Site_fact :
- Id_Site (clé primaire 1)
- Id_TypeSite (clé primaire 2)
- Id_Fact (clé primaire 3)

Relation :
T_Sites 1----n TR_Site_fact, via Id_Site et Id_TypeSite ;
T_Fact 1----n TR_Site_fact, via Id_Fact.

Sauf erreur, car vite fait.

Cela, sans se pencher sur le fond de ton analyse que je prends comme déjà décidé.

[minot83]

Bonjour,

je te remercie Richard pour ta réponse.

J'ai dû laisser un peu de côté ce problème, afin d'en résoudre un plus prioritaire...

http://www.developpez.net/forums/d10...eme-relations/

J'y reviens donc dès que j'ai réglé ce préalable.

[Richard_35]

Je viens de poster sur ton autre fil.