Discussion :

[B.AF]

Salut,

Voilà. J'ai découvert hier encore un de ces systèmes où on va taper dans 6 ou 7 bases différentes, de fournisseurs différents, faites de façon différente.

Qu'est ce que j'ai essayé de faire ? Un domaine d'objets 'métier' basé sur ces données, afin de les extraire avec des règle métier strictes et de pouvoir éventuellement les centraliser différemment.

Dans la théorie, c'est bien. C'est un bon sujet pour un ORM, des services...Mais....

Certains doivent savoir que si un sujet me touche vite dans les applis actuelles, c'est souvent que lorsqu'elles sont connectées à une base via un ORM quelconque, c'est vite du grand nawak avec de la génération de code spaghetti que je déteste.

Et voilà pourquoi :
Sur toutes les bases, 70% des tables disposent d'une clef primaire; 35% des tables contenant des données basées sur des dates contiennent des index et des tris sur les dates. 0% des relations sont matérialisées, il n'y a aucune intégrité.
La plupart des plans d'exécution des requêtes aboutissent à un scan des tables.

Et là j'ai compris. J'ai compris pourquoi SQLPro était si perplexe face à certaines technologie. J'ai compris que ce qui semble normal (des règles et une connaissance fondamentale des règles de gestion des données) n'était pas acquis pour tous, et que les "on ne fait pas de relation parce que c'est compliqué pour faire des mises à jour" était fait dans l'approbation béate collective.

Je dis SQLPro parce que souvent dans les débats sur les ORM, j'ai trouvé sa réserve quasi radicale et aveugle. Mais là je dois avouer que je l'ai dit : avant d'utiliser un ORM ou des ORM, assurez-vous de comprendre ce qu'est une base de données relationnelle et de comprendre la norme SQL.
J'me suis encore fait des potes :-)

SQLPro, à jamais tu seras le Yoda du SGBD.

[Erwy]

Et voilà pourquoi :
Sur toutes les bases, 70% des tables disposent d'une clef primaire; 35% des tables contenant des données basées sur des dates contiennent des index et des tris sur les dates. 0% des relations sont matérialisées, il n'y a aucune intégrité.
La plupart des plans d'exécution des requêtes aboutissent à un scan des tables.

Il y a quelques années, alors que moi-même je ne travaillais que depuis peu de temps avec des bases de données, un collègue vient nous voir parce que la base qu'ils développent à des accès catastrophique en lecture.
On lui pose la première question "de base", "est-ce que tu as vérifié que tes indexs sont bien fait" réponse : "c'est quoi un index ?" , quelques années après j'ai dut utiliser cette fameuse base, je vous laisse imaginer à quel point elle était bien conçue mais le pire c'est que si sur le plan technique c'était léger, c'était aussi le cas sur le plan fonctionnel...

