La validation de la mise à JOUR et INSERT à l'encontre de l'ensemble de la table

Je suis à la recherche de la meilleure façon d'aller sur l'ajout d'une contrainte à une table qui est effectivement un index unique sur la relation entre l'enregistrement et le reste des enregistrements dans cette table.

Imaginez le tableau suivant décrivant les patrouilles de divers gardes (à partir de la précédente veilleur de scénario)

PK  PatrolID Integer
FK  GuardID  Integer
    Starts   DateTime
    Ends     DateTime

Nous commençons avec une contrainte spécifiant que le début et la fin des temps doit être logique:

Ends >= Starts

Cependant je veux ajouter une autre logique de contrainte: Une garde (GuardID) ne peut pas être à deux endroits en même temps, ce qui signifie que pour n'importe quel enregistrement de la période fixée par Démarrer/fin devrait se chevauchent pas avec la période définie pour tout autre patrouille par le gardien.

Je pense à deux façons d'essayer d'approcher ce:

Créer un déclencheur INSTEAD OF INSERT. Ce déclencheur serait alors utiliser des curseurs pour passer à travers la table INSERTED, en vérifiant à chaque enregistrement. Si un enregistrement en conflit avec un enregistrement existant, une erreur serait soulevée. Les deux problèmes que j'ai avec cette approche sont: je n'aime pas utiliser les curseurs dans une version moderne de SQL Server, et je ne suis pas sûr de la façon d'aller sur implimenting la même logique pour les Mises à jour. Il peut aussi y avoir de la complexité des dossiers à l'intérieur INSÉRÉ conflit les uns avec les autres.

Le second, apparemment mieux, approche serait de créer une CONTRAINTE qui appelle une fonction définie par l'utilisateur, en passant la PatrolID, GuardID, Commence et se Termine. La fonction serait alors de faire une OÙ il EXISTE requête de vérification de tous les dossiers qui se chevauchent les GuardID/Commence/Termine les paramètres qui ne sont pas l'original PatrolID enregistrement. Cependant, je ne suis pas sûr de ce que les effets secondaires potentiels de cette approche pourrait avoir.

Est la deuxième meilleure approche? Personne ne voir aucun des écueils, tels que lors de l'insertion/mise à jour de plusieurs lignes à la fois (ici, je suis préoccupé parce que les lignes à l'intérieur de ce groupe pourrait entrer en conflit, sens de l'ordre, ils sont "insérés" fait une différence). Est-il une meilleure manière de faire ceci (comme certains de fantaisie INDICE de truc?)

OriginalL'auteur David | 2009-06-18

  1. 5

    Utiliser un déclencheur after pour vérifier que le chevauchement de la contrainte n'a pas été violé:

    create trigger Patrol_NoOverlap_AIU on Patrol for insert, update as
    begin
    if exists (select *
        from inserted i
        inner join Patrol p
            on i.GuardId = p.GuardId
            and i.PatrolId <> p.PatrolId
        where (i.Starts between p.starts and p.Ends)
        or (i.Ends between p.Starts and p.Ends))

        rollback transaction
    end

    REMARQUE: l'annulation d'une transaction à l'intérieur d'un déclenchement de résilier le lot. Contrairement à une contrainte normale violation, vous ne serez pas en mesure de rattraper l'erreur.

    Vous souhaitez peut-être une autre clause where, selon la façon dont vous définissez l'intervalle de temps et se chevauchent. Par exemple, si vous voulez être en mesure de dire de la Garde #1 est au X à partir de 6:00 à 7:00 puis Y de 7:00 à 8:00 le ci-dessus ne permettrait pas. Vous voulez à la place:

    create trigger Patrol_NoOverlap_AIU on Patrol for insert, update as
    begin
    if exists (select *
        from inserted i
        inner join Patrol p
            on i.GuardId = p.GuardId
            and i.PatrolId <> p.PatrolId
        where (p.Starts <= i.Starts and i.Starts < p.Ends)
        or (p.Starts <= i.Ends and i.Ends < p.Ends))

        rollback transaction
    end

    Où Commence le temps de la garde commence et se Termine est l'infiniment petit moment après le gardiennage se termine.

    OriginalL'auteur Shannon Severance

  2. 3

    La façon la plus simple serait d'utiliser une procédure stockée pour les plaquettes. La procédure stockée peut faire l'insérer dans une seule instruction:

    insert into YourTable
(GuardID, Starts, Ends)
select @GuardID, @Starts, @Ends
where not exists (
    select *
    from YourTable
    where GuardID = @GuardID
    and Starts <= @Ends
    and Ends >= @Start
)

if @@rowcount <> 1
    return -1 -- Failure

    Dans mon expérience, les déclencheurs et les contraintes de l'UDF, ont tendance à devenir très complexe. Ils ont des effets secondaires qui peuvent exiger beaucoup de débogage à la figure.

    Procédures stockées travail juste, et ils ont l'avantage que vous pouvez refuser l'INSERTION d'autorisations pour les clients, vous donnant un contrôle plus fin sur ce qui entre dans votre base de données.

    Les déclencheurs sont nécessaires pour ce type de chose que les enregistrements peuvent être insérés à partir d'autres lieux que le proc. Si vous n'imposez pas au niveau de déclenchement, vous ne pouvez pas guarnatee l'intégrité des données.
    Ainsi, c'est pourquoi personne ne se INSÉRER des droits de l'.

    OriginalL'auteur Andomar

  3. 1
    CREATE TRIGGER [dbo].[emaill] ON [dbo].[email]
FOR INSERT

AS

BEGIN


    declare @email CHAR(50);


    SELECT @email=i.email from inserted i;

    IF @email NOT LIKE '%_@%_.__%' 
    BEGIN
            print 'Triggered Fired';
            Print 'Invalid Emaill....';
            ROLLBACK TRANSACTION
    END 

END

    OriginalL'auteur ketan