Discussion :

[escartefigue]

Autre petite perle, plutôt rare : j'ai un client qui a tout simplement interdit l'utilisation du type integer dans ses bases de données
L'argument de poids : c'est plus simple (dixit les responsables des normes internes !)
Je n'ai pas compris pourquoi ils n'interdisent pas aussi les formats date, decimal et autres, après tout le char c'est bien suffisant...

Et bien sur, chez ce cumulard, aucune contrainte d'intégrité, des PK de format char, des tables monstrueusement obèses et toutes autres joyeusetés habituelles d'un classicisme navrant

[Invité]

Autre petite perle, plutôt rare : j'ai un client qui a tout simplement interdit l'utilisation du type integer dans ses bases de données

Tu veux dire qu'ils stockent les entiers dans des varchar ? Ça doit travailler fort dans le transtypage lors des traitements...

[François DORIN]

Tu veux dire qu'ils stockent les entiers dans des varchar ?

Des NVARCHAR(MAX). Sinon ce n'est pas drôle...

[escartefigue]

J'aurais voté pour un blob perso, mais bon

[Invité]

Des NVARCHAR(MAX). Sinon ce n'est pas drôle...

SAP a fait ça à une époque avec les clefs primaires, FK et autres...
« Pourquoi ma bd est si énorme ? Pourquoi j'ai besoin d'autant de RAM... »
Un bonheur !

[FMJ]

Je ne suis pas consultant en DB, me suis formé sur le tas pour tout ce qui touche au relationnel, et n'ai donc quasiment aucun recul sur ce qui se fait ailleurs. Tout juste ai-je une petite idée du "best practice".
Pour autant, je suis très perplexe par rapport à toutes ces "pépites" mentionnées. Elles laissent la désagréable impression que le MDB et l'optimisation des bases sont laissés aux bons soins des RH ? Ou du marketing.......? Enfin à tous services, sauf celui qui serait sensé détenir quelques compétences en la matière ! C'est tout de même incroyable !
Mon coeur de métier, c'est le réseau/télécom. Là j'ai un meilleur recul sur ce qui se fait. Eh bien j'ai l'impression qu'en règle général, c'est beaucoup plus carré. Il faut aussi dire que dans ce domaine, soit ça marche, soit ça marche pas (ou très mal). C'est un peu plus binaire.

[François DORIN]

Je ne sais pas pour SAP, mais il arrive souvent que des gros projets commencent par des proof of concept développé à la va vite par un stagiaire (ça coûte pas cher), voir par plusieurs stagiaires d'affilé. Si c'est concluant, le projet démarre... mais à partir de l'existant au lieu de repartir sur des bases saines. Et après, les dettes techniques s'accumulent...

[FMJ]

Cela m'est quelque fois arrivé sur de petits devs : tu ne prends pas la peine de faire un cahier des charges précis, englobant toutes les fonctionnalités nécessaires et les contraintes, tu commences par développer "à vue" ce dont tu as un premier besoin, et puis au fur à mesure du temps ça grossit au point d'arriver à pieuvre dont les tentacules se mordent mutuellement la queue.
Mais de là ce que cela se passe de la même façon sur un "vrai".....

[escartefigue]

D'après mon expérience, ces états de fait sont surtout causés par la méconnaissance des enjeux, méconnaissance qui conduit à la négligence dans la formation des personnes en charge et par un temps et des charges allouées à la partie étude et modélisation, réduits comme peau de chagrin.
Plutôt que d'investir les sommes nécessaires en début de projet, on dépense des fortunes en CPU et espace disque pour pallier aux défauts de conception.
C'est ainsi

[Invité]

Pour le SAP, ça a été des nvarchar(max) sur des clefs pour une version.
De ce que j'ai vu du modèle, je pense que le développement s'est fait pour une autre SGBD (Sybase, Oracle ?) et que la conversion vers MS Sql Server s'est faite à l'arrache pour un client et s'est ensuite retrouvée comme une version de prod.
Ça a été corrigé pour les versions suivantes.
Mais bon, quand on voit SAP HANA qui demande une quantité faramineuse de RAM de base, il y a quand même des trucs pas propres là-dedans...

