Juste pour rigoler

Salut,



Juste pour rigoler, parce que je viens de trouver une nouvelle base maintenue par des collègues d'une filiale.
Voici la requête que j'ai du faire :

Code:

---

1 2 3

select * from CODE0000TB where agrm_end_date >= to_char(sysdate,'YYYYMMDD')

---

Comme vous pouvez le voir, la modélisation est super bien faite, car les noms de tables est clair, et les colonnes sont parfaitement typées. ^^


Mais bon, en voyant ca ce matin, j'ai plutot eu envie de pleurer : toutes les tables de la base sont comme ca.


Bonne journée à vous.

Hum, c'est malheureusement fréquent, j'ai connu un site qui a modélisé toutes ses dates dans des colonnes décimal(9,0) 8O eh oui !
Autre joyeuseté : présence de colonnes identifier en clef primaire, avec obligation d'utiliser des accesseurs pour accéder aux tables, sauf que les accesseurs ne restituent pas l'identifier, les accès se faisant donc par .... des clefs sémantiques bien sur :D

Je vous laisse deviner ce qu'il en est des contraintes d'intégrité :roll:

Un vrai bonheur :aie:

J'ai le cas d'une application qui utilise un TimeStamp pour stocker la date... et un varchar(8) pour l'heure, une autre qui utilise un timestamp pour la date et un int pour l'heure. Toute les deux des applications du marché, une pour gérer les encaissement et une WMS.
Et une troisième (un ERP!) avec des tables C1, C2, D1, D4 (et d'autres plus parlantes, comme DTOSYN, EEC, GATSUI), chacune contenant des colonnes CE1 à CEx (x variant suivant la table, entre 1 et F ou G) en plus des colonnes "normales".
Evidemment, la colonne CE1 d'une table n'a pas forcément la même signification que la CE1 d'une autre table, les valeurs ne sont pas forcément comparables... tout un programme.

Et l'intégrité référentielle ? "On ne l'utilise pas, comme ça c'est plus souple on peut faire ce qu'on veut" dixit l'éditeur de l'une de ces applications. Les autres ont tenu à peu près le même discours.

Tatayo.

Bon sang !

Je vous tire mon chapeau pour ne pas craquer. :applo:

Pièce jointe 180801

Ouais alors...

Un ERP :
- Dates en VARCHAR(8) - YYYYMMDD
- Heures en VARCHAR(4) - HHMM
- Aucune table n'a de clé primaire (que des index uniques)
- Aucune table n'a de clé étrangère (de toute façon impossible à modéliser physiquement en l'état)
- Aucune "clé primaire" n'est composé de moins de 2 colonnes (généralement au moins 3)
- Aucune colonne de "clé primaire" n'est de type "simple" (int) mais uniquement des types complexes (decimal quand on a beaucoup de chances, varchar la plupart du temps)
- Les colonnes "blob" sont modélisées dans une table contenant 20 colonnes et un numéro de ligne (donc un blob de 500 Mo va se retrouver éclaté en 655360 lignes de 20 colonnes de 40 caractères, c'est hyper simple pour gérer les lectures/écritures dedans)
- Le moindre NULL dans une table fait planter le programme
- Les 9/10 des colonnes sont vides la plupart du temps (attention, ' ', pas de NULL !)

Et sinon, depuis quelques mois, je suis passé sur une CRM...
- Dates + heure en INT (YYYYMMDDHHmmSSffff)
- Les clés primaires sont des INT64 constitués d'une partie sur 16 bits (identifiant du PC qui a créé la ligne) et d'un compteur sur 32 bits. Donc pour s'y retrouver par rapport aux information à l'écran, faut se coltiner des décallages de bits dans tous les sens, un vrai bonheur.
- Aucune clé étrangère
- Les tables sont droppées puis recréées à chaque modification
- Les index sont crées automatiquement en fonction d'obscures règles sémantiques dans l'outils de modélisation... sans aucun rapport avec les besoins des requêtes. Evidement, le moindre index créé à la main est dégagé dès qu'on ouvre le programme en question.
- Les triggers sont shootés aussi de la même manière
- Les blobs sont stockés dans une unique table, compressés, donc pas indexables
- Les textes de l'ensemble de l'application (écrans, nom des tables, traductions des libellés produits, etc.) est stocké dans une unique table qu'il m'a fallu 2 semaines avant d'en comprendre les mécanismes, non documentés évidement (et jusqu'à présent, l'éditeur lui-même ne sais pas l'utiliser, genre pas moyen de faire une recherche dedans)

Bref... je continue ? :D

Ah, si, j'oubliais... La CRM est un produit germanique... Donc les noms des tables (sur deux lettres) et des colonnes (abréviations dont la règle m'échappe) sont en allemand, c'est hyper clair pour y retrouver ses petits :S

Qlq un pourrait m'expliquer pourquoi on fait ce métier déjà ? LOL