Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Une base de données avec beaucoup de tables sans relations. Est-ce logique ?
    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 ?

  2. #2
    Expert éminent
    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.
    On ne jouit bien que de ce qu’on partage.

  3. #3
    Membre à l'essai
    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 ?

  4. #4
    Expert éminent
    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.
    On ne jouit bien que de ce qu’on partage.

  5. #5
    Membre à l'essai
    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?

  6. #6
    Expert éminent sénior
    Citation Envoyé par mamadoukebe Voir le message
    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
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  7. #7
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  8. #8
    Membre à l'essai
    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 😊

  9. #9
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  10. #10
    Expert éminent sénior
    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

  11. #11
    Rédacteur

    Citation Envoyé par escartefigue Voir le message
    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

###raw>template_hook.ano_emploi###