Autre "gag", l'année dernière je discute avec un jeune collègue, sortant quasiment de l'école, de ce que doit contenir la base et de ce qui lui doit être extérieur (en particulier sur les contraintes d'intégrité), à un moment de la conversation "mais de toute façon pourquoi ne pas mettre toute les contraintes en JAVA ou autres puisqu'il est impossible d'accéder aux données sans passer par un langage de ce type ...hein?"
Quand je vois que cette personne est plus diplomé que moi, je reconnais que j'ai eu un moment de solitude...

[el_slapper]

Le souci des bons outils, ce sont les mauvais ouvriers.....

j'ai vu un compte-rendu mensuel, qui allait chercher dans toute la base des infos, qui faisait un résultat de 7 colonnes sur 15 lignes, codé en une seule requête SQL par le stagiaire.

Ah, ça marchait. Du feu de Dieu. Puis, la base a grossi, et c'est devenu de plus en plus lent. Puis ça a dépassé les 30 secondes de time-out. Et personne n'a été foutu de s'attaquer à ce monstre. Et surtout pas moi. Je suis parti, je ne sais pas ce que c'est devenu, mais ce time-out empechait le gestionnaire de travailler.

[souviron34]

Salut,

Voilà. J'ai découvert hier encore un de ces systèmes où on va taper dans 6 ou 7 bases différentes, de fournisseurs différents, faites de façon différente.

Qu'est ce que j'ai essayé de faire ? Un domaine d'objets 'métier' basé sur ces données, afin de les extraire avec des règle métier strictes et de pouvoir éventuellement les centraliser différemment.

Salut

Longtemps que je ne t'avais pas lu

Je l'ai déjà mentionné ailleurs, mais j'avais eu le même problème de fond (et même encore plus large, je pense) en météo :

quasiment chaque type de donnée (pas tout à fait, mais pas loin) avait sa base et son moteur, et suivant les pays les bases et les moteurs ne sont pas les mêmes..

La solution (française, bien entendu ) avait été bien évidemment de tout centraliser dans une grosse base Oracle....

D'autres avaient des solutions différentes, mais en gros c'était le gros foutoir...


Outre le coût prohibitif d'une licence Oracle, et vu que les formats pouvaient changer (style bulletins aériens), nécessitant une mise à jour du moteur, le département info du service météo pour lequel je travaillais avait le syle "foutoir" et réfléchissait à prendre la solution française...

Comme on était du début du Net, j'avais été frappé de l'élégance de l'architecture sous-jacente du Web..


Et j'avais (nous avions, à 8 d'origines diverses) donc conçu un petit protocole permettant de décrire simplement toutes les données et leurs types...

Et du coup j'avais dérivé une architecture en grappe, où une appli ne manipulait que des types "génériques", décrits en ASCII par le protocole, et s'adressait à un serveur générique, qui lui avait des sous-serveurs qui eux connaissaient leurs bases et moteurs.. Ce qui permettait d'avoir autant de formats et de moteurs qu'on souhaitait sans changer quoique ce soit ni à l'application ni au principe des serveurs, et permettait une modification d'une table ou d'un moteur local sans changer quoi que coit pour tout le réseau...

