Discussion :

[tnodev]

Bonjour,

j'aimerai recueillir votre avis sur ce point de conception :

Nous avons une BD de 177 tables et le chef de projet a décidé que ce n'était pas un problème d'utiliser une table existante (en l’occurrence la table de paramétrage des alertes 27 colonnes) pour y stocker un nouveau type de donnée : des catégories de décorations des événement de l'agenda (en ajoutant des colonnes spécifiques : label, couleurs etc...) en précisant dans la table le type de donnée.

Est-ce une bonne chose de procéder de la sorte ?
Qu'en pensez vous ?

Merci

[aieeeuuuuu]

Bonjour,

Pourquoi ne pas créer une nouvelle table ?
A première vue, ça m'a l'air assez stupide mais...
Le "nouveau" type de données a-t-il des points communs avec ce qu'en censé représenter le table en question (héritage ?)

Détaillez un peu La table telle qu'elle est, comment elle sera, le contexte,... qu'on sache un peu mieux de quoi on parle !

[tnodev]

Il n'y a rien en commun entre les deux types de données, ou peut-être la colonne titre !

[aieeeuuuuu]

Et pourquoi le chef de projet ne veut-il pas créer de nouvelle table ?

[asmduty]

On peut aussi stocker les chèvres dans la chambre.
Tout dépend de ce que l'on veut ...
Moi perso je préfère choisir la propreté.

[fsmrel]

le chef de projet a décidé que ce n'était pas un problème d'utiliser une table existante

La compétence d'une personne en termes de modélisation des bases de données n'est pas forcément la conséquence de la fonction exercée par cette personne...

Le problème évoqué serait plutôt le chef de projet lui-même.



La remarque faite par aieeeuuuuu est frappée au coin du bon sens.

[SQLpro]

Ajouter de telles colonnes à une table qui contient des déjà les données de nombreuses lignes est une idée d'une haute stupidité.
En effet :
1) la table a pu vivre sans jusqu'ici...
2) ces nouvelles colonnes sont elles réellement des attributs propres l'entité que la table modélise ? J'en doute
3) que faire des lignes actuelles ? Mettre une valeur par défaut bidon pour éviter le poison des Nulls ou laisser les Nulls afin de gruyériser sciemment la table ?
4) que va t-il se passer si certains programmes utilisant cette table font des SELECT * pour afficher les données de ladite table ?
5) a votre avis la rapidité des requêtes utilisant actuellement cette table dans les programmes existant, sera t-elle améliorée par cet apport de colonnes qui ne sera probablement jamais utilisé ?
6) pour couronner le tout, les nouvelles données, lors des mises à jour, vont bloquer l'accès à la table de manière exclusive ce qui empêchera de lire les autres données et toutes les requêtes tapant dans cette table s'en trouveront donc ralenties....
Bref, il n'y a pas plus stupide que ce genre de chose et si une table à pu vivre sans pendant longtemps, c'est que cela n'a rien à y faire maintenant !

C'est par ce genre de dérive stupide que l'on plombe les performances des bases de données...

A +

[Mattig]

Bonjour

Je suis le chef de projet en question.

Je m'étonne que la description faites par TNODEV du contexte est pour le moins incomplète voir inexistante.

On a une table qui sert à paramétrer des événements dans l'agenda de notre application.
Les utilisateurs peuvent notamment paramétrer
¤ certains caractérisques sur des évenements automatiques. Ils peuvent paramétrer le destinataire de certains événements automatiques. Uniquement des modifications
¤ ils peuvent se créer/modifier des paramétrages qui vont créer des événements sur des déclencheurs .


Nos clients nous réclament de pouvoir personnaliser notre agenda selon leur propre usage.
Il s'agit qu'ils puissent personnaliser la couleur des événements créés.

Il se peut que des clients souhaitent réaliser ce paramétrage par site comem cela est déjà possible pour les exemples précitées. Certains de nos clients peuvent posséder jusqu'à 7 sites qui fonctionnent de façon autonome.

Pour réutiliser l'interface de paramétrage déjà faite (l'url / le formulaire et la liaison avec 1 ou n sites / la liste avec les critères de recherches / l'export-import entre base de données ), je pense qu'il est préférable d'ajouter deux / trois colonnes à la table de paramétrage des alertes. Il y aura peut-etre un peu de travail pour créer un formulaire héritant ou une liste héritante.

Pour l'anecdote, nous avons eu un débat récemment avec TNODEV, ou les positions étaient inversées.
TNODEV souhaitait réutiliser une table existante pour lui faciliter le travail pour le calcul de cumul.
J'étais clairement contre, car dans ce cas la, cette table était utilisée à beaucoup d'endroits et cela risquait d'impacter des fonctionnalités existantes.


