Discussion :

[Zineb2014]

Bonjour,

je travaille avec une table composée d'un certain nombre de champs.Mais l'année prochaine la structure de la table va changer(un autre champ qui s’ajoutera suite à des besoins métiers), sachant que cette table est objet d'une relation récursive ( relation du genre père/fils avec plusieurs niveaux).
bien-entendu je dois gérer ce nouveau champ et cette récursivité tout en maintenant l'ancien affichage sur 2018 et années antérieures. j’espère que mon problème est clair, je compte sur vos réactions !

Merci d'avance.

[escartefigue]

Bonjour,

Si aucun traitement n'est prévu pour alimenter une valeur rétroactivement sur les lignes existantes pour la nouvelle colonne, alors il faudra gérer par traitement les cas d'antériorité (test de nullité...)
Le fait que la requête soit récursive ne change rien.
Si vous utilisez la table au travers d'un vue, ce qui est fortement recommandé, la vue prendra en charge l'éventuelle conversion (COALESCE par exemple)

Par contre il s'agit d'une nouvelle colonne et non d'un nouveau champs, les champs sont les attributs d'un formulaire et non d'une table

Pouvez vous communiquer le DDL CREATE TABLE avant et après modif ? (quitte à anonymiser si besoin)

[aieeeuuuuu]

Bonjour,

Je traiterais ça comme un cas d'héritage : aucune modification dans la table actuelle, mais ajout d'une seconde table héritant de la première et contenant les nouvelles colonnes.

Comme indiqué par escartefigue, il serait alors préférable de passer par une vue faisant la jointure (externe) entre ces deux tables, et gérant le contenu des nouvelles colonnes pour les "anciennes" données en fonction de vos règles de gestion.

[Zineb2014]

Je vous remercie pour vos réponses.
l'ajout de la nouvelle colonne en fait impacte la récursivité, puisqu'un nouveau niveau qui s'ajoute aux 3 niveaux existants et au milieu.!
l'affichage des 3 niveaux en 2018 et antérieur mais sur 2019 il faut en afficher 4.
(si comme on avait pays, région,ville) et on le modifie par( pays,région,province,ville).

[escartefigue]

(si comme on avait pays, région,ville) et on le modifie par( pays,région,province,ville).

Si l'exemple que vous donnez est représentatif, alors c'est une erreur de modélisation, il faudrait 4 tables distinctes, une pour chaque niveau géographique

[Zineb2014]

alors c'est une erreur de modélisation, il faudrait 4 tables distinctes, une pour chaque niveau géographique

une erreur ... je ne pense pas ,mais il n 'a pas de modèle parfait , tout modèle a des avantages et des inconvénients ça d'une part. d'autre part, pourquoi créer 4 tables qui seront constituées des même colonnes !!! le mieux est d'avoir une seule table avec une colonne pour distinguer les types ( les niveaux) sinon à quoi peut servir la récursivité !

[soazig]

Bonjour,
Peux tu nous donner la structure de ta table, et ce qui change entre les deux années, parce que je crois que dans l'abstraction on risque de te donner des conseils erronés ou qui ne s'applique pas à ton problème ?
Merci
Soazig

[escartefigue]

une erreur ... je ne pense pas ,mais il n 'a pas de modèle parfait , tout modèle a des avantages et des inconvénients ça d'une part. d'autre part, pourquoi créer 4 tables qui seront constituées des même colonnes !!! le mieux est d'avoir une seule table avec une colonne pour distinguer les types ( les niveaux) sinon à quoi peut servir la récursivité !

Tout à fait d'accord, mais en ce cas on ne rajoute pas de colonne quand un niveau apparait, on ajoute une nouvelle valeur pour identifier ce niveau
Donc
- soit les attributs pour chaque niveau géographique sont différents, auquel cas on modélise autant de tables que nécessaire, et une requête non récursive permet d'assembler les morceaux
- soit les attributs sont identiques, on identifie le niveau par une nouvelle valeur d'un attribut existant, et une requête récursive permet d'assembler les morceaux

[Zineb2014]

@ escartefigue : dans mon cas ,on a opté pour le 2eme scenario : une seule table avec une relation récursive.
ma question est étant donné qu'un nouveau niveau va s'introduire en 2019, comment puis je faire pour préserver les anciens niveaux sur <=2018 et afficher la nouvelle structure sur 2019 et plus ?.

[aieeeuuuuu]

Bonjour,

Comme indiqué par soazig, si vous postiez la structure de votre table, tout serait plus clair pour tout le monde.

Car tel que vous le présentez, tout comme escartefigue, je ne vois pas en quoi l'ajout d'un niveau supplémentaire pose problème...

A moins en efet, que vous ayez une nouvelle propriété propre aux province (dans votre exemple) que l es autre n'ont pas.

Dans ce cas, comme je le disais, mettez en place un héritage : une table "zone_geographique" regroupant tout, avec les propriétés communes, et des tables de spécialisation, contenant les propriétés spécifique à chaque type de zone.

Ainsi, point de colonnes inutiles (capitale pour une province par exemple), mais vous gardez la possibilité d'effectuer vos requêtes récursives comme avant.