Finalement ce protocole (et l'appli et la strucure interne des serveurs) ne manipulait strictement que des données "virtuelles", modélisées non en fonction de la donnée mais simplement du type générique spatial (0D (ponctuelle : une mesure, une photo)), 1D (un vecteur), 2D (un plan, une image), 3D (un volume)).

Donc même pas des données "métier", mais un niveau d'abstraction encore au-dessus... : une "température" ou un "vent" ou une "humidité" sont la même chose, même si du point de vue "métier" c'est différent : si c'est une observation d'une station au sol par exemple c'est un point de mesure. Si c'est la mesure d'un ballon-sonde c'est un vecteur. Si c'est une image satellite c'est un plan, car elle est géo-référencée. Si c'est extrait d'un modèle numérique, ça peut être un point, un vecteur (au dessus de telle lat/lon par exemple), un plan (à 950 mb par exemple) ou un volume (l'ensemble du modèle ou une sous-partie).

Ceci permettait simultanément de

• s'affranchir des moteurs différents (responsabilité purement locale du serveur spécialisé pour s'attaquer à cette base en particulier),
• s'affranchir des problèmes de maintenance (la modification d'une base n'entraîne que la modification du serveur local) ,
• s'affranchir de la définition même des données (fournie en ASCII par le protocole),
• permettre d'avoir plusieurs types / sources/ bases pour la même donnée métier (mon exemple de la température plus haut),
• d'avoir une structure de développement hypersimple : toute nouvelle base ou nouvelle donnée ne nécessitait l'écriture que de 5 fonctions à partir d'un canevas commun : fournir les infos descriptives du type de la donnée, savoir se positionner dans la base, savoir fournir les infos d'une donnée en particulier, savoir fournir la donnée elle-même, et savoir écrire une donnée.

J'ai toujours été extrêmement réticent autant envers les BDR (des tables vers des tables vers des tables.) qu'envers une centralisation extrême..


Donc je te comprends

[B.AF]

Le truc là, c'est que quoi que je fasse, j'ai un risque d'explosion tel dans les bases, que le mieux, c'est quasiment de ne rien faire et d'attendre l'explosion..

[_skip]

Salut B.AF!

Et voilà pourquoi :
Sur toutes les bases, 70% des tables disposent d'une clef primaire; 35% des tables contenant des données basées sur des dates contiennent des index et des tris sur les dates. 0% des relations sont matérialisées, il n'y a aucune intégrité.
La plupart des plans d'exécution des requêtes aboutissent à un scan des tables.

C'est un problème récurrent, j'ai dernièrement été visité un client qui a conçu et exploite avec succès une grande chaîne de vente en ligne. J'ai eu accès à son schéma de données : idem, aucune contrainte d'intégrité, des tables gérant dans *la même colonne* des relations entre des tables différentes avec un ID qui indique plus ou moins vers quelle table le contenu de la colonne est censé pointer etc...

En gros, une telle merde que je suis sorti de là-bas j'étais blanc. Pourtant ben ça fonctionne, c'est tout pourri, pas performant, inmaintenable mais ça fonctionne.... En fait on est surpris quand on voit ce que des gros logiciels ont parfois sous le capot, et on peut être surpris en mal bien souvent.

Je dis SQLPro parce que souvent dans les débats sur les ORM, j'ai trouvé sa réserve quasi radicale et aveugle. Mais là je dois avouer que je l'ai dit : avant d'utiliser un ORM ou des ORM, assurez-vous de comprendre ce qu'est une base de données relationnelle et de comprendre la norme SQL.
J'me suis encore fait des potes :-)

Les positions de SQLPro ne sont pas toutes défendables, à ce titre, il a inclut iBatis dans son article sur les ORM en lui prêtant les mêmes défaut qu'hibernate alors que ces outils ont juste rien à voir et ne sont pas comparables. Avant d'affirmer qu'un outil est un mal absolu, ça aurait quand même été pas mal de connaître ce qu'il fait réellement (cad, réduire le code nécessaire à l'utilisation de SQL via JDBC sans aucune magie noire ni perte de maîtrise sur les échanges SGBD).

Ce que j'ai toujours apprécié dans IBatis, c'est qu'il se contente de simplifier JDBC. En cela, il ne cherche aucunement à "cacher" le fait que tu bosses avec sur du relationnel et qu'au final ce sera du SQL pur qui assurera la communication avec ton SGBD. Le tout objet c'est bien sympa, mais perso j'ai toujours trouvé que chercher une trop forte abstraction du système de stockage était une erreur.
Donc je fais partie de ceux qui conçoive leur modèle de données en fonction des extractions nécessaires et jamais je ne laisserai un ORM décider de comment doivent être organisées mes tables, j'écris et j'optimise moi-même les requêtes SQL que mon application utilisera. C'est un procédé plus lent, mais au moins je sais ce que je brasse et j'ai une grande liberté d'optimisation.

Mais c'est une tendance générale de nos jours d'utiliser tout ce qui peut nous faire coder moins et plus vite. Mais parfois la perte de maîtrise qui résulte de l'utilisation de frameworks qui font de la magie vaudoue ça se paie cher.

[OButterlin]

Il n'y a pas UNE techno absolue.
Toutes ont un domaine de prédilection et des contraintes.

Dire que telle techno est géniale et toutes les autres sont des bouses ne démontre (à priori) que l'étroitesse d'esprit de celui qui l'avance (special thanks SQLPro dont la vision est plus proche de l'intégrisme que de la raison).

Ceci dit, l'ORM n'est pas LA panacée, loin s'en faut...
J'en suis arrivé à utiliser l'ORM pour la persistance "métier", avec des graphes d'objets limités et toutes les requêtes de sélection par du code sql natif (c'est surtout là qu'on a besoin d'optimiser).

[bokan]

