Commentaires

Envoyé par Artemus24

Dans les grands comptes du domaine bancaire, je n'ai jamais vu des VIEW sous DB2 autrement que sur des questions de sécurités.
La plupart du temps, les accès aux bases de données se font en lecture uniquement.
Les mises à jour se font par des voies non applicatives comme par exemple un batch durant la nuit, ou des accès via des DAB ...

Dans la mini et micro informatique, vous avez plus de liberté que nous en gros système, et donc tu ne peux pas généraliser ainsi.

J'ai fait de nombreuses mission pour de grandes banques françaises et aussi chez certains de leurs fournisseurs, et je ne confirme nullement ces propos !

• je n'ai jamais vu la sécurité gérée au travers de VIEW dans les banques dans lesquelles je suis intervenu, ni même au travers des grant DB2
  La sécurité est le plus souvent gérée par RACF ou TSS d'une part, et par des habilitations applicatives d'autre part
• j'ai rencontré quelques cas de vue de type jointure mais aussi et surtout des vues servant à versionner les modifications des tables afin de ne pas impacter les traitements lors des évolutions faites sur les tables
• quand aux accès aux bases de données en lecture seulement, je ne sais pas dans quelle banque vous êtes intervenus, mais ça non plus ne correspond en rien à ce que j'ai connu par le passé ou que je connais actuellement dans les grandes banques françaises.

