Discussion :

[pseudocode]

On obtient ainsi :
- des schema de base de données qui sont conçus uniquement par des schéma UML et qui change au gré des évolution de ceux-ci (ce qui fait en effet que personne d'autre que leur application ne peut utiliser leur BDD à part au travers de Web Service qu'ils mettent des mois à fournir et je ne parle pas des pb de maintenances)...
- Des schemas sans aucune contrainte sur les données tout étant au niveau du "framework" d'accès ,puisqu'on n'écrira jamais dans la BDD sans passer par l'application...ce qui bien sûr est faux puisqu'il y a régulièrement des modifications massives à effectuer qui passe par du SQL ,sans aucune sécurité donc(et ils ont déjà réussi à corrompre leurs données avec ça... )
- une absence totale d'optimisation : genre "C'est quoi un index?"(non,non je ne blague pas malheureusement ) avec des requêtes de lectures qui font planter la base ...
- une méconnaissance totale du fonctionnement d'un SGBD moderne, j'ai appris récemment à un de mes jeunes collègues qu'en utilisant des outils comme SQL Loader on pouvait charger des fichiers de données sans passer par une "application" type JAVA, .NET ou autres...

Tout ca vient du fait que le SGBD est utilisé pour faire la persistance des données d'un logiciel. Dans ce cas, coder un schéma de BdD n'est pas une finalité en soi mais juste une nécessité technique. On comprend donc que le développeur d'appli ne soit pas particulièrement intéressé a respecter (encore moins comprendre) les règles d'utilisation d'un SGBD.

Autant je comprends les DBAs qui poussent de grand cris face aux implémentations des développeurs... autant ces memes DBAs doivent bien reconnaitre que les SGBD ne sont pas véritablement en phase avec les problématiques de développement de 2010 : répartition des donnés, multi-threading, orienté-objet, versioning, extensibilité, ...

Je ne sais pas si la solution viendra des SGBD, du NoSQL ou des langages de programmations, mais il y a des problèmes à prendre en compte et l'excuse du "YOU'RE DOING IT WRONG" ne peut pas marcher à tous les coups.

[B.AF]

C'est tout à fait ce que j'ai écrit dans mon article cité ci avant sur le darwinisme, mais je trouve que tu ne pousse pas assez ton analyse.
En définitive tu devrais conclure que lorsque l'on a mis une jambe de bois (no sql) à la place d'une vrai jambe, y mettre un pansement ne servira à rien !!!
Cautère sur jambe de bois.
Autrement dit remplacer quelque chose que l'on a mal fait par quelque chose d'autre qui est encore plus sale, à toutes les chances de produire encore moins de bons résultats !!!!

A +

En même temps dans cet article qui aurait pu être superbe sans toutes ses erreurs et raccourcis sur des technologies qui semblent mal maitrisées ou mise en piéce pour le fun, je ne vois pas trop quoi en tirer...

Qu'il faut tout faire en SQL ? C'est faux.
Que le SQL c'est la silver bullet de l'informatique ? C'est faux.

Franchement en 2010 lire ça :

À un spécialiste des frameworks et ORM que j'ai réussi récemment à convaincre d'adhérer à la cause du développement en base de données épaisse pour un projet d'envergure, je posais la question suivante : quel argument vous a le plus convaincu ? Je pensais aux performances, à la pérennité du code, au temps gagné en développement, à la facilité de maintenance... Mais il m'a cloué le bec en me disant que c'était à cause de la reprise des données... Je n'y avais même pas pensé. Mais il est vrai qu'en fournissant tous les mécanismes de validation et de traitement des données côté base de données et à travers des vues, il ne suffisait plus que d'utiliser de simples jeux de requêtes pour importer les données de l'ancienne base vers la nouvelle. Bref, rien à redévelopper ! Mauvaise nouvelle pour les prestataires...

Je ne sais si c'est une blague ou un usurpateur, mais aucun architecte digne de ce nom ne fera un principe d'utiliser une technologie. On le sait tous. La techno répond au besoin, et pas le besoin fait avec la techno. Quel expert en ORM ne connait pas les vues, les contraintes, les différentes natures d'objet présentes dans un moteur ?????? L'Expert ORM qui découvre le SQL...C'est un tel cliché et finalement un raccourci facile...
Donc on va crucifier un savoir sur l'autel de la méconnaissance...

Le seul argument qui pourrait aller à l'encontre du tout SGBDR est celui de 'l'escalation'. En effet, de part sa nature unique, l'information ne peut exister qu'en un seul point du système d'information, sauf à induire une redondance préjudiciable et donc à prendre les SGBDR à rebrousse poil

A la poubelle le sharding, les réplications, le load balancing, la virtualisation...
Boum, tout le monde dehors...A la poubelle les caches distribués, à la poubelle les transactions distribuées.

