Discussion :

[martinbrait]

(entre la modélisation et la concrétisation sous postgres).

Bonjour Cinephil,

Besoin de votre grande expertise s'il-vous-plaît.

Contexte :
Actuellement dans une équipe de programmeurs,
Faisant fonction DBA, je dois mettre à disposition de l'équipe du développement front php/html/css,
un schéma de 150 tables correctement modélisées MERISE;
Je suis sous postgres.

J'ai un schéma 'gestion' contenant une grande table intermédiaire de plus d'une centaine de colonnes (genre fichier EXCEL)
J'ai un schéma 'public', rassemblant les nombreuses tables de mouvement, et tables historiques de mouvement

Puis-je présenter aux développeurs,
une seule table de mouvement 'gestion'.'compta', en prenant notamment moi-même
en charge (DBA), la programmation de fonctions et déclencheurs,
pour répercuter, lors de son actualisation par les gestionnaires de l'application,
les modifications d'un enregistrement de 'gestion'.'compta', dans mes tables public.comptabilite#cmp, public.salaire#sal

Cette activité d'implémentation dans les deux tables du schéma PUBLIC, doit rester inconnue
aux développeurs, comme aux gestionnaires.
Ceux ci ont uniquement à connaître, la table intermédiaire du schéma GESTION.



