Discussion :

[FMJ]

Bonjour,

Je n'ai pu résister au plaisir de partager avec vous cette petite perle. Incidemment, je suis tombé sur une "petite" requête utilisée par l'ERP que nous utilisons, requête qui m'a fait esquisser un petit sourire en l'analysant. Je trouvais cette requête un tantinet longuette à l'exécution.... Et pour cause : elle retourne 574 colonnes !!!!!!!!

Si si 574

Ah, le charme des * .......

[SQLpro]

Ho ce n'est rien...
Il m'est arrivé de voir plus de 2000 colonnes dans un SELECT.

Il y aa quelques années, un internaute du forum PostgreSQL cherchait désespérément comment paramétrer le moteur pour que les table réponse puissent dépasser 1664 colonnes...
Il utilisait Hibernate !!!
http://www.developpez.net/forums/d73...eme-jointures/

A +

[FMJ]

Effectivement, je joue plutôt niveau maternelle finalement.
Il n'empêche, je me pose beaucoup de questions sur la compétence des gus qui ont développé le MCD de cet ERP (surement l'un des plus gros en France). Quand tu vois que certaines tables qui peuvent contenir des millions de lignes comportent plus de 200 colonnes, moi ça me laisse pantois !

[kolodz]

Effectivement, je joue plutôt niveau maternelle finalement.
Il n'empêche, je me pose beaucoup de questions sur la compétence des gus qui ont développé le MCD de cet ERP (surement l'un des plus gros en France). Quand tu vois que certaines tables qui peuvent contenir des millions de lignes comportent plus de 200 colonnes, moi ça me laisse pantois !

C'est probablement de la faute de son employeur qui a voulu le payer à la colonne à la place de la ligne

[FMJ]

Je pense surtout qu'ils n'ont pas été foutu de se payer un DBA digne de ce nom. Remarque, même un stagiaire aurait percuté et leur aurait dit que les perfs allaient être misérables avec une pareille structure !
D'un autre côté, comme ils vendent aussi du matos, je me demande s'il n'y aurait pas un calcul visant à pousser les clients à prendre de grosses babasses ???!!!

[SQLpro]

.... grosses babasses ???!!!

Ne serais tu pas en train de citer IBM ?

A +

[FMJ]

Non, du tout. C'est un éditeur français. Les seules fois où j'ai eu à faire avec IBM, je n'ai pas eu à m'en plaindre !

[iberserk]

Non, du tout. C'est un éditeur français. Les seules fois où j'ai eu à faire avec IBM, je n'ai pas eu à m'en plaindre !

SAGE X3?

[FMJ]

SAGE, éditeur anglais à l'origine, appartient désormais à SAP, et est donc allemand. Enfin, si cela veut encore dire quelque chose pour ce genre de mastodonte.
Il suffit de regarder dans le top 10 du classe Truffle des éditeurs français. Je donnerai un dernier indice : cet éditeur pousse parfois le bouchon un peu trop loin !

[François DORIN]

Et pour cause : elle retourne 574 colonnes !!!!!!!!

Le problème n'est pas tant le nombre de colonnes (il doit bien y avoir des cas où cela à un sens !), mais le nombre de colonnes inutiles ! Si la requête envoie 574 colonnes alors que seules 3 sont utiles... alors oui, il y a un ENORME problème

[iberserk]

573 colonnes sur une même table un sens? je vous met au défi de me trouver un exemple de table avec autant de colonne et qui respecte, au minimum, la 3ème forme normale!

[François DORIN]

Le problème n'est pas d'avoir une table avec 500 colonnes, mais une requête retournant 500 colonnes. Ce sont deux choses très différentes !

[iberserk]

Le problème n'est pas d'avoir une table avec 500 colonnes, mais une requête retournant 500 colonnes. Ce sont deux choses très différentes !

Bien entendu, mais je répondais précisément à cette partie de votre phrase:

(il doit bien y avoir des cas où cela à un sens !)

.

[elsuket]

A priori c'est de toute façon difficile à saisir pour une personne normalement constituée, un peu comme une requête dont le résultat est affiché dans une page web et qui retorune 10000 lignes ...
J'en trouve aussi, mais je suis encore loin des 500+ colonnes

@++

[FMJ]

Le problème n'est pas d'avoir une table avec 500 colonnes, mais une requête retournant 500 colonnes. Ce sont deux choses très différentes !

Les deux mon général !

Pour la requête, je pense que l'appli doit utiliser 100 champs aux maximum ! Allez soyons fous disons 150 ! Le plus marrant, c'est que cette requête commence avec une liste interminable de colonnes pour finir par les répéter en utilisant [tables].*. Ils sont trop forts !

Quand aux tables et au nombre de colonnes, je vous rassure cet ERP n'est pas en reste : je pense à une table qui peut contenir des millions de lignes et qui comprend .... 217 colonnes ! A la louche, je dirais qu'une cinquantaine sont utilisés régulièrement ....

[Invité]

De mon bord, j'ai vu une table de 516 colonnes.
C'était une des rares tables avec clef primaire et indexation de la bd.
Sur les 516 colonnes, il y en avait moins de 50 qui étaient à autres choses que NULL...

[Lyche]

Ha tiens, j'ai travaillé récemment sur un ERP ou il y avait précisément 584Colonnes dans une table. A la décharge de l'éditeur, le projet est maintenu en interne et il est possible de faire ce que l'on veut de la base étant donné que c'est un modèle en méta-data et que depuis l'interface il est possible de créer des colonnes dans une table.

Le soucis de ce modèle c'est, évidemment que n'importe qui peut faire n'importe quoi dans leur base de données.. Et on en arrive à des catastrophes de modélisation et de performances!

Et quoi que vous fassiez, rien ne sera changé.. La réponse de mon client (et de mon chef à l'époque) "laisse, ça fonctionne comme ça"... 15 jours plus tard la base tombait et il a fallu remonter un serveur avec plus de ressources pour compenser..

[FMJ]

Vive la CPU ! Vive la RAM ! Vive les licences !

[Lyche]

Vive la CPU ! Vive la RAM ! Vive les licences !

Remarque, pas toujours, je bosse avec un éditeur en ce moment qui préconises des machines scandaleusement énormes pour au final se rendre compte que le processus est tellement dégueulasse que rajouter CPU+RAM ne change pas les temps de traitement

Ils chargent leurs données en cache et font du traitement de la base en linéaire... quand j'ai demandé à leur archi pourquoi ils avaient fait ça (15minutes de temps de traitement pour 1Million de lignes et moins de 1Go de data) Il m'a tout simplement répondu qu'il avait les même perfs qu'en SQL et que ça le faisait chier de maintenir du code SQL

Donc bon... le CPU+RAM ça a bon dos pour justifier des perfs.

En gros, l'éditeur recommande 16Coeurs et 512 de RAM pour un serveur qui contiendra maximum 1To de base sur 6ans.. et 1To, je suis très très large

Tout ça pour dire que non, monter le coût de la machine ne veux certainement pas dire amélioration sensible des performances applicatives.. Si le processus est pourrit au départ, il restera pourrit malgré la machine.

[FMJ]

Je suis tout à fait d'accord. Mon cocorico précédent ne relayait que l'état d'esprit de la plupart des éditeurs / revendeurs matériel. Quand tu as une structure de 4L, c'est pas la peine de lui greffer un V12 Ferrari !