Et le florilège de la conception qui coute les yeux de la tête pour peau de balle

Il faut s'interdire tout accès direct aux tables et par conséquent ne passer que par des vues pour la lecture ou des fonctions tables qui permettent de faire des vues paramétrées. De la même manière on peut passer par des vues pour la mise à jour ou des procédures pour les mises à jour complexes. Bref, il est impératif de recourir systématiquement à la notion de schéma externe et de se reposer dessus pour tout accès depuis l’IHM...

Comme ça s'il y a 1500 tables qui contiennent "Id;Description", on va faire 1500 vues.C'est la classe internationale. Surtout pour remplir des combo box.

Mais il faut aussi éviter les vues de vues, de vues... C'est pourquoi personnellement je recommande de ne pas dépasser deux niveaux d'imbrication des vues : des vues de mise à plat des données et des vues orientées objets pouvant éventuellement utiliser les premières.

Là c'est du grand mystique....

Les données pilotent les programmes : il faut s'assurer que l'enchaînement des traitements repose sur le résultat de données en sortie d'un précédent traitement. Pour cela tout doit être exprimé dans la base de données. Par exemple on doit faire en sorte qu'il n'existe aucune constante, autre que naturelle16, dans les programmes.

Ok donc, résultats volatiles, simulation, calcul intermédiaires...Ben non. C'est pas du dev. C'est dommage quand même que les "programmes" utilisent des drivers pour accèder au SGBD. Finalement, ce serait mieux des drivers qui permettent au SGBD de piloter le programme ?????

les tables n'étant pas des objets, la façon de factoriser les appels aux données consiste à utiliser la généricité

Je crois que là, ça mérite le formol !!!!!

C'est pourquoi SQL Server intègre une machine CLR nommée SQL CLR, située à l'intérieur de l'environnement d'exécution du SGBDR, pour laquelle le serveur de bases de données exerce un contrôle total se permettant au pire des cas de virer le processus fautif dans un bac à sable !

Là il faut bien regarder l'exemple, et parès on peut revenir à ...

Nous devons donc conclure qu'en définitif un code ensembliste portant sur un jeu de données, même relativement faible, aura toutes les chances de battre systématiquement tout code itératif même le plus moderne qui soit. Bien entendu les différences de performances seront d'autant plus grandes que le volume des données sera plus important.

Bref, parmis d'autres...
C'est d'un poujadisme à dégouter tout décideur de l'IT.


Tu aurais pu aborder les vraies problèmatiques :
- La distribution de l'information. Les enjeux de rendre la donnée accessible et centralisée; avec le rôle du SGBDR et d'une maitrise des architectures de données
- Les possibilités d'architecture hétérogénes

Mais ça semble tellement loi...

[Erwy]

Tout ca vient du fait que le SGBD est utilisé pour faire la persistance des données d'un logiciel. Dans ce cas, coder un schéma de BdD n'est pas une finalité en soi mais juste une nécessité technique. On comprend donc que le développeur d'appli ne soit pas particulièrement intéressé a respecter (encore moins comprendre) les règles d'utilisation d'un SGBD.

Avant de l'affirmer il faut connaitre le contexte.
Hors ces données "propres au logiciel" sont des données légales qui doivent être conservé 5 ans au minimum et qui comprennent des données comptables et commerciales.
Les appli en questions concerent la saisie et/ou la réception et la vérifiaction de ces données. Même dans l'informatique de gestion ce problème de "méconnaissance du modèle de donnée" est récurrent mais tu montre bien le réflexe du développeur d'application allergique à la réflexion sur les données

Pour le reste, je ne suis pas du tout dans l'axe toute donnée doit être relationnelle, et je trouve que c'est une véritable misère qu'il n'y ait quasi aucune documentation sur les théories de données en informatiques autres que dans un contextes SGBDR...

Autant je comprends les DBAs qui poussent de grand cris face aux implémentations des développeurs...

En passant je ne suis que développeur pas DBA

[SQLpro]

Qu'il faut tout faire en SQL ? C'est faux.

Ou voyez vous cela dans mes propos... Je ne l'ais jamais dit, et si vous aviez lu mes propos d'un post, juste avant celui là, je disais :
"Le problème est qu'un certain nombre de personne utilisent des SGBDR à mauvais escient et viennent s'en plaindre après."
http://www.developpez.net/forums/d77...e/#post5312643

Que le SQL c'est la silver bullet de l'informatique ? C'est faux.

L'Expert ORM qui découvre le SQL...C'est un tel cliché et finalement un raccourci facile...

Mais c'est hélas la triste réalité... En plus de mon boulot de conseil, je donne des cours aux 5e années d'ingénieurs à l'ISEN, l'EXIA (CESI) et aux arts et métiers.... Le bilan est lourd : l'approche base de données (modélisation, transactionnel, SQL...) se résume à 32 heures de cours ! Celle des ORM et autres frameworks, plus de 200 !!!
Et l'expert ORM est la plupart du temps le développeur lui même !

