Discussion :

[erpWorld]

Bonjour
après une expérience de 10 ans presque dans le monde des ERP et de consulting, je me suis concentré depuis une année presque sur les bases de données et exceptionnellement SQL Server.
J'ai remarqué une ignorance totale de ce monde quelque soit au niveau des développements : les développeurs utilisent les SGBD comme conteneur de données uniquement (mauvais choix de type de données, conceptions non normalisés), les ORM sont les maîtres des codes sources, absence totale des routines SQL.
Au niveau administration aussi : tous les logins sont des sysadmin, pas d'utilisation de normes d'utilisateur de base de données et des rôles.
Aucune études pour les stratégie de sauvegarde et de récupération
Un seul travail existant dans l'agent SQL pour une sauvegarde complète quotidienne, pas de maintenance d'index...
Je peux pas donner des critiques vue que j'ai pas encore de l'expérience et de l'expertise dans le domaine mais je pense pas que les éditeurs tel que Microsoft ou Oracle continuent a faire des investissements et des recherches autour de leurs produits pour rien
Malheureusement les données sont les éléments les plus chers et sensibles des entreprises et malgré ça on continue a les ignorer.

[SQLpro]

Et encore, c'est parfois pire que ça…. Exemple classique "ouai, les perf sont pas bonnes, parce que c'est un SGBD Relationnel… Passe au NoSQL, tu verras ça déchire !!!!"

Pour info, écrit il y a plus de 10 ans…. : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

A +

[StringBuilder]

Les joies des éditeurs de progiciels et la gestion des données

Ce qui me fait le plus peur, c'est que j'ai découvert Oracle à l'époque où un serveur avec 128 Mo de mémoire c'était énorme... et que ça tournait aussi bien que les mêmes produits, sur les mêmes SGBD, simplement en versions plus récentes, sur des machines où il faut maintenant 128 Go de mémoire.

Non seulement il y a 30 ans, les développeurs d'ERP et autres progiciels n'y comprenaient rien aux bases de données, mais depuis, ça a plus qu'empiré : la moindre sélection d'une liste de quelques lignes dans une table va demander des dizaines de requêtes, souvent pas optimisées du tout, et consommer un trafic réseau totalement surréaliste en raison d'erreurs de codage abominables...

Le pire que j'ai vu jusqu'à présent, c'est quand même un programme qui fait :

select * from matable order by toto
=> Chargement de toutes les lignes, mais aussi toutes les colonnes, y compris les BLOB et autres.

Puis un seek sur la premère ligne.
Et au moment de passer à la seconde ligne...
Rebelotte : select * from matable order by toto, seek sur la seconde, et ainsi de suite.
Bref, au final t'as chargé la table dans son intégralité plusieurs centaines de voir pour éditer une simple facture...
Et le client qui dit "pffff, le séquentiel indexé c'était mieux !"

[erpWorld]

Pour info, écrit il y a plus de 10 ans…. : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
A +

J'ai lu cet article grâce a un client qui a demandé le développement d'un module avec cette méthode... Notre équipe de développement n'a pas été convaincu et on a pu perdre le projet 😁
Mon rêve maintenant est développé une Gestion Commerciale en suivant les détails cités.
événement = appel de procédure
j'ai demandé l'aide de quelques développeurs de windev et ils m'ont dit que c'est une ancienne méthode et q'uil faut pensé plutôt a faire les traitements côté applicatif pour ne pas être dépendant d'un seul SGBD
Mais refaire une application est plus simple que refaire la conception, changer de SGBD et migrer les données de plus on peut développer des routines utilisables sur tous les grands SGBD simplement en respectant la normes SQL et comme ça la migration du code sera plus facile

[erpWorld]

.
Et au moment de passer à la seconde ligne...
Rebelotte : select * from matable order by toto, seek sur la seconde, et ainsi de suite.
Bref, au final t'as chargé la table dans son intégralité plusieurs centaines de voir pour éditer une simple facture...
Et le client qui dit "pffff, le séquentiel indexé c'était mieux !"

Un problème presque similaire dans notre code
-requête pour charger les factures
-requête pour charger les clients
-requête pour les dépôts
-une autre pour les devise.
...
Avec une TRES mauvaise conception on arrive alors a des temps d'exécution médiocre pour un nouveau développement (première version livrée en 2015) (10 secondes pour 20000 lignes) sachant la plus grande base installée de ce module ne dépasse pas 1Go.

