Discussion :

[splinternabs]

Bonjour tout le monde,

Voila, je me retrouve confronté à un petit pb. Je dois bosser sur une BDD qui contient une certaine table qui aurait pu etre scindée en deux pour une relation 1-N (et ca aurait été plus logique). seulement voila, je dois revoir tout ca, et en proposant la solution des deux tables mon responsable me prend le choux, parce qu'il trouve que c'est plus compliqué et que ca n'apporte pas grand chose par rapport a une table (donc relation 1-1) avec multiples enregistrements. Alors voici ma question, hormis le fait que ce soit plus économe en volumétrie et que l'architecture soit plus "propre", quelles sont les avantages des deux tables pour le 1-n par rapport à une seule table ?
merci pour votre aide.

[hed62]

J'ai du mal à comprendre sans schéma, mais je dirais

- évite les redondances
- empêches certaines erreurs de cohérence
- facilite la maintenance si besoin.

[fsmrel]

quelles sont les avantages des deux tables pour le 1-n par rapport à une seule table ?

Je suppose que lorsque vous n’avez qu’une seule table, vous avez prévu n colonnes du même type (par exemple Quantité_du_lundi, Quantité_du_mardi, etc. Dans cette hypothèse :

1) Que faire quand il faut ajouter des colonnes ? Pleurer. En revanche, si vous avez deux tables, le nombre de lignes correspondant aux quantités est par définition variable, auquel cas ajouter une quantité n’est pas un problème. Vous n’aurez qu’une seule colonne Quantité.

2) Si vous avez deux tables, les fonctions d’agrégation (SUM, AVG, MIN, etc.) sont faciles à utiliser. Avec une seule table et un système par colonnes, ça devient très lourd, et les requêtes existantes sont toutes à réécrire si le nombre des colonnes impliquées change.

3) Si vous n’avez qu’une table, toutes les colonnes ne sont pas forcément valorisées, vous allez vous encombrer de valeurs nulles ou autres, dont il faudra tenir compte dans tous les cas.

4) Si vous n’avez qu’une table, vous serez peut-être amené à définir autant d’index supplémentaires que de quantités du lundi, du mardi, etc.

5) Si vous avez deux tables, vous pourrez n’en voir qu’une par le biais d’une vue de jointure (mais en respectant la vision verticale des choses, c'est-à-dire une seule colonne Quantité pour reprendre mon exemple).

6) Si vous avez deux tables, si la clé primaire de la 1re est K (une colonne ou une liste de colonnes), la clé primaire de la 2e sera K, augmentée d’un attribut permettant de numéroter les quantités (pour reprendre mon exemple).

7) hed62 arrivera bien à trouver d'autres avantages à l'utilisation de deux tables...

[splinternabs]

Merci messierus pour vos réponses.
En fait la solution mise en place est la suivante :
un ensemble d'articles, et pour chaque article un ensemble de quantités. Et pour chaque quantité on réenregistre tout (article, quantité, date ...) donc pas de rajout de colonnes, mais tout est réécris à chaque fois. du coup un article est redondant. Quels seraient les défauts d'une telle organisation.
Perso, je préfere une liste exaustive des articles, et une liste de quantités avec jointure sur les articles.
Merci messieurs

[deltree]

Bonjour,
j'ai eu le même genre de problème avec (plusieurs) chefs, et c'est quand même dément que ce soit aux développeurs de convaincre les chefs de projets de faire une bonne conception .
ralâge mis à part, je vais essayer de t'aider:

A. un bonne conception par sur une base normalisée, donc sans données redondantes comme tu veux la faire. C'est la méthode Merise.

B. si toutefois on estime qu'on peut se passer de cette conception on se prive:
1.de l'unicité des données:
impossible de changer un libellé d'article sans parcourir toute la BD: des heures de maintenance en perspective.

2. De l'efficacité et la simplicité des requêtes: suivant que l'on veuille un seul article, ou les valeurs d'un seul article, il va falloir jouer sur les group by... là une requête simple avec ou sans jointure répond à toutes les questions dans un modèle normal.

3. de la fiabilité: au moindre problème dans le programme, si les données sont incohérentes en base, les group by ne vont plus fonctionner, des articles vont se scinder,
Inversement, si à l'ajout ton N° d'article s'incrémente mal, tu va fusionner eds artcile que tu ne souhaitait pas fusionner.
Avec un vrai modèle, c'est impossible, tu as une erreur de contrainte, et la base de données anticipe et gère tous tes problèmes d'intégrité (contrainte de clef primaire, de clef étrangère)

Comment convaincre davantage qu'utiliser les bonnes méthodes éprouvées est plus efficace et fiable que de réinventer la rouer (enfin la base de données)

Tu as un bon esprit pratique, à toi d'imposer la méthode merise dans les règles de l'art.

[fsmrel]

un ensemble d'articles, et pour chaque article un ensemble de quantités. Et pour chaque quantité on réenregistre tout (article, quantité, date ...)

Pour éviter toute ambiguïté, pourriez-vous nous présenter le schéma des tables ainsi qu'un exemple de contenu ?

[Alain Defrance]

Bonjour,

Quels seraient les défauts d'une telle organisation.

Je répond par :

mais tout est réécris à chaque fois. du coup un article est redondant.

Le sujet et une peu ambigu mais, a première vu je stockerais directement le nombre d'article dans un champ présent dans ton entité article.
Si tu doit gérer des inventaires avec des quantité a des dates précises, (donc obligation de tout réenregistrer (chose qui est plutôt sale a mon sens), tu pourrait avoir une entité articles avec leurs informations, puis une association entre article et la date d'inventaire porteur du nombre présent a cette date.

En ce qui concerne le modèle merisien, il est vrai qu'il est la référence dans la modélisation de base de donnée et je pense que tout développeur ayant a utiliser un SGBDR doit connaitre. Cependant il faut savoir ses limites et accepter qu'il est souvent très lourd pour une structure de base de donnée moyennement grande.
En effet merise interdit la redondance d'information (donc pas le droit de stocker des donnée calculables). de plus la transitivité ne doit pas elle non plus être redondante, chose qui implique de multiples jointures qui sont très lourdes pour la base de donnée.
De plus pour chaque entité il faudra prévoir ajout/modification/suppression. Donc de la production en plus, alors que pour certaines choses (par exemple des catégorie), si il est possible de stocker directement en chaine de caractère sans jointure, et si ça ne pose pas de problème, il peut être compréhensible de dégrader ce modèle pour répondre a des attentes de simples mortelles comme nous, et aux contrainte de temps d'exécution imposé par nos machines actuelles.

[splinternabs]

bonjour tout le monde,

c'est rassurant et a la fois alarmant de voir d'autres personnes qui se battent contre leurs propres responsables pour mettre en place des trucs "propres". je pense en tt cas avoir pas mal d'élements pour aller affronter le boss.

alors que pour certaines choses (par exemple des catégorie), si il est possible de stocker directement en chaine de caractère sans jointure, et si ça ne pose pas de problème, il peut être compréhensible de dégrader ce modèle pour répondre a des attentes de simples mortelles comme nous

Lui est plutot de cet avis, mais je suis persuadé que des évolutions seront à prévoir probablement pas dans l'immédiat, mais c'est tellement l'usine à gaz ce truc qu'il y en aura forcément alors j'ai pas vraiment envie de laisser klkchose de pas très clean.
En tout cas, merci a tous.
ps : comment mettre le sujet en résolu ? je vais encore chercher mais si vous voyez que le sujet n'est pas résolu, merci a vous de me guider pour.