A la poubelle le sharding, les réplications, le load balancing, la virtualisation...

La réplication répon à un autre besoin que celui de la multiplicité des bases. On réplique des informations pour d'autres usage que dans la version d'origine. Le load balancing n'existe pas vraiment en matière de SGBDR puisqu'il nécessite un point de passage obligé qui est la r&éplication et quand à la virtualisation des SGBDR, je me marre doucement ! Même Valduriez qui est un grand expert des solutions distribuées de données, déconseille fortement la virtualisation des SSGBDR car cela cause de très mauvais perf, qui rendent les serveurs inexploitables. Voire l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8...irtualisation/

Boum, tout le monde dehors...A la poubelle les caches distribués, à la poubelle les transactions distribuées.

Une transaction distribuée n'est pas une transaction sur les mêmes données ais sur des données différentes de serveurs différents, même hétérogène. De plus rien ne garanti la bonne finalisation des transactions distribuées. Si vous avez découvert un mécanisme pour garantir cela, n'hésitez pas à concourir à la médaille fields ou le prix Alan Turing !

Comme ça s'il y a 1500 tables qui contiennent "Id;Description", on va faire 1500 vues.C'est la classe internationale. Surtout pour remplir des combo box.

Inutile une seule vue en UNION ALL suffit à synthétiser toutes les tables de référence alimentant toutes les combos de l'application...

Ok donc, résultats volatiles, simulation, calcul intermédiaires...Ben non. C'est pas du dev. C'est dommage quand même que les "programmes" utilisent des drivers pour accèder au SGBD. Finalement, ce serait mieux des drivers qui permettent au SGBD de piloter le programme ?????

L'un n'empêche pas l'autre !

Tu aurais pu aborder les vraies problèmatiques :
- La distribution de l'information. Les enjeux de rendre la donnée accessible et centralisée; avec le rôle du SGBDR et d'une maitrise des architectures de données
- Les possibilités d'architecture hétérogénes

Ce n'étais pas le sujet. Valduriez fait un excellent cours chez Orsys à ce sujet. Moi je met ce genre de chose, en pratique depuis fort longtemps pour mes clients....
http://www.orsys.fr/formation-systemes-repartis.asp


A +

[SQLpro]

...ces memes DBAs doivent bien reconnaitre que les SGBD ne sont pas véritablement en phase avec les problématiques de développement de 2010 : répartition des donnés, multi-threading, orienté-objet, versioning, extensibilité, ...

Visiblement vous avez un manque cruel de connaissance ou bien vous développez avec MySQL !!!
La répartition des données existe depuis 2O ans dans les SGBDR : gestion des espaces de stockage, partitionnement de données, bases de données réparties...
Multi threading : il y a fort longtemps que les SGBDR sont multi threadés et même apte à faire du parallélisme massif. C'est même le principal intérêt des requêtes ensembliste face à du code itératif dont la parallélisation est extrêmement difficile !
orienté-objet : : cela fait plus de 10 ans que les SGBDR intègrent du XML avec les méthodes qui vont avec (XQuery, Xpath... lisez : [ame="http://www.amazon.fr/Querying-Xml-Xquery-Xpath-Context/dp/1558607110"]Querying Xml: Xquery, Xpath, And Sql/xml in Context: Amazon.fr: Jim Melton, Stephen Buxton: Livres en anglais@@AMEPARAM@@http://ecx.images-amazon.com/images/I/41F0XxY0x3L.@@AMEPARAM@@41F0XxY0x3L[/ame]) et même des objets. La norme SQL de 1999 à entériné les structures objet et le comportement de SQL qui va avec.
extensibilité : tous les SGBDR (sauf MySQL) sont capable d'étendre leurs types de données, les fonctions, procédures et déclencheurs avec des langages hôte comme Java ou C#....

Visiblement vous êtes pile dans le genre de problème que je dénonce : manque de culture => ne pas prendre SQL car il sait pas faire, ce qui est manifestement faux.
Je vous invite à lire mon livre... Vous découvrirez peut être enfin ce que SQL est capable de faire !!! [ame="http://www.amazon.fr/SQL-1C%C3%A9d%C3%A9rom-Fr%C3%A9d%C3%A9ric-Brouard/dp/2744073180"]SQL (1Cédérom): Amazon.fr: Frédéric Brouard, Rudi Bruchez, Christian Soutou, Nicolas Larrousse, Stéphane Faroult: Livres@@AMEPARAM@@http://ecx.images-amazon.com/images/I/51CSsRN-yKL.@@AMEPARAM@@51CSsRN-yKL[/ame]

A +

[SQLpro]

Je n'avais pas lu les récents propos de Fabian, qui rejoignent les miens (lisez mes intro dans les bouquins sur SQL que j'ai écris)...