Cordialement
Mattig

[fsmrel]

Mattig,


Votre réaction vous honore et je vous prie de m’excuser pour une affirmation qui manifestement n’est pas toujours vérifiée.


Quant au problème posé je vous cite :

« je pense qu'il est préférable d'ajouter deux / trois colonnes à la table de paramétrage des alertes »

Sans la connaissance de votre MCD et des règles de gestion qui l’accompagnent, il n’est pas possible de confirmer ou infirmer votre position de façon objective.

En tout cas, il n’est pas mauvais d’avoir à l’esprit l’utilisation des vues : en laissant intacte la structure de la table en cause et en définissant une table supplémentaire pour le besoin nouveau, il est possible de définir une vue qui soit la jointure (ou l’union ou que sais-je) des deux tables : les utilisateurs (au sens large, c'est-à-dire les programmes) manipuleront une table (virtuelle) correspondant au besoin exprimé en plus des besoins existants.

Si vous préférez ajouter des colonnes à la table existante, il faudra vous assurer des effets des points recensés par SQLpro.

[tnodev]

Maladresse de ma part, je viens de découvrir que notre table alert_param abrite déjà les données de deux tables distinctes !

On va ajouter les colonnes d'une troisième table.

[asmduty]

L'important c'est aussi bien vous que votre chef de projet de réfléchir et prendre la meilleure solution.
Qu'il y ai déjà les données de deux tables déjà dedans, OK, mais c'est pas pour autant qu'il s'agit d'une bonne pratique et qu'il faut continuer comme ça.
Là encore sans plus de détails nous on ne peut pas se prononcer.
En tous cas bonne continuation.

[aieeeuuuuu]

Maladresse de ma part, je viens de découvrir que notre table alert_param abrite déjà les données de deux tables distinctes !

Heu... ça s'appelle une vue ça non ?

On va ajouter les colonnes d'une troisième table.

Tel que vous le dites, vous avez l'air de faire une sacrée usine à gaz.
Attention avec le gaz, ça finira par exploser un jour ou l'autre !

[tnodev]

Bonjour,

on m'a dit que j'avais été malhonnête intellectuellement et je me suis fait taper sur les doigts. Je vais donc vous donner plus d'élément concernant la conception de la BD afin que vous puissiez donner un avis en connaissance de cause.

• Une BD d'environ 180 tables
• Une table «alert_param» contient environ une trentaine de colonnes.
• 6 colonnes communes et classiques sont présentes dans cette table (actif, description, libelle, modifiable, lib_court, ordre)
• Comme ces 6 colonnes peuvent être ré-utilisées, alors on va ajouter dans la table «alert_param», des informations des «obs_trimestrielle» et «categorie_evenement». Ce qui doit représenter une douzaine de colonnes supplémentaires.

Qu'en pensez vous d'un point de vu conception de BD ?


Merci

[asmduty]

Sans un petit jeu de données actuelles, de celles que vous voulez ajouter et la structure de la table en question, c'est difficile ...

[CinePhil]

Une BD d'environ 180 tables

Ça commence à faire beaucoup !

Une table «alert_param» contient environ une trentaine de colonnes.

Là aussi, ça commence à faire beaucoup !
Sémantiquement, que contient cette table ?
Des paramètres d'alarmes ?
Est-ce une table associative ?
Y a t-il par ailleurs une table pour les alertes ?
Y a t-il une table de référence des paramètres ?

6 colonnes communes et classiques sont présentes dans cette table (actif, description, libelle, modifiable, lib_court, ordre)

Elles décrivent quoi ? Les paramètres ou les alarmes ?

Comme ces 6 colonnes peuvent être ré-utilisées,

Que signifie "peuvent être ré-utilisées" ?

alors on va ajouter dans la table «alert_param», des informations des «obs_trimestrielle» et «categorie_document». Ce qui doit représenter une douzaine de colonnes supplémentaires.

«obs_trimestrielle» laisse supposer qu'il y aura plusieurs observations pour une "alert_param". Il conviendrait donc de faire une table séparée pour les observations et de l'associer à "alert_param".
Quant à "categorie_document", s'il n'y a qu'une catégorie de document pour une alert_param, alors c'est une clé étrangère référençant la table des catégories de documents mais s'il peut y en avoir plusieurs, il faut une table associative donc ne pas mettre ça dans la table alert_param.

Qu'en pensez vous d'un point de vu conception de BD ?

Donnez davantage d'explications sur cette partie de votre BDD afin qu'on puisse mieux comprendre de quoi il s'agit. Un schéma (MCD, MLD, Entity/relashionship, diagramme de classe... au choix) serait le bienvenu.

[tnodev]

Je n'ai pas du être clair

Le chef de projet souhaite mettre dans la table «alert_param» des colonnes, sans rapport avec «alert_param», représentant des données d'autres tables (mais qui n'existe pas «obs_trimestrielle» «categorie_evenement») afin de ne pas à avoir à créer ces tables.
La justification donnée est qu'il existe des colonnes communes (nom, sa description, si elle est active, son ordre...) à cette table et ces deux tables virtuelles.

