Discussion :

[mamadoukebe]

Bonjour ! J'ai une question.
Je suis entrain de visualiser une base de données de gestion commerciale avec 69 tables. Ce qui m'étonne les tables non aucune relation clé primaire et secondaire entre elles. Sauf que j'ai remarqué une chose, il y'a un champs idnServer de type varchar, dans chacune des tables. Je me demande es ce logique de créé une base comme ça ? Et comment fait-ont pour gérer les intégrité? Et que représente le champs qui se retrouve dans tous les tables ?

[StringBuilder]

Non, il ne faut pas faire ça.

Ça tombe bien, 99% des logiciels du marché ont des bases ainsi modélisées...

Et 99% ont des problèmes aberrants de performance et des bugs monstrueux liés à ces modélisations bancales.

Mais 100% ont toujours de bonnes raisons pour expliquer pourquoi ils ont fait comme ça.

[mamadoukebe]

Ah OK ! Je comprends. Mais je me dis, si on a une assez volumineux avec jusqu'à 90 tables en relation par exemple, en cas de modification ou d'ajoute de nouvelles . Sa peut poser des problèmes oubien je me trompes ?

[StringBuilder]

Ajouter de nouvelles tables ne pose pas plus de problèmes que ce soit correctement modélisé ou non : dans tous les cas, il faudra repartir modifier dans le programmes les requêtes impactées.

Le seul cas qui peut vraiment poser souci, c'est quand on a un modèle des données à "géométrie variable".
C'est le cas des ERP notamment.
En effet, parfois, dans une même base de données, selon le paramétrage (global ou pour un périmètre déterminé) on a des contraintes d'intégrité différentes, notamment les clés.

Par exemple, dans un ERP que je connais bien Aurea Collaborative Entreprise (anciennement Generix), on a une notion de "société". Un groupe peu stocker dans la même base de données toutes les entités du groupe, avec chacune ses propres règles de gestion. Ainsi, on peut se retrouver avec la table produit où toutes les lignes de produits sont les mêmes pour l'ensemble des entités d'une branche, tandis que les produits des autres entités des autres branches ont sont spécifiques à chaque entité.
A ce moment, le code société qui fait partie de la clé primaire sera tantôt identique au numéro de société des commandes dans lesquelles ont va les mettre, tantôt différent.
Ainsi, modéliser en conservant les mêmes tables deviendrait un véritable casse-tête, c'est pourquoi les relations entre table ne sont pas modélisées.
Dans l'absolu, les tables produit et commande devraient être différentes selon l'un ou l'autre des modes de gestion.

On comprend vite alors que ça pourrait devenir très complexe a gérer... d'où ces libertés que prennent les différents éditeurs. Le problème, c'est que ça se fait au dépends des performances, mais aussi parfois de la stabilité globale de l'outil.

[mamadoukebe]

Ah ok merci pour ces détails. Mais j'aimerais suivre une logique propre qui pourras me faciliter et faire moins de dépendance possible. Qu'elle méthodeme conseillerais vous?

[Mat.M]

Bonjour ! J'ai une question.
Je suis entrain de visualiser une base de données de gestion commerciale avec 69 tables. Ce qui m'étonne les tables non aucune relation clé primaire et secondaire entre elles. Sauf que j'ai remarqué une chose, il y'a un champs idnServer de type varchar, dans chacune des tables. Je me demande es ce logique de créé une base comme ça ? Et comment fait-ont pour gérer les intégrité? Et que représente le champs qui se retrouve dans tous les tables ?

salut Mamadoukebe c'est un problème très classique des bases de données et donc des SGBDR.

S'il n'y a pas de liaison entre les tables c'est parce qu'en mettant des liaisons , au moment où on insert ou met-à-jour des données dans une table et que les références correspondantes ( donc liaisons étrangères ) ne sont pas mises à jour il va y avoir un message d'erreur.
Donc ce programme de gestion commerciale gère mal les erreurs

[SQLpro]

Les éditeurs qui font cela ont oublié aussi que les bons SGBDR comme Oracle ou SQL Server sont capable de simplifier les plans d'exécution des requêtes si les contraintes d'intégrité référentielles existent (clefs étrangères).

Je montre en cours d'optimisation, comment une requête va 500 fois plus vite si l'on ajoute les intégrités référentielles !!!

A +

[mamadoukebe]

Merci beaucoup SQLpro. Je crois que je vais rester sur ma voix de l'intégrité référentiel. Même si c'est fatiguant 😊

[SQLpro]

Pourquoi serait-ce fatiguant ?

Si c'est pour insérer des données primales, une technique - afin de ne pas se poser de question sur la précédence - est de désactiver les contraintes d'intégrité référentielle avant d'insérer massivement les données et de les réactiver à la fin.

Si vous utilisez MS SQL Server ceci ce fait avec une commande du genre ALTER TABLE … NOCHECK CONSTRAINT ALL

Pour le faire globalement en une seule instruction dans toute la base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXEC sp_MSforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

A +

[escartefigue]

Avec DB2 for Z/OS, les contraintes peuvent être désactivées sur la table, mais également désactivées au moment du chargement avec l'utilitaire LOAD et l'option ENFORCE NO.

Ceci permet de paralléliser le chargement de plusieurs tables indépendamment des contraintes qui seront vérifiées ultérieurement par un CHECK DATA

[SQLpro]

Avec DB2 for Z/OS, les contraintes peuvent être désactivées ... au moment du chargement avec l'utilitaire LOAD et l'option ENFORCE NO.

Ceci permet de paralléliser le chargement de plusieurs tables indépendamment des contraintes qui seront vérifiées ultérieurement par un CHECK DATA

Même chose dans SQL Server. les contraintes CHECK et FOREIGN KEY sont désactivées par défaut lors de chargement par BULK INSERT ou via bcp.exe (ligne de commande).
On peut cependant en forcer l'activation avec l'option de commande CHECK_CONSTRAINTS
Même chose pour les triggers, ils ne sont pas joués par défaut sauf si FIRE_TRIGGERS

A +