A +

On en reviens toujours au même constat: un problème d'incompétence, d'ignorance finalement ?...

Fabian Pascal n'est pas très optimiste:

No surprise there. The database industry has been taken over by vociferous ignoramuses who are selling crappola to other ignoramuses and everybody's happy because ignorance is bliss. Expect this to become even worse; there is no bottom.

This is a consequence of the total collapse of the educational system, and hardly the most critical one[; just look at the state and path of the country]. The dismissal of knowledge and reason is dooming western society in general and the american empire in particular, with the barbarians at the gates.

Pour rejoindre SQLPro sur l'histoire des SGBD:

The history of the field should be an obligatory part of computer science curriculum, but I won’t hold my breath. The academia is increasingly focused on product training for vendors rather than on education.

Those who forget, or dismiss the past ...

A note on programmer knowledge
Note on programmers and data fundamentals
Une étude intéressante à lire, sur le fait d'être incompétent et la difficulté de s'en apercevoir:
Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments

A +

[B.AF]

La réplication répon à un autre besoin que celui de la multiplicité des bases. On réplique des informations pour d'autres usage que dans la version d'origine. Le load balancing n'existe pas vraiment en matière de SGBDR puisqu'il nécessite un point de passage obligé qui est la r&éplication et quand à la virtualisation des SGBDR, je me marre doucement ! Même Valduriez qui est un grand expert des solutions distribuées de données, déconseille fortement la virtualisation des SSGBDR car cela cause de très mauvais perf, qui rendent les serveurs inexploitables. Voire l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8...irtualisation/
A +

Donc c'est bien ce que je dis, toute évolution est inutile. On se demande pourquoi SQL Server 2008 R2 Enterprise existe... Par exemple...

Une transaction distribuée n'est pas une transaction sur les mêmes données ais sur des données différentes de serveurs différents, même hétérogène. De plus rien ne garanti la bonne finalisation des transactions distribuées. Si vous avez découvert un mécanisme pour garantir cela, n'hésitez pas à concourir à la médaille fields ou le prix Alan Turing !

Qui te dit que ce n'est pas déjà le cas ? Rester anonyme n'est pas toujours un choix.

[Erwy]

orienté-objet : : cela fait plus de 10 ans que les SGBDR intègrent du XML avec les méthodes qui vont avec (XQuery, Xpath... [..])

