Deux clés étrangères référence à une table SUR la mise à JOUR de SET NULL ne fonctionne pas

J'en ai deux clés étrangères dans la table. Supposons que le tableau est appelé News et a les clés étrangères updatedById et createdById, qui pointe à userId dans le tableau Users.

Maintenant je veux mettre à NULL clés étrangères lorsqu'un utilisateur est supprimé, mais lorsque je tente de régler ON DELETE SET NULL dans les relations j'obtiens:

L'introduction de la contrainte de CLÉ ÉTRANGÈRE 'FK_News_Users' sur la table 'News' peut
cause de cycles ou de plusieurs en cascade des chemins. Spécifier on DELETE NO ACTION ou
On UPDATE NO ACTION, ou modifier d'autres contraintes de CLÉS ÉTRANGÈRES.

Je ne comprends pas pourquoi les deux clés étrangères ne pouvez pas définir la valeur null?

Pouvez-vous poster le complet SQL DDL pour la table "News" et les "Utilisateurs"?
Aussi la marque de la question avec le sgbd que vous utilisez. (SQL Server, Oracle, MySQL, PostgreSQL, etc.)
exemple de base de données: dl.dropbox.com/u/105509493/test.sql essayez de modifier la relation: FK_News_Users_updated - SUR SUPPRIMER pour Définir la valeur Null et économisez. Vous verrez que l'erreur.
Vous êtes donc en permettant aux orphelins News dossiers d'exister sans les propriétaires? Cela fait-il sens?
S'il vous plaît ne pas envisager d'en comprendre le sens, mais le problème. Ce tableau ne sont pas mes vraies tables, j'ai créé cet échantillon afin de simplifier le problème. Btw. cet exemple a un sens, parce que l'utilisateur peut être supprimé, mais la nouvelle doit le rester.
Normalement dans des situations de ce genre vous préférez supprimer l'utilisateur logiquement physiquement par l'introduction d'un indicateur (par exemple, Active ou Supprimés). De cette façon, toutes les relations rester intacte et peut être analysé de façon rétrospective.
très bonne idée, j'ai pensé aussi à ce sujet...

InformationsquelleAutor Wojciech Kulik | 2013-01-27

8

Plusieurs des Actions en Cascade

La série des référentielle en cascade les actions déclenchées par un seul
De SUPPRIMER ou de mise à JOUR doit former un arbre qui ne contient pas de circulaire
les références. Pas de table, peuvent apparaître plus d'une fois dans la liste de tous les
référentielle en cascade actions qui résultent de la SUPPRESSION ou mise à JOUR.
Aussi, l'arbre de la référentielle en cascade des actions ne doit pas avoir plus
qu'un seul chemin d'accès à n'importe quelle table spécifié. Toute une branche de l'arbre est terminé
lorsqu'il rencontre une table pour lesquelles AUCUNE ACTION n'a été spécifié ou
est la valeur par défaut.

Éventuellement dans des situations comme cela, vous pourriez envisager de mettre en œuvre la fonctionnalité de suppression d'un utilisateur logiquement plutôt que physiquement (par exemple, par l'introduction d'un indicateur Active ou Supprimé dans Users tableau). De cette façon, toutes les relations rester intacte et peut être analysé de façon rétrospective.

