Discussion :

[Jean-Jacques Engels]

Hi,

Je dois créer une table pour stocker des références d'article. Or, en fonction de la famille d'article, les attributs peuvent être différents (les caractéristiques d'une poudre sont forcément différentes d'une mousse ou d'une colle)

Il existe donc plusieurs manières de concevoir l(a)(es) tables(s) : créer une table reprenant les attributs communs à chaque famille d'article et créer ensuite différentes tables secondaires pour y stocker les caractéristiques propres à chaque famille d'article. Cela implique qu'il faudra gérer autant de tables qu'il existe de familles d'article.

Autre possibilité, créer une seule table reprenant les attributs de toutes les familles d'article. Dans ce cas, la plupart des champs de la table qui ont été créés pour entrer les caractéristiques de la mousse ne serviront que pour la mousse. Ces champs resteront vides pour la poudre, par contre il faudra créer des champs spécifiques aux caractéristiques de la poudre. Idem pour la colle, etc.

Voilà, l'une et l'autre méthode ont leurs avantages et inconvénients. Peut-être avez-vous solutionné le problème par une autre méthode, j'aimerais avoir un retour d'expérience sur la manière dont vous avez structuré votre table article ou d'éventuelles suggestions si de bonnes idées vous traversent l'esprit.

Merci.

JJ

[micniv]

C'est une bonne question.
De mon côté j'ai toujours fait une seule table (reste à voir le nb de chps au total) et je personnalise le formulaire selon la famille d'articles ...

[CinePhil]

créer une table reprenant les attributs communs à chaque famille d'article et créer ensuite différentes tables secondaires pour y stocker les caractéristiques propres à chaque famille d'article. Cela implique qu'il faudra gérer autant de tables qu'il existe de familles d'article.

C'est la bonne méthode et cela s'appelle l'héritage.
Cherche dans les tuto.

[Pierre Fauconnier]

Bonjour

C'est la bonne méthode et cela s'appelle l'héritage.
Cherche dans les tuto.

Héritage de table? Je n'en ai jamais entendu parler... Pourrais-tu développer ton idée?

Pour moi, la méthode de créer plusieurs tables (avec ou sans héritage) n'est pas la meilleure, car elle va compliquer les extractions de données. Si l'on veut rechercher par exemple les articles fournis par le même fournisseur ou vendues au même client, on va devoir utiliser des requêtes UNION sur les champs communs des différentes tables, et lorsque l'on va ajouter un nouveau type de produits, on va devoir créer un nouvelle table et modifier les requêtes UNION en conséquence...

Je trouverais pour ma part plus judicieux de ne créer qu'une table. S'il existe beaucoup de champs propres à chaque catégorie d'article, on pourrait concevoir des "sous-tables" reprenant les propriétés spécifiques d'une catégorie et pointant vers la clé primaire de la table des articles. Par programmation, il serait alors possible d'afficher tel ou tel sous-formulaire en fonction de la catégorie de l'article affiché dans le formulaire principal...

Cela étant, je suis ouvert à toute autre idée...

[CinePhil]

Tu n'y es pas du tout !
En plus j'ai déjà expliqué ça tout ce matin même dans ce message

Encore une fois cherche des infos et des tuto sur le concept d'héritage et tu y arriveras.

Pour répondre plus spécifiquement à ça :

Si l'on veut rechercher par exemple les articles fournis par le même fournisseur ou vendues au même client, on va devoir utiliser des requêtes UNION sur les champs communs des différentes tables, et lorsque l'on va ajouter un nouveau type de produits, on va devoir créer un nouvelle table et modifier les requêtes UNION en conséquence...

Les articles sont TOUS dans la table articles qui pourrait avoir la structure suivante :
Articles(ArtId, ArtNom, ArtIdFournisseur, ...)
Il est donc très facile d'avoir tous les articles vendus par un fournisseur ou vendus au même client.

Si un article est une poudre, il figurera en plus dans la table des poudres :
Poudres(P_IdArticle, PConditionnement, PDangerosité, PGranulometrie...)

[Pierre Fauconnier]

Salut Cinéphil,

Dans ce message, tu expliques, me semble-t-il, exactement la même chose que moi... Je ne suis donc pas sûr de "n'y être pas du tout"...

Ce qui me "perturbait", c'est le mot "héritage" dont je n'ai jamais entendu parler au sujet des tables dans le cas présenté ici (et à mon avis, en absence de recherches plus approfondies de ma part, inapproprié dans ce contexte, car aucune table n'hérite de la structure d'une autre, ni en suivant tes explications, ni en suivant les miennes)... L'héritage de tables, tel que le concept est décrit généralement, n'est pas géré par Access. La recherche de tutos sur le sujet mènera donc à une impasse!

Mais je pense que nous développons exactement la même idée tous les deux, car si tu lis bien mon message, tu verras que j'y aborde la même démarche que la tienne, à savoir une table commune pour les propriétés communes, et une table pour chaque catégorie liée à cette table commune par un champ FK => PK ...

[alassanediakite]

Salut tout le monde
cinephil pouvez-vous de temps en temps indiquer des exemples de liens quand vous suggérer des solutions de recherche. (excusez ma paresse).

Pour la solution multitable, les tables sont créées par le programmeur ou leur création est programmée puis exécuté par l'utilisateur?
Je voie déjà le problème de requête sur ces tables: une recherche sur ces tables deviens quasiment impossible.

J'ai eue le même problème pour la création d'un appli de gestion de matériels informatique. Ma solution était de créer une table proprietes(Idpropriete, idproduit, nompropriete, valeurpropriete). Quelles sont vos remarques?