Je vais faire un dessin avec des couleurs !:
Colonnes communes
colonnes réservées à la table originelle «alert_param»
colonnes réservées à la table «obs_trimestrielle»
Colonnes réservées à la table «categorie_evenement»

Dans la table «alert_param»

type de donnée (indique si c'est une alert_param, une obs_trimlestrielle, ou une categorie_document)
nom
description
actif
ordre
colonne 6
....
colonne 24
colonne 25
...
colonne 29
colonne 30
...
colonne 35

[asmduty]

Rien que ça, personnellement, ça me fait un peu peur.

Il devrait y avoir une table générale avec les informations communes, et 3 autres tables avec en clé étrangère la clé primaire de la table commune.

D'ailleurs si vous avez séparé les choses avec des couleurs c'est que vous devez bien vous en rendre compte.

Il n'est peut être pas question de tout refaire, mais autant ne pas empirer les choses et ajouter les nouvelles données proprement, dans une table séparée.

[aieeeuuuuu]

J'en reviens à ma question : pourquoi ne pas créer une table.

Car même par flemme, je ne vois pas : je trouve bien plus compliqué/risqué d'ajouter des colonnes à une table existante que de créer une nouvelle table. Il y a plus de risques d'effets de bord, et dans un cas comme dans l'autre, on modifie le schéma...

Nous n'avons pas assez d'informations "métier", mais -même s'il existe quelques colonnes "commune" - j'ai l'impression qu'on n'est même pas dans un cas d'héritage.

Bref, je pense que vous avez déjà un problème de modélisation, et que tout ça ne va rien arranger.

[CinePhil]

Le chef de projet souhaite mettre dans la table «alert_param» des colonnes, sans rapport avec «alert_param»

Rien que là déjà il est évident qu'il ne faut pas le faire !

représentant des données d'autres tables

Si les données existent dans d'autres tables, il ne faut pas les recopier dans cette table ni dans aucune autre !
Il existe les vues pour constituer des tables virtuelles présentant des données provenant de plusieurs tables.

mais qui n'existe pas «obs_trimestrielle» «categorie_document»

Ces tables n'existent pas mais les données sont-elles présentes dans des tables existantes ?

afin de ne pas à avoir à créer ces tables.

Pourquoi ?
Si de nouvelles tables sont nécessaires, pourquoi s'en priver ?
Mais encore faut-il s'assurer qu'elles sont nécessaires, c'est à dire s'assurer qu'on ne va pas créer une redondance d'information en créant ces tables.

La justification donnée est qu'il existe des colonnes communes (nom, sa description, si elle est active, son ordre...) à cette table et ces deux tables virtuelles.

Non ! Il y a des informations nouvelles qui sont à associer à celles données par la table alert-param.
Si pour une alert-param il n'y a qu'une information nouvelle, alors on peut ajouter un ensemble de colonnes à la table alert_param. Il s'agit simplement de nouvelles propriétés de l'entité type "alert_param".
S'il peut y avoir plusieurs infos nouvelles pour une alert param et qu'une info nouvelle ne se rapporte qu'à une seule alerte param alors il faut créer une table pour les infos nouvelles qui sera munie d'une colonne clé étrangère référençant l'alert_param.
Si enfin il peut y avoir plusieurs alert_param pour une info nouvelle et plusieurs infos nouvelles pour une alert_param, alors il faut créer la table des infos nouvelles et une table associative dont la clé primaire sera composée des identifiants de alert_param et de la table des infos nouvelles. Cette table associative pourra être porteuse d'une colonne valorisant l'info nouvelle pour une alert_param.

C'est le B.A. BA de la modélisation des données !
Mon blog, le cours sur la modélisation Merise de SQLPro et d'autres cours présents sur ce site pourront vous aider à réviser tout ça.
Au besoin, je peux vous former à la modélisation des bases de données ; contactez-moi par MP pour ça.

[tnodev]

Merci de vos remarques