2011-05-17 2 views
2

Q:mise à jour une partie de la clé

Si j'ai un combiné clé composite à partir de 4 champs par exemple, puis-je mettre à jour l'un d'entre eux?

Je veux dire que je peux exécuter une instruction comme ceci:

UPDATE tb 
SET firstCol = '15', secondCol = 'test2' 
WHERE firstCol = '1' AND serial = '2'; 

Étant donné:

  • mon nom de la table est: tb
  • mes champs sont: firstCol, secondCol, serial
  • mes clés sont les suivants: firstCol , serial

Des suggestions? Ai-je manqué un concept?

merci.

+3

C'est le genre de question à laquelle on aurait répondu en essayant simplement, ce que vous aurez éventuellement à faire de toute façon. Pourquoi demandes-tu? –

+0

Je sais que je peux l'exécuter, je veux dire à partir de la vue logique, est-ce logique, et si oui l'exécution de phrase comme ceci peut causer des violations de contraintes? –

+3

Encore une fois, essayez-le. Soit ça marche, soit ça ne marche pas. Si ce n'est pas le cas, une question parfaitement bonne et raisonnable serait "pourquoi pas".La raison pour laquelle j'ai demandé «pourquoi demandez-vous» est que, plus souvent qu'autrement, les gens ne posent pas les vraies questions, ils essaient eux-mêmes de déduire la raison de leur situation, puis ils posent des questions à ce sujet. Voici un exemple: Quelqu'un at-il chargé le fusil de chasse? Après un peu de creusement, il s'avère que ce qu'ils auraient vraiment dû demander était "j'ai accidentellement tiré sur mon pied, pouvez-vous m'aider?". Essayez le SQL, voyez ce qui se passe, prenez-le pour un tour. –

Répondre

3

Vous pouvez rencontrer des problèmes de mise à jour si vous essayez de créer une ligne avec les mêmes valeurs comme une ligne existante. Peu importe ce que vous faites dans une mise à jour, la contrainte unique s'appliquera toujours.

Si vous avez des tables associées et que la mise à jour en cascade est activée, vous pouvez rencontrer des problèmes de verrouillage si de nombreux enregistrements doivent être verrouillés. Si vous n'avez pas activé la mise à jour en cascade, vous pouvez avoir des problèmes où un PK ne peut pas être changé jusqu'à ce que vous cassiez ces relations et les remettiez après avoir manuellement changé toutes les tables liées à la nouvelle valeur. Cette tâche, quelle qu'elle soit, ne doit être effectuée qu'en mode mono-utilisateur pendant les heures creuses. Personnellement, si vous avez besoin de changer le PK, la conception de votre base de données est fragile et peut poser des problèmes à l'avenir. Surtout avec une clé multicolonne. S'il s'agit d'un changement ponctuel et rare, allez-y et travaillez sur les problèmes. Sinon, il pourrait être temps de décider si avoir une clé de substitution comme PK et un index unique sur les multi-colonnes est un meilleur choix. Les PK multicolonnes créent des index beaucoup plus importants non seulement sur la table principale, mais aussi sur les tables enfant. Ils peuvent créer des problèmes complexes lorsque vous devez mettre à jour une des colonnes et avoir des implications sur les performances pour les jointures. En général, je ne suis pas fan d'eux. Et certainement pas si certaines de ces colonnes doivent être mises à jour avec n'importe quelle fréquence (et je veux dire toute grande mise à jour plus d'une fois par an - un ou deux enregistrements OK, mais si vous exécutez une mise à jour plus souvent que une fois par an, vous devez revoir le design à mon avis.).

4

Bien sûr, vous pouvez le faire, pourquoi? Avez-vous un problème avec cela?

3

Oui, vous pouvez. Cela peut faire partie de la clé, mais c'est toujours une colonne.

Remarque: Si vous utilisez des clés FK basées sur cette clé, vous devez prendre en compte les mises à jour CASCASE. En outre, une mise à jour de clé (en supposant qu'elle est en cluster) signifie plus de travail que "normal" en raison de la manière dont les index non clusterisés se réfèrent à la clé en clusters

Questions connexes