D'ailleurs, que ce soit dans le monde bancaire, ou dans les autres corps de métier où je suis intervenu (industrie, assurance et retraite), je n'ai encore jamais vu de plate-forme mainframe (jadis OS/370 puis OS/390 et aujourd'hui Z/OS) qui gère la sécurité au travers de view.
Mais toujours une sécurité de 1er niveau via RACF ou TSS, puis des sécurités gérées dans les applications elles mêmes.

Salut iberserk.

Envoyé par iberserk

Je vais (pour une fois?) prendre la défense de StringBuilder

Si je me permets de répondre à StringBuilder au sujet de "Remodéliser votre base de données", ce n'est pas pour le discréditer, tout au contraire.
J'ai déjà échangé avec lui, et je l'apprécie grandement ! Mais nous n'avons pas tous la même expérience professionnelle, d'autant que je viens du monde du gros système où les contraintes sont plus importantes.

Envoyé par iberserk

Je ne suis absolument pas d'accord avec toi Artemus

C'est ton droit. Ce blog est un droit de réponse, alors exprimons-nous, mais avec courtoisie.

Envoyé par iberserk

Je ne vois pas le rapport avec le problème que soulève ici Stringbuilder?

C'est juste une idée que j'expose suite à ce qu'il dit ici :

Envoyé par StringBuilder

Le problème, c'est que de nombreux outils accèdent souvent à cette base de données ...

J'ai travaillé sur un 'data warehouse' (=DW) dans le cadre de la 'BAFI'.
Pour réaliser ce travail, je devais récolter les données, les agréger et ensuite les stocker dans le DW.
Ce qu'expose StringBuilder m'a rappelé le travaille que j'avais fait. Ce travail consistait à créer une interface de conversion. N'est-ce pas l'idée de ce sujet ?

Envoyé par iberserk

un datawarehouse est en générale utilisée dans un cadre analytique, avec de l'agrégation de données, et en général plutôt en lecture seule.

Oui, c'est tout à fait exacte. Mais toutes les bases de données ne sont pas destinés à des applications tournées vers les utilisateurs.
Il y en a où l'on fait uniquement des statistiques pour des organismes demandeurs de ce genre de résultat.
Extraire et triturer des données, on peut le faire soit dans le cadre d'une migration de données, soit en tant qu'interface.

Envoyé par iberserk

C'est donc complètement hors sujet pour moi...

Dans le sens stricto sensus du sujet, oui, je veux bien, mais pas dans l'idée qu'expose StringBuilder, celle de créer une interface.

Envoyé par iberserk

on peut toujours se poser la question de l'utilité d'une colonne à 95% NULL.

De ce point de vue (celui des 95%), je suis d'accord avec toi. Mais je n'ai pas compris cela de cette façon. Quand je lis les propos de StringBuilder :

Envoyé par StringBuilder

Et la présence de NULL dans une table, c'est la preuve d'une modélisation hasardeuse.

Je comprends que l'usage des NULL dans une table est la cause d'une mauvaise modélisation.
Avoir quelques valeurs à NULL, n'est pas une raison valable pour remettre en cause la modélisation.

Mais comme je le souligne, c'est le nom respect de la première forme normale qui est en cause, et non les NULL.
Donc sa remarque est juste une façon de montrer que le modèle choisi n'est pas adapté à ce que l'on cherche à faire.

Envoyé par iberserk

Si vous trouvez qu'un INSTEAD OFF TRIGGER est une usine à gaz, vous n'avez pas du faire beaucoup de SQL poussé dans votre vie!

Vous n'avez pas compris mon point de vue. Créer une interface comme le fait StringBuilder est une façon de pénaliser les performances.
Une vue, ce n'est pas une table temporaire déjà existante, mais bien un traitement qui va extraire les données à partir de la requête contenue dans le VIEW, et cela à un cout.

Envoyé par View DB2

A view is represented internally to DB2 by SQL statements, not by stored data

C'est comme si vous faisiez dans un select, un sous-select. Et chacun sait, que ce genre de requête est d'une performance dégradée.

Quand on se retrouve avec des milliards de lignes en ligne, les questions de performances sont cruciaux.
J'ai travaillé sur la numérisation des images chèques, et quand chaque jour quelques millions de chèques sont produits dans une banque internationale, je peux vous assurer que faire une recherche sur 10 ans, ce n'est pas anodin.
Je pense que vous sous-estimez la question de la performance ! Et pour votre gouverne, j'étais administrateur DB2.
Il y a encore quelques temps, il était interdit de faire l'usage des procédures, triggers, functions et events. Et à votre avis pourquoi ?

Il y a une énorme différence entre un serveur Mysql où 50 personnes au maximum viennent consulter une base de données, et là, je suis d'accord avec vous. Avec une base DB2 ou plusieurs milliers de personnes dans le monde viennent faire des opérations (je parle des utilisateurs et non des clients).

Envoyé par iberserk

et la cohérence des données

On ne parle pas de cohérence, mais d'intégrité des données.
Ceci est géré par le mode transactionnel qui est connu dans DB2 depuis fort longtemps, à l'inverse de MySql.
Cela se gère au niveau application, par l'intermédiaire du RollBack et du Commit, en faisant en sorte de rejeter ou valider une grappe de données.

Envoyé par iberserk

De plus j'ai le sentiment que vous ne voyez que les performances en lectures...

Oui, vous avez raison car là où je travaillais, c'était la raison même d'être administrateur.
Mais ce n'est pas pour autant que j'ai délaissé l'intégrité des données.
Je ne sais pas chez vous, mais là où je travaillais, les développeurs passaient par des contrôles de qualités avant de livrer leur travail.
Et ensuite, nous devions soumettre nos applications à une chaîne de tests assez contraignante, avant la mise en production définitive.

Envoyé par iberserk

la principale est de masquer la complexité/propreté d'une modélisation.

Dans les grands comptes du domaine bancaire, je n'ai jamais vu des VIEW sous DB2 autrement que sur des questions de sécurités.
La plupart du temps, les accès aux bases de données se font en lecture uniquement.
Les mises à jour se font par des voies non applicatives comme par exemple un batch durant la nuit, ou des accès via des DAB ...

Dans la mini et micro informatique, vous avez plus de liberté que nous en gros système, et donc tu ne peux pas généraliser ainsi.

@+

Je vais (pour une fois?) prendre la défense de StringBuilder
Je ne suis absolument pas daccord avec toi Artemus

Envoyé par Artemus24

Salut StringBuiler

Bon travailStringBuilder , mais j'ai quand même quelques remarques à faire !


Pourquoi tout réécrire ?
Une solution consiste à extraire les valeurs dont on a besoin dans une nouvelle base de données afin de les exploiter au mieux.
Ce genre d'outil se nomme un entrepot de données (en anglais 'data warehouse').
@+

Je ne vois pas le rapport avec le problème que soulève ici Stringbuilder? un datawarehouse est en générale utilisée dans un cadre analytique, avec de l'aggregation de données, et en général plutôt en lecture seule.
C'est donc complètement hors sujet pour moi...

Envoyé par Artemus24

Un 'null' exprime l'absence de valeur pour une colonne donnée.
Son usage n'est pas une aberration comme tu sembles le souligner, mais cela à son utilité.
Il ne faut pas confondre l'absence de valeur avec une valeur renseignée qui est soit à zéro ou soit à blanc.

Ce n'est pas le NULL qui pose problème mais la redondance des colonnes de même type comme dans ton exemple avec les numéros de téléphones.
C'est la première forme normale qui est enfreinte.
Voici la définition de cette forme issue du livre "SQL et DB2, le relationnel et sa pratique" de M. Koutchouk :

De ce fait, cette table n'est pas normalisée correctement, d'où le problème que l'on rencontre par la suite.

J'abonde sur le fait que le problème viennent de la modélisation mais on peut toujours se poser la question de l'utilité d'une colonne à 95% NULL et donc de la possibilité de faire un découpage horizontal de la table sur un ensemble de colonnes (informations sécu par exemple) qui sont en générales soi toutes présentes soit aucune.

Une colonne NULL induit souvent des traitement particulier pour le prendre (ou pas) en compte.

Envoyé par Artemus24

Le problème de ton exemple est que tu transformes une usine à gaz en une autre usine à gaz.
La question des triggers peut grandement pénaliser la performance du traitement des mises à jour de ta base de données transformées.
Si les mises à jour sont peu nombreuses, oui, en effet cela peut être une solution.
Mais en procédant ainsi tu vas créer un Goulot d'étranglement qui peut nuire à la performance.

Si vous trouvez qu'un INSTEAD OFF TRIGGER est une usine à gaz, vous n'avez pas du faire beaucoup de SQL poussé dans votre vie!
De plus un trigger si bien codé ne pénalise pas la performance, il fait de plus partie intégrante de la transaction : idées reçu que tous cela, je suis d'ailleurs en train de faire faire un retour en arrière sur ces idées préconçues dans la société dans laquelle j'interviens en ce moment.

Envoyé par Artemus24

La question fondamentale reste la performance.
Une table qui n'est pas normalisée, ou devrais-je dire dénormalisée, est peut-être la réponse à cette question fondamentale.
Donc une mauvaise modélisation n'est pas nécessairement un handicap.

La performance... et la cohérence des données
De plus j'ai le sentiment que vous ne voyez que les performances en lectures...

Envoyé par Artemus24

L'exemple que tu donnes est juste une façon d'illustrer l'usage des view.
Oui mais tu fais un usage à contre emploi de ce qu'il faut faire.

Les view sont destinées à créer des sous-ensembles de données à partir d'une table unique.
On le fait dans le respect de la mise en place de la sécurité au niveau d'une entreprise.
L'exemple des données comptables est soumise à des restrictions selon les services qui ont accès à ces données.

Ce n'est qu'une facon d'utiliser les vues, il y en à bien d'autre! dont la principale est de masquer la complexité/propreté d'une modélisation.
Très important par les temps qui court avec ces fichus ORM que nos développeurs aiment tant mais dont il ne comprenne rien!

Cordialement

De mon coté je préconise l'utilisation de procédures stockées pour la BDD, interdiction de faire autrement; si bien que toute la structure table peut être changée sans modification des applis... ça me parait plus simple, plus pérenne et sécurisé en plus.

Méfiance sur l'utilisation des triggers : comme dit précédemment, pas top pour les perf, il ne faut pas se planter dans ces triggers sinon rien n'arrive dans les tables et en cas de problème ou modif de schéma on ne pense plus trop au trigger...

Salut StringBuiler

Bon travailStringBuilder , mais j'ai quand même quelques remarques à faire !

Envoyé par stringBuiler

Le problème, c'est que de nombreux outils accèdent souvent à cette base de données, et qu'il vous semble insurmontable de devoir tout réécrire afin de réagencer quelques tables dans votre base.

Pourquoi tout réécrire ?
Une solution consiste à extraire les valeurs dont on a besoin dans une nouvelle base de données afin de les exploiter au mieux.
Ce genre d'outil se nomme un entrepot de données (en anglais 'data warehouse').

Envoyé par stringBuiler

Et la présence de NULL dans une table, c'est la preuve d'une modélisation hasardeuse.

Un 'null' exprime l'absence de valeur pour une colonne donnée.
Son usage n'est pas une aberration comme tu sembles le souligner, mais cela à son utilité.
Il ne faut pas confondre l'absence de valeur avec une valeur renseignée qui est soit à zéro ou soit à blanc.

Ce n'est pas le NULL qui pose problème mais la redondance des colonnes de même type comme dans ton exemple avec les numéros de téléphones.
C'est la première forme normale qui est enfreinte.
Voici la définition de cette forme issue du livre "SQL et DB2, le relationnel et sa pratique" de M. Koutchouk :

On dit qu'une table est en première forme normale quand elle possède uniquement des données élémentaires pour chaque colonne dans chaque ligne (pas de données répétitives).

De ce fait, cette table n'est pas normalisée correctement, d'où le problème que l'on rencontre par la suite.

Envoyé par stringBuiler

Vous pouvez rendre votre base de données propre et performante, en la remodélisant.

Le problème de ton exemple est que tu transformes une usine à gaz en une autre usine à gaz.
La question des triggers peut grandement pénaliser la performance du traitement des mises à jour de ta base de données transformées.
Si les mises à jour sont peu nombreuses, oui, en effet cela peut être une solution.
Mais en procédant ainsi tu vas créer un Goulot d'étranglement qui peut nuire à la performance.

La question fondamentale reste la performance.
Une table qui n'est pas normalisée, ou devrais-je dire dénormalisée, est peut-être la réponse à cette question fondamentale.
Donc une mauvaise modélisation n'est pas nécessairement un handicap.

Envoyé par stringBuiler

de faire des vues

L'exemple que tu donnes est juste une façon d'illustrer l'usage des view.
Oui mais tu fais un usage à contre emploi de ce qu'il faut faire.

Les view sont destinées à créer des sous-ensembles de données à partir d'une table unique.
On le fait dans le respect de la mise en place de la sécurité au niveau d'une entreprise.
L'exemple des données comptables est soumise à des restrictions selon les services qui ont accès à ces données.

Mais à ma connaissance, je ne connais aucun exemples rencontrés en gros système (donc en DB2) faisant un usage comme tu le fais des view.
Vous avez certainement plus de liberté pour entreprendre vos modélisations qu'en gros système sur des grands comptes.
Quand je faisais du développement, nous étions soumis à des contrôles de qualités avant les livraisons de nos programmes.
Et si nous ne respections pas les normes de l'entreprise, nous devions réécrire nos programmes.

@+