Je ne peux parler que dOracle à ce niveau mais je mettrais un bémol la dessus.
Il y a 10 ans de gros efforts ont été fait dans ce sens et Oracle pouvait même se vanter d'être à la pointe mais cela donne parfois l'impression qu'ils ont abandonné toutes améliorations (et il y en a un paquet à faire....) et même corrections depuis un moment.
Entre les "fonctions XML" du SQL, du PL, et leur package java on a parfois de sacrés bizarreries et des cas d'utilisations largement ignorés.
La validation par les schema XML est une usine à gaz .
Leur XSLT n'est pas standard à 100% et leur moteur est loin d'être performant.
Jamais testé XQuery sur Oracle, mais je crains la même chose.
Ils ont par contre des technos comme XSQL (exportable sur d'autres bases comme Mysql) qui sont vraiment très intéressante et qui effectue une parfaite liaison entre relationnel et XML mais qui ne semble malheureusement plus connaitre de développement à ce jour.
En gros l'intégration du XML dans un SGBDR est généralement bien faite, les outils XML de bases sont un peu bancal et pour le reste...

[SQLpro]

Effectivement et cela n'est pas nouveau, Oracle est en retard de corrections depuis quelques années et pêche parfois par un excés de fonctionnalité pas toujours optimisé. Cela a été plusieurs fois dénoncé par des experts, notamment sur le plan de la sécurité !

A +

[pseudocode]

Visiblement vous êtes pile dans le genre de problème que je dénonce : manque de culture => ne pas prendre SQL car il sait pas faire, [B]ce qui est manifestement faux.

Tu as mal interprété mes propos. Je ne parle pas de répartition ou Multi threading A L'INTERIEUR du moteur du SGBD.

Je parle de problématique applicative : faire une application multi-tache ou répartie qui doit manipuler des données.

Il est toujours sur possible d'utiliser un SGBD pour faire cela, mais ca consiste souvent à TOUT mettre dans le SGBD : le schéma, les données, le code, ...

C'est un peu ce qui me chagrine chaque fois que je tombe sur un DBA un peu zélé : il m'explique qu'on peut tout faire avec le SGBD... et quand je lui explique que je veux juste faire "une partie" du travail avec le SGBD, je me retrouve avec des limitations/contraintes. Et le DBA m'explique que ces contraintes sont dues au fait que je n'ai pas "bien" utilisé le SGBD, comprenez par là qu'il fallait concevoir toute l'application autour de BdD.

[fsmrel]

Quand à l'utilisation des SGBD partout, j'attends toujours qu'on me donne une réponse objective sur la nécessité d'utiliser la théorie relationnelle pour le stockage du cache de Firefox.

SGBD, Logique mathématique et Épicerie n’ont pas la même finalité. Je dois reconnaître que l’apport d’Aristote, de Frege, de Russel, de Gödel ou de Łukasiewicz à la gestion des caches des SGBD X ou Y sont probablement nuls.

La Théorie relationnelle inventée en 1969 par Ted Codd est une branche des mathématiques appliquées et qui se définit ainsi :

1. Une collection non limitée de types scalaires (dont notamment le type booléen (valeur de vérité)) ;
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen ;
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu ;
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs de relations à ces variables ;
5. Une collection non limitée d’opérateurs relationnels génériques (« l’algèbre relationnelle »), pour produire des valeurs de relations à partir d’autres valeurs de relations.

Ted Codd n’était ni un informaticien ni un épicier, seulement un mathématicien, mais il a révolutionné l’approche que nous avions à l’époque de la modélisation des données, de leur manipulation et de leur intégrité. Pour avoir beaucoup utilisé les SGBD pré-relationnels, je sais de quoi je parle.

Disons que les rapports qu’entretiennent la théorie relationnelle et les caches de Firefox sont ceux qu’entretiennent Léonard de Vinci et la Compagnie du gaz (pour citer André Frossard sur ce dernier point).

[B.AF]

Cependant, un effet de bord me semble aussi important à prendre en compte : l'effet volume.
Quand bien même il peut y avoir un modèle de données cohérent et juste, il n'en reste pas moins que sa qualité ne va prévaloir que par sa capacité à absorber la volumétrie de données.
Or, aujourd'hui, la plupart des développeurs travaillent sur des bases locales, ou des bases anémiques. Pourquoi ? Parce qu’ils ne comprennent souvent pas l’utilité finale de leur développement. Ils ne connaissent pas les attentes de l’utilisateur. Ils ne connaissent pas le contexte d’utilisation. Ils développent ce qui est spécifié par des experts, et désigné par des architectes.
Parce que la donnée en elle même est triviale, c'est son traitement qui ne l'est pas. Or il est très difficile de générer une volumétrie importante de données permettant de valider et la qualité fonctionnelle, et la robustesse, et la montée en charge. Encore plus quand le Sgbd contient la logique métier. C’est infernal à maintenir. C’est un coût, du temps, de la maintenance.
De la même façon qu'existent les EJB, les JSF, l'AOP, l'IOC, c'est une des nièmes tentatives d'une profession qui ne comprend pas que la qualité de production et liée à la qualité de compréhension. La technique est compréhensible de tous aujourd'hui; l'information est très accessible.
Prenons un exemple : je suis sur un projet où "je" manipule un ensemble de données complexes. Eventuellement si certains voient un intérêt je peux le montrer, mais il est incompréhensible pour une personne qui ne connait pas l'objet du projet.
Globalement, par rapport au stockage, j'ai un rapport d'emploi qui est :
- 80% de consultations
- 20% de traitements divers
En modifiant les contraintes, en modifiant le modèle physique et en utilisant des structures ad-hoc, j’ai réduit un traitement « stratégique » (tout ce qui est long est stratégique en entreprise…) de 120 secondes à 50 secondes.
Cependant, le modèle d'origine était efficient :
- Relations cohérentes
- Types cohérents
- Contraintes cohérentes
- Indexation cohérente (notamment la dimension temps)
D'où provient le défaut ? Le développeur d'origine a travaillé sur une population fixe; là ou la db reçoit un volume croissant quotidien et surtout sur une population non représentative. Pour reprendre le principe de fractal, une pierre n'est pas un cube. Donc la science ignorant le contexte, la problématique ne s'est pas posée.
Pourtant, il connait très bien le SQL, très bien la modélisation. Il a juste oublié le contexte d'utilisation.
Il a appliqué religieusement tous les grands principes de modélisation de base de données. Il a appliqué les "best practices" dont certaines que l'ont retrouve dans les documents de SQL Pro. Et pourtant ça dysfonctionne ...Et il ne devrait pas rougir, je pense qu’aucun expert ici ne trouverait à redire.
Comment j’ai trouvé la solution ? En raisonnant en dehors du standard. On a aussi le droit et parfois l’obligation de ne pas suivre les sentiers peut être battus, mais surtout boueux.
Le métier restera toujours le fantôme de nos machines. Quelle que soit la technologie, et le relationnel ou le non-relationnel n'échappe pas à cette règle.
La recherche a cependant cela de clément, c’est qu’on apprend que la possibilité de se tromper existe, et que l’efficacité ou un début de vérité ne peut exister sans une collecte d’information importante, sans une information de qualité, sans plusieurs hypothèses.
Quand des générations avant la mienne ont prôné l’exclusivité du process comme élément de sa qualité et la standardisation comme indicateur d’efficacité, pourquoi aujourd’hui nous plaindre qu’une génération accepte l’enseignement de la précédente ?

[CinePhil]

Je crois comprendre que le cas que tu cites est celui d'une base de données modélisée et implémentée dans les règles de l'art n'a pas supporté la montée en charge pour certaines requêtes devenant trop longues.

Il a été dit plusieurs fois dans les forums dédiés à la modélisation des données et aux BDD que la dénormalisation d'une BDD était possible... à partir du moment où on constate que la BDD ne tient plus la charge. Il ne faut pas dénormaliser a priori.

Si j'ai bien compris, c'est ce que tu as fait.

Ce qui aurait pu être fait avant la mise en production, ce sont des tests de montée en charge en remplissant les tables d'un grand nombre de données fictive représentant l'estimation de la charge estimée par le projet. Il aurait alors été possible de penser à la dénormalisation avant la mise en production, mais pas pendant la conception.

[B.AF]

Ce qui aurait pu être fait avant la mise en production, ce sont des tests de montée en charge en remplissant les tables d'un grand nombre de données fictive représentant l'estimation de la charge estimée par le projet. Il aurait alors été possible de penser à la dénormalisation avant la mise en production, mais pas pendant la conception.

Dans la réalité c'est possible s’il y a 15 tables, pas d'historique, pas de logique métier.
Globalement, on peut dire qu'on attend un jeu d'essai qui :
- Représente initialement une situation de production cohérente (e.g : 2 années de production)
- Permet d'intégrer des données pouvant correspondre à une production normale, et/ou à une production exceptionnelle, et/ou une augmentation saisonnière.
- Est entièrement valide
Et donc que l'on dispose d'un moyen de s'assurer que l'ensemble des traitements proposés par l'application exploite parfaitement ces données (0 défauts)
Sur un ERP, par exemple, ou un CRM, cela signifie créer des jeux de données pour 4/5 ans de production. En constatant que l'utilisation du logiciel représente aujourd'hui 30 à 40% du travail des utilisateurs (vérification, compréhension, validation), on peut dire que sur une population de 50 utilisateurs, tu fais face au besoin de collecter des jeux de données et des scénarios d'utilisation correspondant à + de 500 années/h de prod.
Sans compter qu'il faut le faire vivre, qu'une application évolue, change...
Comment faire dans ce cas là pour
- Anticiper la charge ?
- Valider les traitements métiers dans le SGBD ?
La méthode existe, mais les bugs sont aujourd'hui aussi la victoire de la réalité du terrain sur la méthode.

L'élément faillible du développement, c'est l'homme. Quel que soit le langage, quel que soit son niveau d'éducation, l'homme est paresseux. Et c'est pour ça que le développement est souvent sale, que les processus projets ne fonctionnent pas, que les applications ne fonctionnent pas à 0 défaut.
Parce qu'un développeur prendra toujours plus de plaisir à apprendre un nième Framework qu'à collecter des données de test ou à comprendre la teneur fonctionnelle d'un sujet, parce que depuis des années "on" explique que ce n'est pas son travail. Il y a toujours une responsabilité dans la chaine pour justifier l’absence de travail ou de recherche. Qu'un moa qui ne comprend rien au développement ne va pas capter l'enjeu dont nous parlons par exemple, donc il ne transmettra pas l'information ou la négligera. Que l'expert métier sera toujours un wanna be qui a raté sa carriére métier tout court car un vrai expert métier aura une reconnaissance sociale et financiére bien plus importante dans son domaine d'expertise que dans l'informatique. Que le management est une gigantesque blague universelle vouée à justifier les écarts de rémunération entre l'homme et le capital et que c'est le fondement de la théorie des organisations. Et que tout le monde sait ça et que tout le monde l'accepte et que tout le monde au final...S'en fout. On humanise le processus, les crises, les thérapies de groupe, les comités, les réunions, les points, les meetings, les livrables, les documents. On brasse de l'air pour ne pas faire l'essentiel parce que l'essentiel demande du travail et beaucoup.

Quand on a invité les gens à la paresse intellectuelle depuis 15 ans, qu'on les arrose de méthodologies et dogmes dans lesquels ils ne s'épanouissent pas; pourquoi s'étonner de l'absence d'implication ou de qualité ?
Moi je cherche toujours parce que je suis un chercheur à la base. Et je sais que je ne partage pas grand chose avec la "distribution normale" des informaticiens ni même des ingénieurs. Je ne crois pas au savoir centralisé, aux organisations mécaniques et au savoir « instantané ».

J'aime comprendre l'utilité de la moindre donnée; comprendre son rôle, son implication, sa validité, son histoire. J’aime comprendre la finalité de ce que je fais. Et pour cela, il faut aller à l’essentiel.
Une fois cela fait, la technologie n’est qu’une option parmi n, une hypothèse de recherche. A l’expérience on peut la déterminer plus rapidement et certains choix standards sont valides rapidement.
Les facteur déterminants sont toujours en revanche : les gens avec qui je collabore.

[CinePhil]

Je me contenterai de rester dans le sujet en répondant à la première partie :

Dans la réalité c'est possible s’il y a 15 tables, pas d'historique, pas de logique métier.
Globalement, on peut dire qu'on attend un jeu d'essai qui :
- Représente initialement une situation de production cohérente (e.g : 2 années de production)
- Permet d'intégrer des données pouvant correspondre à une production normale, et/ou à une production exceptionnelle, et/ou une augmentation saisonnière.
- Est entièrement valide
Et donc que l'on dispose d'un moyen de s'assurer que l'ensemble des traitements proposés par l'application exploite parfaitement ces données (0 défauts)
Sur un ERP, par exemple, ou un CRM, cela signifie créer des jeux de données pour 4/5 ans de production. En constatant que l'utilisation du logiciel représente aujourd'hui 30 à 40% du travail des utilisateurs (vérification, compréhension, validation), on peut dire que sur une population de 50 utilisateurs, tu fais face au besoin de collecter des jeux de données et des scénarios d'utilisation correspondant à + de 500 années/h de prod.
Sans compter qu'il faut le faire vivre, qu'une application évolue, change...
Comment faire dans ce cas là pour
- Anticiper la charge ?
- Valider les traitements métiers dans le SGBD ?

Je parlais de peuplement automatique de tables pour tester la montée en charge. Pas de travailler avec des données réelles.

Je ne l'ai jamais fait moi-même mais j'ai vu plusieurs exemples de procédures qui permettent de le faire. je crois qu'il y en a chez SQLPro.

Si l'entreprise concernée a par exemple :
- 50 catégories de produits ;
- 3000 produits ;
- 10 000 fournisseurs ;
- 50 000 clients.

Si on estime que ça générera 200 000 commandes et 1 million de lignes de commandes par an , on peuple les tables de manière cohérente avec ce volume par des procédures automatiques et on teste les requêtes les plus critiques pour voir si les temps de réponse restent satisfaisants.

Si on constate que certaines sont trop longues, alors on examine les plans de requête pour comprendre où est le bouchon et on envisage de le faire sauter par une dénormalisation... après avoir envisagé toutes les autres possibilités d'optimisation.

La méthode existe, mais les bugs sont aujourd'hui aussi la victoire de la réalité du terrain sur la méthode.

Oui le problème est généralement dans l'interface clavier - chaise.

Mais pour en revenir au sujet de cette discussion, j'ai de gros doutes sur la capacité d'un système noSQL à gérer plus efficacement et avec au moins le même degré de sûreté qu'un SGBDR un tel volume de données.

[B.AF]

Je me contenterai de rester dans le sujet en répondant à la première partie :
Je parlais de peuplement automatique de tables pour tester la monté en charge. Pas de travailler avec des données réelles.

Je ne l'ai jamais fait moi-même mais j'ai vu plusieurs exemples de procédures qui permettent de le faire. je crois qu'il y en a chez SQLPro.

Si l'entreprise concernée a par exemple :
- 50 catégories de produits ;
- 3000 produits ;
- 10 000 fournisseurs ;
- 50 000 clients.

Si on estime que ça générera 200 000 commandes et 1 million de lignes de commandes par an , on peuple les tables de manière cohérente avec ce volume par des procédures automatiques et on teste les requêtes les plus critiques pour voir si les temps de réponse restent satisfaisants.

Si on constate que certaines sont trop longues, alors on examine les plans de requête pour comprendre où est le bouchon et on envisage de le faire sauter par une dénormalisation... après avoir envisagé toutes les autres possibilités d'optimisation.

Oui le problème est généralement dans l'interface clavier - chaise.

Mais pour en revenir au sujet de cette discussion, j'ai de gros doutes sur la capacité d'un système noSQL à gérer plus efficacement et avec au moins le même degré de sûreté qu'un SGBDR un tel volume de données.

Oui, cela répond à certains cas, mais pas à tous, et surtout pas à ceux qui sont aujourd'hui mis en avant pour "shooter à vue" sur les sgbd.

Le système noSQL, ça ne change rien, le fait que ce ne soit pas du SGBD n'empêche pas de penser à la question du volume et de la performance. L'erreur existe aussi en noSQL. Comme en C, ou en basic.

Disons que dans le cas où il est nécessaire des stocker une donnée volumineuse non structurée, ils présentent une architecture plus séduisante que les SGBD. En outre, il y a beaucoup d'approches différentes et il y a systèmatiquement un langage de manipulation. Seulement, ce n'est pas une norme.

Ce qui est plus drôle c'est que j'ai vu il y a quelque jour un ORM qui est conçu pour un outil noSQL

[fsmrel]

Ce qui aurait pu être fait avant la mise en production, ce sont des tests de montée en charge en remplissant les tables d'un grand nombre de données fictive représentant l'estimation de la charge estimée par le projet. Il aurait alors été possible de penser à la dénormalisation avant la mise en production, mais pas pendant la conception.

Dans la réalité c'est possible s’il y a 15 tables, pas d'historique, pas de logique métier.

CinePhil a parfaitement raison en ce qui concerne les tests de montée en charge qui doivent absolument faire partie des travaux de prototypage des performances. En revanche, je ne suis pas d’accord sur le fait qu’il faille dénormaliser, car ce prototypage des performances montre que c’est inutile si la modélisation des données est correcte, cela fait 40 ans que je l’observe. Les séances de prototypage mettent plutôt en évidence les maladresses de modélisation.

Pour ma part, j’ai d’abord effectué ces travaux en utilisant des SGBD pré-relationnels (tels que IMS/DL1, IDMS, TOTAL, Adabas), puis avec SQL/DS, DB2 ou Teradata, dans tous les univers : banque, assurance, industrie, administration, grande distribution, retraite, etc. : les préparatifs sont toujours les mêmes, à savoir identifier le top 10 des transactions (lesquelles, bien sûr, ne seront développées que dans six mois ou un an), les grands batchs avec lesquels on ira chercher les sous chez les clients de l’entreprise. Cela suppose que l’on dispose d’un MCD (ou diagramme de classes ou autre) correspondant au cœur du système. Même si le MLD dérivé comporte 1500 tables, on sait très bien que c’est seulement sur le cœur du système — justement une quinzaine de tables au plus — que l’on doit se focaliser, quitte à enrichir ce coeur au fil du temps.

Que l’on vous annonce un historique de cinq milliards de lignes, ça impressionne, mais on s’en occupera après. Une fois que le cœur du système aura subi avec succès l’épreuve du prototypage des performances, il sera toujours temps de discuter avec la maîtrise d’oeuvre et/ou la maîtrise d’ouvrage pour juger des conséquences techniques et financières de la mise en œuvre des monstres à cinq milliards de lignes.

Quant à la logique métier, là encore on en reste au cœur, même si cela reste fruste : si on sait comment brancher les contrats sur les entreprises clientes, brancher les cotisations sur les employés de ces entreprises, on est à même de développer les requêtes — disons SQL, c’est quand même plus simple — sur lesquelles on va se focaliser, en remplissant les tables avec des valeurs que l’on génère soi-même au moyen de requêtes ad-hoc au sein de brouillons de transaction, pour des volumétries qui ont été estimées en relation avec les chefs de projet. Et on est parti pour observer et résoudre les problèmes de performance.

Tous ces travaux sont du ressort du DBA, lequel ne doit bien sûr pas être un perdreau de l’année, mais qui se doit de s’adjoindre des DBA plus jeunes, motivés et capables, pendant un bon mois, de passer des nuits (à apprendre) à prototyper.

[Jester]

Vous faites comment quand le process métier change et que votre modèle de données ne convient pas/plus?

Parce que partir de rien c'est somme toute plus facile.

[Erwy]

J'interprète peut être mal votre message, ou peut être n'est ce valable que pour l'informatique de gestion dont j'ai l'habitude mais le "process métier"(si on entend par là le processus applicatif) ne doit avoir qu'un impact minoritaire sur les données (essentiellement sur l'optimisation).

Ce qui est important c'est :
1) Analyse des métiers et "objets de données" (formulaires,facture,devis,liste...) concernés par l'application qui vous donnent les données et leur forme
2)le plan d'urbanisation (passé,futur, présent) de votre SI parce qu'il est illusoire de croire que votre application ne va pas évoluer ou que d'autres applications ne vont pas l'utiliser qui vous donnent ce qui est à implémneter en priorité comme données.

On voit d'abord les données, ensuite l'application.
Cela n'a rien d'extra ordinaire puisque même UML qui est pourtant axé applicatif suit cette démarche.
A noté que d'un point de vue donnée si je vois l'intérêt d'UML pour coder un framework d'accès aux données , je trouve qu'il n'a aucun intérêt au point de vue SGBD ou n revient vite à MERISE

Si cela a été mené correctement c'est le framework d'accès aux données, ainsi que les optimisations, qui devront être modifiés en cas de changement de "process métier", pas la forme de vos données

[B.AF]

Si cela a été mené correctement c'est le framework d'accès aux données, ainsi que les optimisations, qui devront être modifiés en cas de changement de "process métier", pas la forme de vos données

C'est une affirmation un peu rapide.