Considérations sur l'utilisation de DataConnection
Prenez en compte les éléments suivants lorsque vous utilisez DataConnection avec le moteur des règles d'entreprise.
Utilisez des clés primaires
Lorsqu'une clé primaire existe, l'égalité des deux lignes est déterminée par le fait que ces lignes contiennent la même clé primaire et non par la comparaison de l'objet. Si les lignes sont considérées comme identiques, une seule copie est conservée en mémoire et l'autre est libérée. Ceci réduit la consommation de mémoire.
Lorsqu’un DataConnection est déclaré dans le moteur de règles pour la première fois, le moteur tente toujours de localiser ses informations de clé primaire à partir de son schéma. Si une clé primaire existe, les informations la concernant sont extraites et utilisées dans toutes les évaluations ultérieures.
Notes
Une clé primaire est obligatoire si des changements sont requis dans la base de données.
Fournissez une transaction d'exécution à DataConnection chaque fois que possible
Sans transaction, chaque requête et mise à jour sur dataConnection lance sa propre transaction locale, et différentes requêtes peuvent retourner des résultats différents dans différentes parties des évaluations de règles. Les utilisateurs risquent d'obtenir un comportement imprévisible si des changements sont apportés dans la table de base de données sous-jacente.
Bien que vous puissiez utiliser un DataConnection sans fournir de transaction lorsque la table ne change pas au fil du temps, il est recommandé d’utiliser une transaction même lorsque DataConnection est utilisé uniquement pour les opérations de lecture.
Vous devez, toutefois, utiliser systématiquement une transaction lorsque vous mettez à jour des données.
Le nombre de requêtes peut augmenter de manière linéaire
Comme les requêtes sur dataConnection sont paramétrées par d’autres objets joints, le nombre de requêtes exécutées sur dataConnection correspond directement au nombre d’objets de jointure atteignant dataConnection. Par conséquent, si le nombre d’objets de jointure atteignant l’objet DataConnection augmente linéairement, le nombre de requêtes par rapport à DataConnection augmente également de façon linéaire. aucune optimisation n'est mise en place pour réduire ce nombre de requêtes.
Prenons cette règle comme exemple :
IF A.x = 7 AND DC.y = A.y
THEN
A représente un ObjectBinding, DC représente un DataConnection, et x et y représentent les attributs de A et DC.
Pour chaque instance de A qui réussit le test (x = 7), une requête est générée à l’aide de DataConnection. S'il existe de nombreuses correspondances, vous obtenez le même nombre de requêtes.
Utilisez les conditions OR avec précaution
Si la règle utilise uniquement des conditions conjonctives (AND), les tests et les requêtes sont exécutés le plus tôt possible, de sorte que les instances d’objets transitant sont réduites. Par conséquent, le nombre de requêtes sur la connexion de données suivante sera réduit proportionnellement. Si des conditions disjonctives (OR) et un DataConnection sont utilisés ensemble dans une règle, toutes les évaluations de condition sont envoyées à la requête finale. Si plusieurs DataConnection sont utilisés dans une règle, toutes les requêtes à l’exception de la dernière sont effectivement une instruction de requête Select-ALL.
En général, il vaut mieux fractionner en deux ou en plusieurs règles discrètes une règle avec une condition OR parce que, par comparaison avec la définition de règles plus atomiques, les conditions OR réduisent les performances. Ceci est vrai que vous utilisiez ou non des DataConnections.
Vous pouvez également envisager d’utiliser des règles distinctes qui se composent uniquement de conditions conjonctives au lieu d’une règle avec des conditions OR . Avec les conditions OR , le nombre de requêtes augmente à la vitesse de multiplication des instances de tous les objets joints. Cela est illustré par l'exemple suivant.
IF (A.x ==7 OR A.x == 8) AND DC.y == A.y
THEN DC.z = 10
Dans cet exemple, A représente un ObjectBinding ; DC représente un DataConnection, et x, y et z représentent les attributs de A et DC. Si A a 100 instances et que x est 1 dans le premier objet, 2 dans le deuxième objet, et 100 dans le 100e objet, 100 requêtes doivent s’exécuter sur dataConnection.
Il vaut mieux réécrire la règle précédente en la fractionnant en deux règles.
Règle 1
IF A.x =7 AND DC.y = A.y
THEN DC.z = 10
Règle 2
IF A.x = 8 AND DC.y = A.y
THEN DC.z = 10
SQL ne prend pas en charge certains prédicats et fonctions.
Certains prédicats et fonctions pris en charge par le moteur de règles ne le sont pas par SQL. Si vous utilisez ces prédicats et fonctions non pris en charge dans les conditions de règle, ils ne peuvent pas être intégrés à la requête. Les conditions suivantes ne peuvent pas être optimisées en tant que requêtes SQL.
Certaines des fonctions intégrées du moteur n'ont pas d'équivalent dans une requête SQL. Il s’agit de Power, FindFirst et FindAll. L’utilisation d’une colonne DataConnection comme un ou plusieurs de leurs arguments ne peut pas être optimisée dans le cadre d’une requête ; par exemple, Power( 2, dc.Column1).
Prédicat intégré Match qui utilise une colonne DataConnection comme argument d’expression régulière (premier argument). Par exemple, Match("abc*", dc1.Column2) est valide, mais Match(dc1.Column1, dc1.Column2) ne peut pas être traduit.
Utilisation d’une fonction utilisateur qui a une colonne DataConnection comme l’un de ses paramètres. Par exemple, c1.M(dc.Column1) ne peut pas être optimisé parce que la fonction utilisateur ne peut pas être exécutée par le serveur de base de données, mais par le moteur des règles d'entreprise.
Fonctions utilisateur qui représentent des opérations de jeu sur dataConnection ; par exemple, dc.Column1(5).
Fonctions qui utilisent un ObjectReference pour dataConnection ; par exemple, ObjecRef(dc).
Si un ou plusieurs arguments d'une fonction ne peuvent pas être traduits, l'appel de fonction devient aussi intraduisible ; par exemple, Add(c1.M(dc.Column1), 5).