J'ai développé récemment quelques routines sql pour récupérer un historique des règlements de factures :
- 1j/h de développement vs 3j/h lorsqu'on a fait le même truc en dev
- temps de traitement : quelques secondes en SQL (insertion de toutes les lignes dans la même transaction) vs des heures a l'aide d'un dev en .Net (traitement en boucle, insertion d'une seule ligne dans chaque transaction)

[StringBuilder]

Bonjour, quelques commentaires

Mon rêve maintenant est développé une Gestion Commerciale en suivant les détails cités.
événement = appel de procédure

C'est un rêve pieu.
Le problème, c'est que malheureusement, la gestion commerciale est fait d'autant d'exceptions qu'il y a de règles (chaque règle étant une exception).
Il en ressort un constat simple : si on veut "bien modéliser", on va devoir écrire une usine à gaz en termes de quantité de code.
C'est, je pense, la première raison pour laquelle les ERP sont généralement si mal conçus : il sont avant tout conçus pour pouvoir répondre au plus de problématiques possible, et donc savent tout faire, mais rien de bien.
Un exemple simple, c'est la gestion des prix : parfois il y a un prix unique tout client confondu, parfois il y a des prix en fonction de la famille de client, parfois en fonction du client lui-même, de sa zone géographique, parfois il y a des tarifs en fonction des quantités, parfois on a même du panachage, avec des règles aussi diverses que variées (si camion complet, alors remise de 10%, si 3 produits achetés, alors le 4ème offert, si 5 produits parmi ces 10, alors une remise particulière, etc.).
Et bien souvent, on a droit à une fabuleuse combinaison de tout ça : même les ERP les plus puissants peinent souvent à gérer les descentes tarifaires des clients de la grande distribution notamment.
J'ai travaillé avec pas mal d'ERP différents, et ceux qui avaient un modèle le plus propre (le moins de colonnes dans les tables, le moins de colonnes vides dans les clés uniques, le plus de tables dédiées à un type d'information, etc.) étaient systématiquement les plus limités en termes fonctionnels.

j'ai demandé l'aide de quelques développeurs de windev

Oui mais alors là, non, pas WinDev.
WinDev c'est parfait pour faire du prototypage, une petite application monoposte dans une PME, etc.
Mais dès qu'on commence à taper dans du lourd (genre une gestion commerciale) on est tout de suite bloqué par le langage (et son mode de licence prohibitif… genre 5000 euros par poste pour pouvoir se connecter à SQL Server, ce qui revient au final plus cher que SQL Server lui-même !)

et ils m'ont dit que c'est une ancienne méthode et qu'il faut pensé plutôt a faire les traitements côté applicatif pour ne pas être dépendant d'un seul SGBD

Argument le plus fallacieux qu'il soit, donné par des personnes :
- qui ne comprennent absolument rien aux SGBD
- qui ont arrêté d'évoluer il y a 30 ou 40 ans
Ce fut vrai dans le début des années 90 et même 2000, à l'époque où certains SGBD, y compris les leaders, ne supportaient presque rien du SQL standard et utilisaient chacun leurs spécificités, et avaient une gestion des types très différente les uns des autres.
Je me souviens du premier site Web que j'ai fait à l'époque avec une vieille version de Ingres (il me semble) : la moindre jointure ouverte (left join) faisait tomber le serveur mutualisé. L'hébergeur n'arrêtait pas de m'appeler car mon site faisait tomber tous les autres jusqu'à ce qu'on identifie d'où ça venait.
Je me souviens aussi de l'époque de SQL Server 6.5, où quand on utilisait une colonne "text" ou "image" dans une requête, si elle n'était pas la dernière, ça faisait planter le pilote ODBC.
Mais aussi et surtout, avant ODBC et OLEDB, chaque éditeur proposait son propre connecteur, pas forcément disponible dans tous les langages, et chacun avec ses spécificités (même à l'heure d'ODBC, le pilote pour Oracle 7 était une plaie : il fallait utiliser celui de Microsoft, plus limité, et non celui d'Oracle qui était instable).
Bref, à cette grande époque.
Et à cette époque, oui, un programme écrit pour Oracle avait très peu de chances de fonctionne correctement avec SQL Server, DB2 ou autre (et encore… depuis que j'ai commencé à travailler fin des années 90, j'ai toujours écrit des requêtes SQL en tentant de les rendre compatibles avec au moins Oracle et SQL Server… Mise à part pour la récursivité (avant l'apparition des CTE) je n'ai jamais eu de problème.
Pour ce qui est des langages procéduraux, T-SQL et PL/SQL sont très proches. Il faut certes, maintenir deux versions du même code, mais aussi bien les fonctionnalités que les instructions, 90% sont identiques ou presque. La seule vraie différence se situe au niveau syntaxique, et dans les triggers (Oracle gère les triggers de manière séquentielle alors que SQL Server les gère de manière ensembliste).
Rien d'insurmontable.

Mais refaire une application est plus simple que refaire la conception, changer de SGBD et migrer les données de plus on peut développer des routines utilisables sur tous les grands SGBD simplement en respectant la normes SQL et comme ça la migration du code sera plus facile

Je n'ai jamais travaillé avec SSIS, mais à l'époque de SQL Server 2000, on pouvait aspirer une base de données Oracle en quelques clic en utilisant DTS, et faire la même chose dans l'autre sens.
Je doute que cela ait régressé, au contraire.
Au contraire, je pense que si on a correctement développé son application, en pensant à l'avance à faire abstraction du SGBD, qu'il est très aisé de changer de SGBD…

Bon après, en WinDev c'est moins vrai. Je ne crois pas qu'un pilote ODBC existe, et on doit se coltiner le connecteur spécifique de chaque SGBD supporté… donc à partir de là, toute la couche d'accès au données est forcément dédiée à un SGBD. Mais voilà quoi… c'est WinDev.