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. #41
    Rédacteur

    Citation Envoyé par SergioMaster Voir le message

    Nobody's perfect sauf peut-être MS SQL cher à SQLPro ...
    non, non, il a aussi ses tares.... la contrainte d'unicité qui ne prend en compte qu'un seul NULL !!!!

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  2. #42
    Expert éminent sénior
    Citation Envoyé par Paprick Voir le message
    Le passage par l'étape MCD éviterait par ailleurs ce que je considère comme un gros problème au niveau relationnel : en effet, il est souhaitable pour une meilleure utilisation de la BD que les noms des clés primaires et étrangères soient les mêmes ; mais pour cela, il faut que chaque clé primaire ait un nom unique pour tout le schéma relationnel et que ce nom soit significatif quand il se trouve dans une autre table en tant que clé étrangère (et éviter de se retrouver avec "NUM" partout !). Dans l'exemple ci-dessus, ID_HEINDIC et ID_AFFECTION seraient de bons nom d'identifiants.
    A suivre !
    Tout à fait d'accord, La chasse aux homonymes et aux synonymes est une étape salutaire de la modélisation, elle évite les confusions et bon nombre d'erreurs.


    Citation Envoyé par SergioMaster Voir le message
    Juste un truc
    Les trous n'interdisent en rien l'intégrité référentielle (selon moi)
    Absolument ! Et fort heureusement, sinon Les COMMIT seraient obligatoires et les DELETE seraient interdits

###raw>template_hook.ano_emploi###