J'ai lu quelque par (source oubliée), qu'on devait tout faire pour faciliter la vie des développeurs,
en les libérant de l'interaction complexes avec des dizaines de tables de mouvement jointes,
pour qu'ils n'aient accès en lecture/écriture, qu'à une seule table intermédiaire de mouvement,
dont toutes les colonnes sont aliasées.
Au lieu d'interagir par transactions sql synchronysées, avec de très nombreuses tables de mouvement,
aux noms de colonnes techniques (emp#id, sal#id,sal#lib etc...)
, les développeurs interagissent avec une seule table de mouvement, dont les noms de colonnes sont aliasés convivialement,
explicitement libellés pour les gestionnaires chargés d'enregistrer des dossiers dans l'application.


En d'autres termes, plus concrets :

L’étape Combiner me permet de créer des jointures à partir de deux tables en une seule session de jointure.
Pour combiner les enregistrements de deux tables séparées, je les joins pour former une nouvelle table plus complète.
Les jointures me permettent de consolider mes données et d’offrir un affichage plus riche des informations qu’elles contiennent,
avec un accès très facile (une seule table intermédiaire)

Dans mon exemple, j'ai joint la table Comptabilité et la table Salaires en utilisant une jointure interne pour créer une nouvelle table qui présente les données d’employés et salaires.
Le gestionnaire saisit ajoute, met à jour ou supprime les données des employés et les données des salaires

Une fois les données actualisées dans cette table intermédiaire par les gestionnaires,
un déclencheur que j'ai programmé répercute la mise à jour des tupples
de cette table intermédiaire, dans les tables sous-jacentes Comptabilité et Salaire.

Concernant mon projet réel, l'étape Combiner me permet de projeter le contenu de 12 tables de mouvement,
dans une table intermédiaire dédiée aux gestionnaires et développeurs, pour afficher, saisir, mettre à jour, supprimer (CRUD)
avec des colonnes aux noms conviviaux.

Je n'ose surtout pas me lancer, de peur d'être à côté de la plaque.
N'ayant jamais pratiqué, voici mes doutes :

Joindre le plus possible de colonnes de mes tables de mouvement,dans une seule table intermédiaire.
Est-ce malin ? Est-ce une usine à gaz de déclencheurs trop compliquée à éviter absolument ?

Qui ressort gagnant d'une telle organisation ?

MERCI POUR VOS PRECIEUX CONSEILS;

[escartefigue]

Bonjour Martinbrait

Bonjour Cinephil

Les autres contributeurs n'ont donc pas voix au chapitre ?

Actuellement dans une équipe de programmeurs,
Faisant fonction DBA, je dois mettre à disposition de l'équipe du développement front php/html/css, un schéma de 150 tables correctement modélisées MERISE;
Je suis sous postgres.

J'ai un schéma 'gestion' contenant une grande table intermédiaire de plus d'une centaine de colonnes (genre fichier EXCEL)
J'ai un schéma 'public', rassemblant les nombreuses tables de mouvement, et tables historiques de mouvement

Une table d'une centaine de colonnes est très rarement une table bien modélisée. C'est une table obèse, source de bien des maux : redondances, incohérences, intégrité non vérifiée, accès concurrents dégradés, index pléthoriques, performances dégradées...

Puis-je présenter aux développeurs, une seule table de mouvement 'gestion'.'compta', en prenant notamment moi-même en charge (DBA), la programmation de fonctions et déclencheurs,
pour répercuter, lors de son actualisation par les gestionnaires de l'application, les modifications d'un enregistrement de 'gestion'.'compta', dans mes tables public.comptabilite#cmp, public.salaire#sal

Les développeurs doivent avoir accès à toutes les tables dont ils ont besoin, idéalement au travers de vues (en principe, les traitements n'accèdent jamais directement aux tables, mais seulement à des vues).
Il faut donc attribuer les privilèges DML aux schémas accédés par les développeurs et créer les vues dans ces schémas.
Les déclencheurs sont effectivement plutôt du ressort du DBA.

Cette activité d'implémentation dans les deux tables du schéma PUBLIC, doit rester inconnue aux développeurs, comme aux gestionnaires.
Ceux ci ont uniquement à connaître, la table intermédiaire du schéma GESTION.

Vu que la table du schema GESTION est très probablement une table obèse, n'exposer que cette table est une très mauvaise idée pour les raisons que j'ai données plus haut.

J'ai lu quelque par (source oubliée), qu'on devait tout faire pour faciliter la vie des développeurs, en les libérant de l'interaction complexes avec des dizaines de tables de mouvement jointes,
pour qu'ils n'aient accès en lecture/écriture, qu'à une seule table intermédiaire de mouvement, dont toutes les colonnes sont aliasées.
Au lieu d'interagir par transactions sql synchronysées, avec de très nombreuses tables de mouvement, aux noms de colonnes techniques (emp#id, sal#id,sal#lib etc...), les développeurs interagissent avec une seule table de mouvement, dont les noms de colonnes sont aliasés convivialement, explicitement libellés pour les gestionnaires chargés d'enregistrer des dossiers dans l'application.

Je suis curieux de savoir où vous avez lu un truc pareil ! Les développeurs doivent être formés aux bases relationnelles et au langage SQL. À partir de là, il faut leur donner accès à toutes les tables et colonnes (encore une fois via des vues) dont ils ont besoin. Les noms techniques ne rebuteront pas les développeurs, puisque ce sont avant tout eux aussi des techniciens . De plus, les noms techniques ne devraient pas contenir de caractères spéciaux tels que le symbole #, ce n'est pas recommandé : ça ne présente aucun intérêt autre que de contraindre d'encadrer les noms par des délimiteurs.

L’étape Combiner me permet de créer des jointures à partir de deux tables en une seule session de jointure.
Pour combiner les enregistrements de deux tables séparées, je les joins pour former une nouvelle table plus complète.
Les jointures me permettent de consolider mes données et d’offrir un affichage plus riche des informations qu’elles contiennent, avec un accès très facile (une seule table intermédiaire)

Parler de sessions et d'enregistrements est inadéquat... Visiblement, on vous confie des taches de DBA sans vous en avoir donné la formation. C'est dommageable pour vous et pour les développeurs.
Si des jointures sont fréquemment utilisées, le DBA peut créer des vues pour ces jointures

Dans mon exemple, j'ai joint la table Comptabilité et la table Salaires en utilisant une jointure interne pour créer une nouvelle table qui présente les données d’employés et salaires.
Le gestionnaire saisit ajoute, met à jour ou supprime les données des employés et les données des salaires
Une fois les données actualisées dans cette table intermédiaire par les gestionnaires, un déclencheur que j'ai programmé répercute la mise à jour des tupples de cette table intermédiaire, dans les tables sous-jacentes Comptabilité et Salaire.

Je ne vois pas l'intérêt d'une telle usine à gaz. L'application doit consulter et mettre à jour, au travers des vues, les tables métiers qui la concernent.
On ne crée pas de redondances dans une base de données, pas plus que des tables obèses.

Qui ressort gagnant d'une telle organisation ?

Absolument personne !

[fsmrel]

Bonjour,

Capitaine Escartefigue, chapeau ! Tu es un vrai DBA.

martinbrait, méditez chaque phrase, chaque mot de la réponse qui vous a été faite.

[martinbrait]

Bonjour Martinbrait
Une table d'une centaine de colonnes est très rarement une table bien modélisée. C'est une table obèse, source de bien des maux : redondances, incohérences, intégrité non vérifiée, accès concurrents dégradés, index pléthoriques, performances dégradées...

Merci de me réassurer sur les tables au nombre de colonnes interminables.
J'en ai moi-même horreur et je les pourchasse systématiquement dans mes petits projets de 20 tables,
réalisées avec des SGDB relationnels.

Les développeurs doivent avoir accès à toutes les tables dont ils ont besoin, idéalement au travers de vues (en principe, les traitements n'accèdent jamais directement aux tables, mais seulement à des vues).

Je me suis rendu compte que les vues construites à partir de plusieurs tables contenant des jointures, restreignent la 'lecture seule'.

Suis-je autorisé à créer une vue de plus d'une centaine de colonnes pour rassembler les données à modifier ?
Réaliser les interactions sur les données, en raison des jointures sous-jacentes, sont elles réalisables et recommandées sous postgres,
dans des vues à nombreuses jointures avec les droits en lecture seule sur les données.
En programmant des déclencheurs 'INSTEAD OF', je pourrais programmer une transaction pour actualiser les champs de toutes les
tables sous-jacentes. Est-ce malin ou inutilement compliqué ?

Est-il plus judicieux de créer systématiquement une vue par table (éventuellement étendue par quelques champs calculés) ?
Ainsi, je suis certain de bénéficier de l'accès à mes données en écriture/ajout/modification/suppression si je le souhaite.

Du coup, dois-je prévoir de créer 150 vues, en correspondance avec mes 150 tables (tables de référence et tables de mouvement)

Vu que la table du schema GESTION est très probablement une table obèse, n'exposer que cette table est une très mauvaise idée ...

Je me suradaptais avec cette table obèse unique, que le développeur a décider d'utiliser systématiquement.
J'ai conscience que cette table était un dépannage bancal, parce que la priorité du développeur était de :
se libérer de toute contrainte d'organisation des données, qui pourrait restreindre sa liberté dans la programmation des formulaires de l'IHM.
La contrainte du DBA était alors d'assurer en permanence la mise à jour d'une partie des champs de cette table obèse,
en programmant de multiples transactions SQL à partir de données des champs d'autres tables, vers les champs correspondant dans cette table obèse.
Mes données sont actualisées dans des tables courtes, respectant les formes normale MERISE;

Je suis curieux de savoir où vous avez lu un truc pareil ! Les développeurs doivent être formés aux bases relationnelles et au langage SQL. À partir de là, il faut leur donner accès à toutes les tables et colonnes (encore une fois via des vues) dont ils ont besoin.

Bien compris, MERCI !

Les noms techniques ne rebuteront pas les développeurs, puisque ce sont avant tout eux aussi des techniciens . De plus, les noms techniques ne devraient pas contenir de caractères spéciaux tels que le symbole #, ce n'est pas recommandé : ça ne présente aucun intérêt autre que de contraindre d'encadrer les noms par des délimiteurs.

Le # est toléré comme caractère spécial de multiples SGBD;
Dans mon cas, il me permettent de préfixer et/ou suffixer par un trigramme, le nom de la table contenant le champ,
afin de me faciliter certaines pratiques :
le noms du champ ne peuvent plus avoir de doublon lors de l'écriture d'une requête SQL (personnel.prs#nom et ville.vil#nom)
le nom du champ révèle immédiatement sa table d'appartenance, lorsque j'écris une longue requête SQL

Parler de sessions et d'enregistrements est inadéquat... Visiblement, on vous confie des taches de DBA sans vous en avoir donné la formation. C'est dommageable pour vous et pour les développeurs.

J'avais laissé les mots clefs sessions et enregistrements, à tort, en provenance d'un copier-coller de sujet internet, en sachant néanmoins qu'ils étaient hors sujet.
En fait, je m'étais trouvé une mauvaise excuse, par peur de n'être ni lu, ni compris.
Vais-je trouver mes mots et obtenir la moindre réponse pour m'aider à sortir de ma galère ?

Si des jointures sont fréquemment utilisées, le DBA peut créer des vues pour ces jointures

Est-il approprié de faire des vues multi-jointures, uniquement pour la réalisation des formulaires et états en lecture seule ?
Est-il courant et acceptable de faire des vues multi-jointures me limitant aux droits de lecture seule, et d'augmenter ces droits
par la réalisation de déclencheurs INSTEAD OF ?
Malin ? Fastidieux et non maintenable ?

Je ne vois pas l'intérêt d'une telle usine à gaz. L'application doit consulter et mettre à jour, au travers des vues, les tables métiers qui la concernent.
On ne crée pas de redondances dans une base de données, pas plus que des tables obèses.

Parfait !

[escartefigue]

Je me suis rendu compte que les vues construites à partir de plusieurs tables contenant des jointures, restreignent la 'lecture seule'.
Suis-je autorisé à créer une vue de plus d'une centaine de colonnes pour rassembler les données à modifier ?

Postgre limite en effet la mise à jour sur des vues qui ne concernent qu'une seule table. Ce n'est pas le cas avec tous les SGBD, DB2 par exemple permet des MàJ via des vues multi-tables.

En programmant des déclencheurs 'INSTEAD OF', je pourrais programmer une transaction pour actualiser les champs de toutes les
tables sous-jacentes. Est-ce malin ou inutilement compliqué ?

Tout d'abord, dans une base de données relationnelle, les champs n'existent pas. Le champ est une zone de saisie d'un formulaire ou une zone de restitution d'un état. Sans rapport avec les bases de données.
Ensuite, si c'est pour conserver votre idée d'une table fourre-tout modifiée par l'application et associée à un déclencheur qui met à jour les vraies tables métier, alors j'ai déjà expliqué en quoi c'était une très mauvaise idée.

Est-il plus judicieux de créer systématiquement une vue par table (éventuellement étendue par quelques champs calculés) ?
Ainsi, je suis certain de bénéficier de l'accès à mes données en écriture/ajout/modification/suppression si je le souhaite.

Oui : il faut créer une vue par table, avec éventuellement des colonnes calculées . Ce qui n'empêche évidemment pas de créer aussi des vues multi tables si nécessaire, par exemple pour des jointures récurrentes.

Je me suradaptais avec cette table obèse unique, que le développeur a décider d'utiliser systématiquement.
J'ai conscience que cette table était un dépannage bancal, parce que la priorité du développeur était de :
se libérer de toute contrainte d'organisation des données, qui pourrait restreindre sa liberté dans la programmation des formulaires de l'IHM.
La contrainte du DBA était alors d'assurer en permanence la mise à jour d'une partie des champs de cette table obèse,
en programmant de multiples transactions SQL à partir de données des champs d'autres tables, vers les champs correspondant dans cette table obèse.
Mes données sont actualisées dans des tables courtes, respectant les formes normale MERISE;

Merise est une méthode, les formes normales sont des règles de modélisation.
Ensuite, si des développeurs décident de ne pas s'embêter avec le typage des données, faut il pour autant mettre toutes les valeurs dans du char ? Non, évidemment.
Et si les développeurs décident de ne pas s'embêter avec la longueur des données, faut il mettre toutes les valeurs dans du varchar(max) ? Non plus.
Croyez-vous qu'on va construire des routes toutes droites pour les conducteurs qui détestent les virages ?
Donc, si les développeurs ne veulent pas s'embêter avec le modèle de données, tant pis pour eux, il faudra qu'ils s'y mettent ou qu'il changent de métier.
On ne modifie pas la structure des données en fonction des états d'âme des développeurs, la structuration des données est une conséquence directe des règles de gestion, et ça c'est incontournable.

Le # est toléré comme caractère spécial de multiples SGBD;
Dans mon cas, il me permettent de préfixer et/ou suffixer par un trigramme, le nom de la table contenant le champ, afin de me faciliter certaines pratiques :
le noms du champ ne peuvent plus avoir de doublon lors de l'écriture d'une requête SQL (personnel.prs#nom et ville.vil#nom)
le nom du champ révèle immédiatement sa table d'appartenance, lorsque j'écris une longue requête SQL

Il s'agit des noms de colonnes, et au lieu d'utiliser le #, il suffit d'utiliser le souligné ou underscore "_" et ainsi, plus besoin de s'embêter avec les délimiteurs SQL !
Pour ma part, quand la codification est libre (c'est rarement le cas en entreprise), j'utilise un préfixe distinct pour chaque type d'entité et chaque association du MCD qui devient une table.
Ce préfixe fait 2 ou 3 caractères selon le nombre d'objets, et je le sépare du nom par un souligné.

Voyez un exemple ICI.

[martinbrait]

Bonjour escartefigue,

Postgre limite en effet la mise à jour sur des vues qui ne concernent qu'une seule table. Ce n'est pas le cas avec tous les SGBD, DB2 par exemple permet des MàJ via des vues multi-tables.

OK

Tout d'abord, dans une base de données relationnelle, les champs n'existent pas. Le champ est une zone de saisie d'un formulaire ou une zone de restitution d'un état. Sans rapport avec les bases de données.

OK

Ensuite, si c'est pour conserver votre idée d'une table fourre-tout modifiée par l'application et associée à un déclencheur qui met à jour les vraies tables métier, alors j'ai déjà expliqué en quoi c'était une très mauvaise idée.

Je n'étais pas du tout fan de cette idée. Sans regard et conseil extérieur, je m'étais consciemment auto-contrains. J'ai déjà expérimenté et subi "à l'insu de mon plein gré", l'importation de données EXCEL (format imposé, recours à liaison odbc interdit). La feuille de classeur EXCEL présente le résultat d'une grande requête enregistrée fourre-tout de 156 colonnes aux noms de colonnes parfois doublonnés. Pire, il faut préalablement filtrer les colonnes utiles, et calculer les contenus des colonnes entre elles, avant d'importer les données. Bref intégrateur de données, depuis une présentation de données bancale, sans voie de recours.

Oui : il faut créer une vue par table, avec éventuellement des colonnes calculées .

OK. Une vue par table. Pour mon projet de 150 tables, créer 150 vues modifiables correspondantes.

Ce qui n'empêche évidemment pas de créer aussi des vues multi tables si nécessaire, par exemple pour des jointures récurrentes.

Du coup, sous postgres, cela se limite aux présentations de données en lecture seule dans des états, n'est-ce pas ?
Quant aux vues matérialisées, sont elles également exclusivement réservées à la lecture seule de données dans des états pour compenser des temps de calcul trop longs, du résultat de vues à centaines de milliers de lignes, en lecture seule, composées avec requêtes avec multi-jointures ?

Merise est une méthode, les formes normales sont des règles de modélisation.
Ensuite, si des développeurs décident de ne pas s'embêter avec le typage des données, faut il pour autant mettre toutes les valeurs dans du char ? Non, évidemment.
Et si les développeurs décident de ne pas s'embêter avec la longueur des données, faut il mettre toutes les valeurs dans du varchar(max) ? Non plus.
Croyez-vous qu'on va construire des routes toutes droites pour les conducteurs qui détestent les virages ?
Donc, si les développeurs ne veulent pas s'embêter avec le modèle de données, tant pis pour eux, il faudra qu'ils s'y mettent ou qu'il changent de métier.
On ne modifie pas la structure des données en fonction des états d'âme des développeurs, la structuration des données est une conséquence directe des règles de gestion, et ça c'est incontournable.

Bien compris.

Pour ma part, quand la codification est libre (c'est rarement le cas en entreprise), j'utilise un préfixe distinct pour chaque type d'entité et chaque association du MCD qui devient une table.
Ce préfixe fait 2 ou 3 caractères selon le nombre d'objets, et je le sépare du nom par un souligné.

Voyez un exemple ICI.

Par exemple, la table PRS_personne a des noms de colonnes préfixés et tronqués, facilitant la rédaction SQL du DBA.
'-----------
PRS_personne
'-----------
PRS_ident
PRS_nom
PRS_prenom
PRS_ddn

On y accèdera, grâce à la vue modifiable personne,
présentant aux développeurs et gestionnaires, les noms de tables et colonnes aliasées selon les attentes du métier.
'-----------
personne
'-----------
personne_id
nom
prenom
date_de_naissance

Est-ce correct ?

[escartefigue]

Du coup, sous postgres, cela se limite aux présentations de données en lecture seule dans des états, n'est-ce pas ?
Quant aux vues matérialisées, sont elles également exclusivement réservées à la lecture seule de données dans des états pour compenser des temps de calcul trop longs, du résultat de vues à centaines de milliers de lignes, en lecture seule, composées avec requêtes avec multi-jointures ?

Données en lecture seule oui, dans des états, mais aussi dans n'importe quel traitement, puisque, en principe, les développeurs ne devraient utiliser que des vues.

Par exemple, la table PRS_personne a des noms de colonnes préfixés et tronqués, facilitant la rédaction SQL du DBA.
'-----------
PRS_personne
'-----------
PRS_ident
PRS_nom
PRS_prenom
PRS_ddn

On y accèdera, grâce à la vue modifiable personne,
présentant aux développeurs et gestionnaires, les noms de tables et colonnes aliasées selon les attentes du métier.
'-----------
personne
'-----------
personne_id
nom
prenom
date_de_naissance

Est-ce correct ?

Les noms que j'ai proposés ne sont qu'une norme qui m'est propre en l'absence de norme locale dans l'entreprise.
Le plus souvent, en entreprise, il y a une norme de codification des objets (noms des tables, des colonnes, des vues, des index...), en tout cas chez les grands comptes chez lesquels j'interviens.
Je n'ai jamais vu les développeurs utiliser des noms différents, ils parlent la même langue que les DBA et autres techniciens, et c'est plus simple pour tout le monde.
Le gestionnaire n'accède ni aux tables ni aux vues, ni à aucun autre objet SQL, il ne voit que ce que les développeurs lui fournissent.
Donc si "nom de la personne" est plus parlant que "PRS_NOM", aucun problème, c'est ce libellé qui sera présenté sur les écrans, les états et autres endroits visibles par les gestionnaires.

[martinbrait]

Données en lecture seule oui, dans des états, mais aussi dans n'importe quel traitement, puisque, en principe, les développeurs ne devraient utiliser que des vues.

Bien compris.

Les noms que j'ai proposés ne sont qu'une norme qui m'est propre en l'absence de norme locale dans l'entreprise.
Le plus souvent, en entreprise, il y a une norme de codification des objets (noms des tables, des colonnes, des vues, des index...), en tout cas chez les grands comptes chez lesquels j'interviens.
Je n'ai jamais vu les développeurs utiliser des noms différents, ils parlent la même langue que les DBA et autres techniciens, et c'est plus simple pour tout le monde.

Le DBA est amené à connaître sur le bout des doigts les règles de gestion métier;
Le DBA est amené à rédiger fréquemment de nouvelles requêtes pour répondre aux besoins métiers qui évoluent;
Le DBA est amené à connaître sur le bout des doigts les noms aliasés (connus par les gestionnaires) des colonnes fréquemment demandées.

Le DBA apprend le nom TECHNIQUE d'une colonne, [prs_personne].[prs.nom] et son ALIAS [personne].[nom de la personne].
Il doit doubler son effort d'apprentissage pour un très grand nombre de colonnes.
Comment vous organisez-vous pour augmenter votre réactivité et diminuer votre charge de travail ?
Comment triez-vous les nouvelles demandes de requêtes des gestionnaires acceptables et celles qui ne le sont pas ?

Le gestionnaire n'accède ni aux tables ni aux vues, ni à aucun autre objet SQL, il ne voit que ce que les développeurs lui fournissent.
Donc si "nom de la personne" est plus parlant que "PRS_NOM", aucun problème, c'est ce libellé qui sera présenté sur les écrans, les états et autres endroits visibles par les gestionnaires.

Puisque "nom de la personne", comme nom de colonne de la table personne serait peu expressif pour le DBA,
est il approprié de lui laisser "PRS_personne"."PRS_nom" ?
est il approprié d'aliaser systématiquement "personne"."nom de la personne" dans la vue développeur/gestionnaire ?

Epargnons au développeur la peine d'inventer un troisième nommage pour libeller l'étiquette de nom du champ sur formulaire.
L'alias de nom de colonne de la vue étiquettera immédiatement le nom de champ du formulaire.

Séparer le nommage de l'univers des tables et le nommage de l'univers des vues est judicieux, n'est-ce-pas ?
J'ai été défié par les gestionnaires lors d'un changement de chef ou autre. Ils trouvaient intelligent, par exemple que le libellé "nom de la personne" soit modifié illico presto en "nom_usuel", et 6 mois plus tard demander une nouvelle modification en "nom_usage".

Il y a probablement moins de répercussions et effets de bord, à changer l'alias d'une colonne dans une vue,
que de changer le nom de la colonne PRS_nom, de la table PRS_personne.
"PRS_nom" est préservé durablement comme nom de colonne dans la table PRS_personne.

[escartefigue]

Dans les organisations que je pratique, le DBA n'est quasiment jamais en relation avec l'utilisateur final, mais avec les études informatiques, études informatiques qui elles sont en lien avec l'utilisateur final.

C'est donc aux études et non pas au DBA de traduire "nom de la personne" en "PRS_NOM" le cas échéant.

Ce n'est pas au DBA de connaitre les règles de gestion métier, c'est au concepteur de la base de données, celui qui établit le MCD.
Il peut arriver que celui qui établit ce MCD soit également un DBA, mais le plus souvent, c'est l'équipe études qui en a la charge, en collaboration étroite avec la maitrise d'ouvrage d'un coté et le DBA de l'autre.

Le DBA doit être consulté lors de cette étape pour vérifier que la modélisation conceptuelle ne s'engouffre pas dans des impasses techniques. Car, même si en théorie MCD et technique sont deux mondes étanches, dans les faits, il y a quelques exceptions. Par exemple, la façon de mettre en œuvre certaines contraintes ou le choix des identifiants n'est pas neutre. De même, lorsque la modélisation conceptuelle commence à prendre corps, il est recommandé de faire appel au DBA pour vérifier la robustesse de l'ensemble, notamment en prototypant les requêtes les plus significatives, pour vérifier qu'elles tiennent la charge.


Quant à savoir s'il faut un nom physique et un nom public différent, tout dépend du contexte, chez certains de mes clients, la maitrise d'ouvrage pratique sans difficulté les noms physiques et pour cause, il n'y a que ceux là
Chez l'un de mes clients, toutes les colonnes sont codées sur 6 caractères seulement (!). C'est peu parlant, mais le dictionnaire de données est disponible et bien documenté, du coup personne n'en prend ombrage.

[martinbrait]

Je prends bien note des préconisations d'organisation :
importance du rôle du bureau d'études.

Merci infiniment pour vos réponses de grande qualité,
et le temps que vous m'avez accordé.

[SQLpro]

On ne modifie pas la structure des données en fonction des états d'âme des développeurs, la structuration des données est une conséquence directe des règles de gestion, et ça c'est incontournable.

et de la nature intrinsèque des données.... par exemple une adresse ip V4 c'est un entier 32 bits, un GUID ou UUID c'est un binaire 128 bits (PostGreSQL en cette matière est particulièrement mauvais puisqu'il met cela dans de la chaine de caractères de 36 octets, soit => 4,5 fois plus !), un code postal ne dépasse pas 10 caractères... Etc. En dimensionnant n'importe comment vous allez plomber les ressources, rendre les requêtes contre performantes et diminuer la concurrence (plus de mémoire pour executer chaque requête = moins d'utilisateur en parallèle...) D'autant que sur ce dernier point PostGreSQL est aussi mauvais vu son modèle base sur des process et non des threads....

[CinePhil]

Bonjour Martinbrait.

Puisque le premier message m'était directement adressé, je me sens un peu obligé de répondre, bien que (presque) tout ait déjà été dit.
s ta
Es-tu maître du modèle de données ou dois-tu faire avec l'existant sans y toucher ?

J'ose espérer que tu es le maître à bord au sujet des données parce que ce que tu présentes est quelque peu effrayant !

Donc...

1) Oui, pour l'accès aux données en lecture, privilégie les vues.
Ne pas en avoir peur, même pour des vues multi-tables, la jointure est l'opération la plus optimisée d'un SGBD

Et 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 donénes des deux tables associées via la table associative mais pas de vue spécifique pour la table associative.

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

3) 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)."


À partir de là, si tu réussis à faire accepter ces principes, on peut t'aider à modéliser ton usine à gaz correctement. Pour t'aider sur les vues et procédures, ce sera plutôt côté forum Langage SQL et/ou PostgreSQL.

Bon courage !

[SQLpro]

...
Quant aux vues matérialisées, sont elles également exclusivement réservées à la lecture seule de données dans des états pour compenser des temps de calcul trop longs, du résultat de vues à centaines de milliers de lignes, en lecture seule, composées avec requêtes avec multi-jointures ?

ATTENTON : les vues matérialisées de PostGreSQL nécessite un rafraichissement (c'est à dire un recalcul global des données), là ou Oracle permet parfois un recalcul différentiel et ou SQL Server présente des vues toujours synchones (pas de rafraichissement possible puisque toujours à jour).
Autrement dit, les vues matérialisées de PostGreSQL ne servent pas à grand chose....

Quelques éléments sur la comparaison PG SQL Server :
http://mssqlserver.fr/postgresql-vs-...ed-comparison/
http://mssqlserver.fr/postgresql-vs-...s-pour-le-dba/
http://mssqlserver.fr/postgresql-vs-...es-avec-count/

A +