Est-ce la bonne façon de créer SQL affirmation?

Pour plus de détails sur CREATE ASSERTION voir l'ISO de la Norme SQL-92 spec.

La CHECK définition devrait être entre parenthèses.

CURRENT_DATE n'a pas de parenthèses.

USER et DATE sont des mots réservés.

SQL doit être terminé par un caractère point-virgule.

SQL mots-clés doivent être en majuscules.

Essayer quelque chose de plus comme ceci:

CREATE ASSERTION assert  
CHECK (0 = (
            SELECT COUNT(*)  
              FROM Video  
             WHERE my_date = CURRENT_DATE  
             GROUP 
                BY my_user
            HAVING COUNT(*) >= 10
           ));

Vous pouvez vérifier que la syntaxe est correcte à l'aide de la ligne Mimer SQL-92 Validateur. Cependant, vous devez également tester votre logique par exemple CURRENT_DATE est non-déterministe.

Aussi, je ne pense pas que ce ASSERTION sera jamais à mordre. Lorsque la cardinalité de la sous-requête est inférieur à 10, il sera de retour à zéro des lignes et des 0 = empty set permettra d'évaluer à UNKNOWN. Lorsque la cardinalité de la sous-requête est de 10 ou plus grande que la condition de recherche permettra d'évaluer TRUE. Norme SQL-92 états

L'affirmation n'est pas satisfaite si et
seulement si le résultat de l'évaluation de la
recherche condition est fausse.

Remarque: vous pouvez remplacer votre CHECK (0 = (SELECT COUNT(*) FROM...)) construire avec CHECK (NOT EXISTS (SELECT * FROM...)), dont le dernier je trouve plus facile à écrire.

---

Mise à JOUR:

Comment dois-je écrire l'affirmation à l'aide de
CASE N'EXISTE PAS ?

Comme je l'ai dit ci-dessus, votre logique semble erronée, il est difficile de mettre en œuvre correctement 😉

Disons que la règle est de limiter les Vidéos de 10 par utilisateur et par jour. Car cela implique un seul tableau, il serait plus approprié d'utiliser une table de niveau CHECK contrainte; cette contrainte est vérifiée lorsque le tableau est mis à jour, ce qui est suffisant dans ce cas (il n'y a aucune raison pourquoi il ne peut pas être un ASSERTION, bien que, en théorie, pourrait être vérifié à chaque fois tout table dans le schéma est mis à jour):

ALTER TABLE Video ADD 
   CONSTRAINT video_limit_10_per_user_per_day
      CHECK (NOT EXISTS (
                         SELECT v1.my_user, v1.my_date
                           FROM Video AS V1
                          GROUP BY v1.my_user, v1.my_date
                         HAVING COUNT(*) > 10
                        ));

---

Mise à JOUR 2:

merci,maintenant, disons que nous voulons limiter
vidéos de 100 par utilisateur et par an, dans
ce cas à l'aide current_date serait
nécessaire ne serait-il pas?

Examiner à nouveau qu'un CHECK/ASSERTION ne seront enregistrés que lorsque les données dans la table/schéma est mis à jour. Le problème avec l'aide de CURRENT_DATE (et d'autres non-determninistic fonctions), dans une contrainte est que la règle d'entreprise, peut être invalidé par le simple compte à rebours a commencé au cours d'une période à l'autre, mais si les données n'a pas été changé dans cette période de l'intégrité des données ne sera pas détecté et la base de données contient des données non valides.

Une autre question, est ce que l'on entend par année dans le contexte.

Il pourrait être l'année civile (du 1er janvier au 31 Décembre inclus) ou d'autres d'autres dates fixes définis par l'entreprise (par exemple, du 1er Avril au 31 mars inclusivement), dans lequel cas de groupement, par année et par utilisateur, puis comptage est trivial.

Plus intéressant lorsque les limites des règles de pointage pour tout période de 12 mois; l'extension à la fois le passé et l'avenir d'éviter les non-déterministe.

Envisager une standard approche de l'utilisation d'un auxiliaire de calendrier de table, contenant une ligne pour chaque jour applicable à l'entreprise, prolongée dans le passé et l'avenir, seulement dans la mesure requise devrait comporter quelques milliers de lignes. Chaque ligne doit avoir la date en tant que clé avec un deuxième colonne qui date de plus d'un an (et, si nécessaire, vous pourriez affiner la définition de "un an" lors d'une journée de granularité!) Le test pour impliquerait l'adhésion à l'Agenda de la table, le regroupement sur le calendrier la date et de l'utilisateur et de comptage par exemple quelque chose comme ceci:

SELECT C1.dt, V1.my_user
  FROM Video AS V1
       INNER JOIN Calendar AS C1
          ON (V1.my_date BETWEEN C1.dt AND C1.dt_plus_one_year)
 GROUP 
    BY C1.dt, V1.my_user
HAVING COUNT(*) > 100;

Cela pourrait être mis dans une CHECK (NOT EXISTS (... contrainte. Cela pourrait encore être au niveau de la table CHECK contrainte: parce que le Calendrier de table est une table auxiliaire, il ne serait soumis à de rares contrôler les mises à jour (mais pourrait encore être un ASSERTION si nécessaire).

OriginalL'auteur onedaywhen