Mais si vous avez encore besoin de mettre en œuvre ON DELETE SET NULL pour les deux FK vous pouvez utiliser un FOR DELETE déclencheur sur User tableau comme ceci:
```
CREATE TRIGGER Users_News_Delete_Trigger 
ON Users FOR DELETE
AS BEGIN
    UPDATE News SET createdById = NULL 
     WHERE createdById = DELETED.id;
    UPDATE News SET updatedById = NULL 
     WHERE updatedById = DELETED.id;
END
```
- Oui, j'ai pensé également sur les déclencheurs, mais pourriez-vous expliquer pourquoi ces contraintes, que j'ai essayé de créer ne fonctionne pas?
- Vous pouvez la lire here
- Voir aussi mis à jour la réponse
- "Normalement dans des situations comme cela, vous feriez mieux de mettre en œuvre la fonctionnalité de suppression d'un utilisateur logiquement plutôt que physiquement (par exemple, par l'introduction d'un indicateur Active ou Supprimé dans la table des Utilisateurs)." ce pourrait être une bonne idée dans certaines applications. Ce n'est pas une bonne idée dans chaque application. ON DELETE SET NULL et ON DELETE CASCADE existent pour une raison.
- C'est strictement la qualité de mise en œuvre de problème. D'autres plates-formes de poignée de votre scénario correctement, définissant à la fois le référencement des valeurs NULL. Par exemple, PostgreSQL.
- pas une bonne idée dans chaque application. je ne vais pas argumenter avec ça. Mais la question a présenté un scénario très spécifique, où, après la suppression d'un utilisateur, vous perdez l'information sur qui a créé et/ou de nouvelles mises à jour. Et dans ce scénario particulier(s) à mon humble avis qui n'est pas un meilleur choix.
- Clés étrangères a déclaré on delete set null, la suppression de l'information est exactement de l'action le concepteur de base de données, il a été décidé approprié. C'est pourquoi les deux on delete set null et on delete cascade existent--pour supprimer l'information--et pourquoi ils ont fait partie de la norme SQL depuis 1992. (Et ce ne sont pas les OP de vraies tables. La question n'est pas de savoir si on delete set null est approprié. La question est de savoir pourquoi il ne parvient pas, dans ces circonstances, dans SQL Server.)
- Pourquoi il se produit dans SQL Server et comment, éventuellement, pour remédier à cela, si l'OP veut, à mon humble avis ont été fournis dans la réponse. BTW d'intégrité référentielle en cascade vérifie dans SQL Server existent pour une raison. Mais je vous remercie pour vos commentaires si. J'ai même changé le libellé de la réponse au sujet de la conception proposée pour cette question.
- Merci beaucoup les gars pour des explications et de l'aide! De la bière pour vous ;-)!
- Bonjour, j'ai eu à utiliser un au LIEU DE SUPPRIMER le déclencheur de le faire POUR SUPPRIMER signifiait toujours le FK contrainte empêché l'original de la supprimer.
- SQL server devs simplement le plus paresseux de l'entreprise, ou le plus incompétent, qu'ils ne pouvaient pas comprendre comment mettre en œuvre cette? Peut-être les deux?
InformationsquelleAutor peterm
3

Une alternative est de créer une table de concordance entre les tables A et B, où chaque entrée est A. ID et B. ID et B. ID est une clé étrangère vers B. Ensuite, vous pouvez simplement les suppressions en CASCADE à la référence croisée. Vous aurez besoin de mettre un troisième champ dans votre renvoi à l'etat le but unique de référence tels que
```
[NewsID] INT NOT NULL DEFAULT 0,
[UsersID] INT NOT NULL DEFAULT 0,
[IsCreatedBy] bit NOT NULL DEFAULT 0
```
Naturellement, vous devez ensuite prendre ces champs de la table A. La jointure gauche vous donnera alors la valeur null pour ces champs si ils sont absents.
- Mon professeur d'université qui a couvert la normalisation de la théorie vous salue.
InformationsquelleAutor Park
1

Je ne pense pas que c'est possible (SQL Server) afin de le faire sur 2 ou plusieurs contraintes FK sur la même table, pointant vers la même FK.

Normalement dans des situations de ce genre vous préférez supprimer l'utilisateur logiquement physiquement par l'introduction d'un indicateur (par exemple, Active ou Supprimés). De cette façon, toutes les relations rester intacte et peut être analysé de façon rétrospective.
--- peterm

Si vous voulez coller avec l'idée originale de paramètre NULL, une façon de contourner le problème serait de gérer votre suppression d'utilisateurs dans une procédure stockée et faire effectuer les mises à jour immédiatement après.
```
CREATE PROCEDURE sp_DeleteUser 
    @UserId INT
AS
BEGIN
    SET NOCOUNT ON;

    DELETE FROM Users WHERE Id = @UserId;

    UPDATE News SET created_byId = NULL WHERE created_byId = @UserId;

    UPDATE News SET updated_byId = NULL WHERE created_byId = @UserId;
END
GO
```
- "je ne pense pas que c'est possible de le faire sur 2 ou plusieurs contraintes FK sur la même table, pointant vers la même FK." Juste pour être clair, il est possible en SQL. C'est juste pas possible dans SQL Server.
- Bon point - modifié réponse.
InformationsquelleAutor PeteGO

Vous devez vous connecter pour publier un commentaire.