Je ne vais pas me faire des amis là mais j'ai une question :
Quel est l'impact de créer des relations sur les performances ?

Ok ça consolide la base, ça évite les erreurs d'intégrité révérencielle et ça permet de détecter et réparer certains problèmes.

En contrepartie ça a de gros inconvénients sur les très grosses applications.

• Ça rajoute une couche à chaque insertion. Si j'ai un utilisateur qui se logue dans le système, je connais son ID. Si je rajoute un enregistrement lié à cet utilisateur dans la table "messages" je transmet l'ID dans ma requête, quel intérêt que le serveur SQL vérifie à nouveau que l'ID existe bien de son coté ? (Vous allez me dire qu'un admin peut avoir supprimé cet utilisateur de la base après qu'il se soit logué, mais dans cas le système est mal conçu si il laisse l'utilisateur connecté).
• Ça pose de gros problèmes d'administration quand on doit diviser la base sur plusieurs serveurs SQL pour répartir la charge. Beaucoup de systèmes d'aujourd'hui sont multi-entreprises. On a un gros service online qui est accédé par plusieurs entreprises. Il n'y a aucune relation entre les objets d'une entreprise et les objets d'une autre entreprise. Seule les tables de gestion du système (users, facturation...) contiennent des données concernant toutes les entreprises. Il est bien plus efficace de répartir les données sur plusieurs petits serveurs que de tout mettre sur un monstre.

Quand on ce type de service à mettre en place et qu'on doit pouvoir monter en charge rapidement, il faut faire tout ce qu'on peut pour mâcher le travail aux serveurs SQL, moins ils en font, plus il peuvent encaisser. Il est très simple de rajouter des serveurs web en frontal et répartir la charge. Il est très complexe monter la puissance des serveurs SQL au delà d'un certain point ou de scinder une base relationnelle sur plusieurs serveurs.

Vous allez me dire que ce n'est plus des bases de données relationnelles. Vous avez raison, dans les très grosses appli web on se sert des serveurs SQL comme de simples unités de stockage de petit paquets de données. On devrait passer sur du NOSQL dans la plupart des cas. Mais le problème c'est qu'on a des dev qui ne savent pas gérer ces technos et qui ont l'habitude du SQL, et on peut avoir des serveurs suffisamment puissants pour encaisser des montagnes de requêtes (à condition de leur mâcher le boulot). C'est le choix que font bien des architectes.

---

Pour les système mono-entreprise PME. Je souscrit à 100% une vraie base de donnée doit être correctement indexée et les relations codées en dur. Je vois mal quel CRM peut saturer un serveur d'aujourd'hui.
Mais pour tout les cas particuliers avec de grosses quantités de données spécifiques, il faut développer des systèmes adaptés. C'est souvent beaucoup plus simple qu'il n'y paraît et redoutablement efficace.


Récemment j'ai bossé pour une boite qui propose un service de géolocalisation de véhicules. Ils ont commencé en 1998 avec une base de donnée installé chez chaque client. Les véhicules envoyaient des SMS pour donner leur position. Ils envoyaient entre 5 et dix messages par jour. Le tout stocké dans une table sans optimisation des données. Latitude et longitude stockées dans 3 int chacun pour degrés minutes et secondes, super pratique quand on veut sortir tout les champs à moins de 100km d'un point.
Puis ils sont passé en service en ligne et ont regroupé toutes les bases de leur client en une seule.
Puis le GPRS est arrivé et les véhicules envoient une position toutes les 1 à 3 min.
Ils n'ont rien changé à la structure de la base.
La table des positions pèse près de 60 Go, les requêtes rament comme pas possible et le système est impossible à maintenir. Pourtant c'est du SQL bien indexé avec une bonne intégrité référentielle.
Je leur ai proposé d'optimiser tout ça (je pouvais réduire à deux tables de 2Go). Ils m'ont dit on ne touche rien avant un an. Je suis parti, pas envie de galérer avec eux à résoudre les problèmes insolvables qu'ils se créent.