Discussion :

[martinbrait]

Bonjour CinePhil,

Es-tu maître du modèle de données ou dois-tu faire avec l'existant sans y toucher ?

Oui, je suis maître du modèle de données.
Pour cette raison, j'ai réalisé un schéma que je crois juste,
pour ne pas chercher partout les informations non redondantes, que je stocke.
(150 tables, c'est à dire +- 1500 colonnes, cqfd un effort de mémoire pour 1500 mnémoniques et 1500 libellés désignant mes colonnes)
Très nombreuses, mes tables sont néanmoins toutes justifiées.
+- 50 tables de mouvements, historiques et/ou de liaisons;
+- 100 tables de référence;
Peut être aurais-je dû me limiter à un modèle moins expressif de 120 tables ?

10 tables de mouvements et 30 tables de référence sont irriguées mensuellement, par importation de sources de données externe (liaison ODBC).
Elles présentent des données en lecture seule, aux gestionnaires de mon SI.

35 tables sont irriguées quotidiennement, par saisie-ajout-modification-archivage de mes gestionnaires.

5 tables historiques sont uniquement irriguées par des déclencheurs insertion et/ou mise à jour
L'irrigation provient de 3 autres tables, alimentées pour partie, par les gestionnaires, et pour partie, par rafraîchissement du contenu des tables externes en liaison ODBC;
(Cela me permet d'associer quotidiennement matricule, codgrade, date de changement de grade, codechelon, date de changement d'échelon, codposte, date de changement de niveau de poste, niveau de poste)
Lors d'un mouvement d'avancement, dénombrer les jours passé par un employé, ayant un grade donné et un échelon de grade donné, sur un poste d'un niveau donné.
Cela répond au cas d'utilisation consistant à décompter +- des jours d'ancienneté d'un matricule sur un poste d'un certain niveau pour un matricule ayant un certain grade,
et un certain échelon de grade, afin de déterminer une catégorie de vivier d'avancement dans lequel prendre en compte sa candidature.

...tu n'auras peut-être pas besoin de 150 vues. Il doit bien y avoir des tables associatives (composées de clés étrangères référençant les tables en jeu dans l'association) dans ta BDD, non ? Dans ce cas, tu auras une vue qui regroupera les données des deux tables associées via la table associative mais pas de vue spécifique pour la table associative.

Bien compris. Pas de souci.
Aucun stress concernant les vues en lecture seule.

...Pour les modifs à faire sur une seule table, oui, tu as le trigger INSTEAD OF sur la vue de la table.

OK pour le trigger INSTEAD OF.

Présente-t-on dans une vue modifiable, une association de 2 tables, de 3 tables, de 4 tables ...
étant donné qu'il faudra sous postgres, passer par la programmation d'une transaction.
Privilégie t-on beaucoup de petites vues, une seule table, jointe à une seule table associée, un maximum de 2 tables ?
Privilégie t-on moins de vues, et des grosses vues plus exhaustives, en projetant le plus possibles de colonnes, sans se fixer de limites concernant le nombre de jointures avec les tables associées ?

Concernant mon développeur web, il préfère travailler un seul 'tableau' de toutes les colonnes de mouvement, pour ne pas avoir à s'exténuer à programmer des formulaires intriqués très complexes.

...Pour les modifs à faire sur plusieurs tables, tu as les procédures.
Ainsi, tu dis au développeur : "Tu veux modifier les données x et y ? Elles sont dans deux tables, donc je te fais une procédure et toi tu appelles la procédure avec ton programme. C'est simple pour toi parce tu n'as pas à te préoccuper de la structure de la BDD et c'est sécurisé de mon côté parce que les données restent bien structurées. Je peux même te renvoyer des messages d'erreur personnalisées à exploiter dans ton programme (exemple : la donnée X n'est pas dans la plage de valeurs acceptables)."

Ok, bien compris l'exemple, et ce que je dois dire au développeur,
Merci pour la recommandation concernant la gestion d'erreur.

À partir de là, si tu réussis à faire accepter ces principes, on peut t'aider à modéliser ton usine à gaz correctement.

J'ai déjà réalisé le schéma (sans les vues).
Grand merci pour la proposition !
Je transmets mon schéma en ouvrant une nouvelle discussion.

Pour t'aider sur les vues et procédures, ce sera plutôt côté forum Langage SQL et/ou PostgreSQL.

Ok. Je ne pense pas bloquer là-dessus.

Bon courage !

Du courage, du courage et encore du courage.

Uniquement expérimenté sur des projets de 20 tables, je suis à genoux devant ma montagne de 150 tables.
Comment programmer intelligemment les mises à jours mensuelles de 40 tables, et réaliser des vues en lecture seule et vues modifiables,
pour simplifier l'interaction avec 50 tables de mouvement ?

Ce qui me manque, c'est de la méthode, et de la confiance.
Sauter le pas de 20 tables à 150 tables est lourd.
Des conseils et/ou modèles d'organisation seraient bienvenus !

Ce qui me stressait le plus, c'était de me lancer dans les déclencheurs et les procédures, sans être évalué sur l'opportunité de les envisager.
Organiser l'écriture des données, depuis une vue unique, composée de colonnes aux noms aliasés pour interagir avec le contenu de plusieurs tables de mouvement.

Je ne savais pas si c'était une ânerie, ou le prix à payer.
Le travail à fournir se justifait-il ?

Finalement, c'est un point de passage, à un niveau supérieur.

Merci infiniment pour la qualité de la lecture !!!