[iberserk]

Sans parler de l'utilisation massive de GUID dans leur base de données chez certains "architectes" .NET.

Pas plus tard qu'il n'y a pas longtemps j'ai vu une table avec une colonne "ETAT" de type UNIQUEIDENTIFIER pour représenter le OK/KO!!!
16 octets contre un bit....

Enjoy

[FMJ]

Pour un développeur, une BD est un outil comme un autre. Qui a l'idée d'optimiser ou de tuner un composant ou une librairie ? Il n'y a généralement pas de concept de performance derrière. On s'en préoccupe tout à la fin, quand l'utilisateur est devant sa GUI.

[iberserk]

Pour un développeur, une BD est un outil comme un autre. Qui a l'idée d'optimiser ou de tuner un composant ou une librairie ? Il n'y a généralement pas de concept de performance derrière. On s'en préoccupe tout à la fin, quand l'utilisateur est devant sa GUI.

Un développeur peut-être et encore mais un architecte...

[FMJ]

Encore faudrait-il qu'il y ait eu un architecte, comme disait si bien Escartefigue un peu plus haut. Tout responsable de projet n'est pas forcément convaincu de son utilité ...

[olivtone]

CRM produit purement microsoft

Table principale : 192 colonnes, CRM crée 47 Index par défaut sur cette table....

Bien sur la PK Clustered est un GUID

12 millions de lignes, 15 Go D'index...

3/4 des index ne sont pas utilisés, mais défense absolu de supprimer les index car ce n'est pas supporté par Microsoft...

C'est tout juste magnifique

[FMJ]

Oui mais le produit a été designé avant qu'ils ne rachètent Sybase et ne créent SQL Server
Enfin, faut espérer !

[al1_24]

J'ai travaillé il y a peu sur une application où les évolutions de la base de données (ajout de tables ou colonnes) étaient effectuées par les développeurs Java sur demande des équipes fonctionnelles, avec avis consultatif des DBA durant la phase de recette.
D'où ce type d'échange :

• DBA : Avec cette structure, ça ne va pas être bon en temps de réponse. Voici la bonne manière de faire (normalisation, tables filles, ...)
• DEV : Tout est déjà développé ; on ne va pas revenir dessus.
• Exploitation : Ça rame. Qui est le DBA qui a conçu cette base ?

[FMJ]

Ah au fait, j'allais oublier (tant qu'à balancer ... autant balancer !)
Une petite précision sur la méthodologie de mise à jour dans cet ERP. Sa colonne vertébrale s’articule essentiellement autour de 2 tables regroupant d'un côté les pièces et de l'autre les lignes contenues dans ces pièces (la fameuse table à 10^6 colonnes). Jusqu'à là, rien d'extraordinaire. Ce qui est amusant, c'est de regarder ce qu'il se passe lorsque l'on modifie une valeur d'une seule ligne d'une pièce. Eh bien l'ERP supprime purement et simplement TOUTES les lignes de la pièce pour TOUTES les recréer ... à l'identique, en ne modifiant que la valeur qui avait changé. Sachant que certaines pièces contiennent plus de 1000 lignes ... de 250 colonnes ! C'est pas beau la vie ???!!! Bref, bonjour au revoir les indexes, les stats et tout le toutim. Tant qu'à faire, autant faire l'économie d'une licence SQL Server et se servir de fichiers à plat ......

[iberserk]

CRM produit purement microsoft

Table principale : 192 colonnes, CRM crée 47 Index par défaut sur cette table....

Bien sur la PK Clustered est un GUID

12 millions de lignes, 15 Go D'index...

3/4 des index ne sont pas utilisés, mais défense absolu de supprimer les index car ce n'est pas supporté par Microsoft...

C'est tout juste magnifique

J'ai bossé 4 ans sur les ERP dynamics AX et NAVISION, plus rarement sur CRM...
En revanche je n'hésitais pas à réaliser l'étude d'indexation complète: ajout suppression etc. Microsoft ou pas...
NOus tenions simplement à jour la liste exhaustive de ces modifications afin de pouvoir les fournir en cas d'audit et les repasser en cas de montée de version