Discussion :

[grome]

Bonjour,

Voilà je suis aujourd'hui DBA débutant pour une structure disons importante et dans ce cadre j'administre des bases de données oracle. J'ai été très surpris avec l'une de ces bases de données. Cette base comporte quelques 1200 tables et index. Pas une seule clé, pas de contraintes bref le néant. Cette base est le support d'un gros produit (de gestion) bien cher et développé par un éditeur bien connu (je n'en dirai pas plus je n'ai pas envie de perdre mon job).

Est ce que vous avez déjà été confronté à ce genre de base de données ?
Est ce que cette manière de construire une base est une pratique courante ?
Je n'arrete pas de me dire que si elle est construite comme cela c'est qu'il y a une raison, je cherche mais je trouve pas...

Merci de vos témoignages.

Jérôme

[Mathusalem]

j'ai toujours vu ça aussi dans des très grosses boites (Finance). ça fait drôle effectivement quand on sort de l'école

pas de modèle cohérent, pas de MCD, formes normales connait pas (genre plusieurs infos dans le même champ), jamais de clé primaire.

après quand ça rame "ben on va ptête créer des index" et nous voila avec 10 index selon différentes combinaisons de champs.


la raison principale, c'est que la base n'est pas au centre du dev des applications comme on l'apprend à l'école, les équipes de dev font leurs cuisines dans leurs coins. Quand on a besoin de faire communiquer 2 applis, ils créent des tables / vues spécifiques entre leurs "modèles", des traitements sont refaits 2 ou 3 fois de manière différentes (typiquement des VWAP), ...

Quand un problème global se présente (la MiFID actuellement), on refond certaines tables proprement, on ajoute des colonnes à droite à gauche pour que ça fonctionne sur les anciennes appli et on ne touche plus à rien quand ça marche



Pour te dire à quel point c'est catastrophique, dans un grand établissement financier à Paris, j'ai dû faire du Matlab, pour extraire des flux de données marché super courantes (tick db si ça te parle) afin de pouvoir en faire qqch en SQL...


J'espère que d'autres ont de meilleurs expériences que moi, j'ai toujours vu les BD sur le terrain comme un sac de nœud dont personne n'a un schéma précis.

[al1_24]

Bienvenue dans le monde réel

Le discours des développeurs de ces produits est le suivant :

La vérification des contraintes est effectuée dans l'application, il n'est donc pas nécessaire de la reproduire dans la base de données, cela ferait double emploi.
Par ailleurs, les index sont coûteux en volume et en temps de mise à jour.

Je continue donc à développer mes applications de gestion avec un SGBDR que j'utilise comme un conteneur de fichiers séquentiels, avec des procédures stockées et des boucles sur des curseurs....

[SQLpro]

Je rajoute qu'actuellement étant en train de donner un cours de modélisation chez Orsys.... C'est exactement le discours que je tiens à mes stagiaires... C'est aussi ce qu'eux même ont déjà constaté avant de venir à cette formation !!!

A +

[grome]

Bon ok ben je vais m'amuser pour optimiser les perfs...

C'est quand même dingue, je comprends un peu mieux mais je suis toujours autant surpris bref...

Et effectivement il y a beaucoup beaucoup d'index (trop ?)...

[SoBaKa]

je commence à me dire que ça doit être la même chose partout la

j'ai commencé comme développeur .net/sql dans une boite de taille moyenne et quand j'ai vu le foutoir qu'a fait le département IT avec les bases de données c'est hallucinant...

Je rajouterais aussi qu'il y a le problème du nom des champs d'une table pour l'id par exemple, pour certaines tables c'est juste 'id', pour d'autres 'table_id' ou encore 'tableId'... et heureusement que ce n'est pas case sensitive (Ah la joie de faire des jointures quand déjà tu t'y retrouves pas dans les noms des tables et qu'ensuite c'est les noms des champs qui te rende fou...)

[grome]

Ben moi j'avais jamais vu çà ni entendu parler de cette manière de procèder. j'ai fait du dév j'ai un éditeur de soft parisien et bien nous étions assez pointu côté oracle sur
1 - l'archi de la base
2 - l'optimisation des requêtes et leur écritures.
bref très school spirit si je peux dire...

J'ai été jusqu'à regarder les requêtes que l'appli lance sur la base et j'ai vu des choses que je n'avais vu avant. Je me dis qu'il y a surement une raison pour que les requêtes soit écrites comme çà ... mais çà fait drôle surtout de la part d'un editeur de cette envergure. Enfin c'est comme çà

je commence à me dire que ça doit être la même chose partout la

j'ai commencé comme développeur .net/sql dans une boite de taille moyenne et quand j'ai vu le foutoir qu'a fait le département IT avec les bases de données c'est hallucinant...

Je rajouterais aussi qu'il y a le problème du nom des champs d'une table pour l'id par exemple, pour certaines tables c'est juste 'id', pour d'autres 'table_id' ou encore 'tableId'... et heureusement que ce n'est pas case sensitive (Ah la joie de faire des jointures quand déjà tu t'y retrouves pas dans les noms des tables et qu'ensuite c'est les noms des champs qui te rende fou...)

[SoBaKa]

J'ai été jusqu'à regarder les requêtes que l'appli lance sur la base et j'ai vu des choses que je n'avais vu avant. Je me dis qu'il y a surement une raison pour que les requêtes soit écrites comme çà ...

Oui, il y a une raison... pas forcément une bonne raison mais la seule raison c'est que ça fonctionne... c'est malheureux mais c'est comme ça...

[Keihilin]

Cette base est le support d'un gros produit (de gestion) bien cher et développé par un éditeur bien connu (je n'en dirai pas plus je n'ai pas envie de perdre mon job).

oh tu n'as pas besoin de dire le nom de l'éditeur...Ceux qui l'ont déjà croisé l'auront reconnu tout de suite

[voyageur]

Je vois que je ne suis pas le seul a constater la difference entre ceux qui est enseigné en theorie et ce que l'on voit sur le terrain.
On se retrouve dans des situations ou l'on doit bidouiller a droite a gauche pour optimiser les perf faute de pouvoir toucher au modele qui tourne depuis deja plusieurs annees comme ca.
Moi aussi je travaille sur de grosses bases de données dans la Finance et ce que l'on peut voir est asez hallucinant ( pas de relations entre les tables, des tables sans clé primaires etc....)
Je n'est toujours pas trouvé la raison de cette facon de modeliser les tables, a mon avis c'est pour gagner du temps et ne pas avoir a gerer les problemes qui pourrait survenir sur la bd ( juste à gerer l'applicatif).

[dgi77]

Chers amis, qui avaient appris à l'école ce qu'étaient une clé primaire, une clé étrangère, un index, une forme normale, et j'en passe... dites vous bien, si vous ne l'avez pas encore constaté, que nous sommes en minorité dans ce cas dans notre profession.
Tant que les décideurs et les recruteurs, côté clients comme côté SSII, n'auront pas compris que l'informatique est un vrai métier et pas seulement une vitrine bureautique/multimédia très alléchante et accessible à tous, qui à ce titre nécessite une formation, tant qu'ils recruteront des pseudos-scientifiques (dans le meilleur des cas), mais aussi des économistes, des juristes, restés sur le carreau dans leur branche, pour faire notre métier, tant que ces décideurs et nos chefs de projets seront eux-mêmes issus de filières non-informatiques, nous passerons derrière des gens qui font de la merde à l'insu de leur plein gré...