Consideraciones al utilizar DataConnection
Considere lo siguiente al utilizar DataConnection con el motor de reglas de negocios.
Utilice claves principales
Cuando hay una clave principal, la igualdad de dos filas se determina considerando si las filas tienen la misma clave principal en vez de comparando objetos. Si se determina que las filas son iguales, solo se conserva una copia en la memoria y la otra se descarta. Esto supone una menor utilización de la memoria.
Cuando dataConnection se declara en el motor de reglas por primera vez, el motor siempre intenta localizar su información de clave principal desde su esquema. Si existe una clave principal, se recupera la información y se utiliza en todas las evaluaciones posteriores.
Nota
Es obligatoria una clave principal si hay que hacer cambios en la base de datos.
Proporcione una transacción de ejecución a la DataConnection siempre que sea posible
Sin una transacción, cada consulta y actualización de DataConnection inicia su propia transacción local y diferentes consultas pueden devolver resultados diferentes en diferentes partes de las evaluaciones de reglas. Los usuarios pueden experimentar un comportamiento incoherente si hay cambios en la tabla de la base de datos subyacente.
Aunque puede usar dataConnection sin proporcionar una transacción cuando la tabla no cambia con el tiempo, se recomienda usar una transacción incluso cuando dataConnection solo se usa para las operaciones de lectura.
Sin embargo, siempre se debe utilizar una transacción cuando actualice datos.
El número de consultas se puede incrementar linealmente
A medida que otras consultas en DataConnection están parametrizadas por otros objetos unidos, el número de consultas ejecutadas en DataConnection corresponde directamente al número de objetos de combinación que llegan a DataConnection. Por lo tanto, si el número de objetos de combinación que alcanzan el objeto DataConnection crece linealmente, también aumentará linealmente el número de consultas en DataConnection . Actualmente, no existe ninguna optimización para reducir el número de consultas.
Un ejemplo es la regla:
IF A.x = 7 AND DC.y = A.y
THEN
Representa un ObjectBinding, DC representa un objeto DataConnection y x e y representan atributos de A y DC.
Para cada instancia de A que supera la prueba (x = 7), se genera una consulta mediante DataConnection. Si existen muchas instancias coincidentes, se producirán el mismo número de consultas.
Utilice las condiciones OR con precaución
Si la regla solo usa condiciones conjuntas (AND), las pruebas y las consultas se ejecutarán lo antes posible, por lo que se reducirán las instancias de objetos que pasan por . Como resultado, el número de consultas en la conexión de datos posterior se reducirá proporcionalmente. Si las condiciones disjuntivas (OR) y dataConnection se usan juntas en una regla, todas las evaluaciones de condición se insertarán en la consulta final. Si se usa más de una clase DataConnection en una regla, todas las consultas excepto la última se convertirán en una instrucción de consulta Select-ALL.
En general, es mejor dividir cualquier regla con una condición OR en dos o más reglas discretas, porque la utilización de condiciones OR disminuirá rendimiento si se compara con la definición de más reglas atómicas. Esto es así independientemente de que se utilicen DataConnections o no.
También puede considerar el uso de reglas independientes que solo constan de condiciones conjuntas en lugar de una regla con condiciones OR . Con las condiciones OR , el número de consultas crece a la velocidad de multiplicación de instancias de todos los objetos de combinación. Esto se muestra en el ejemplo siguiente.
IF (A.x ==7 OR A.x == 8) AND DC.y == A.y
THEN DC.z = 10
En este ejemplo, A representa un ObjectBinding; DC representa una clase DataConnection y x, y y z representan atributos de A y DC. Si A tiene 100 instancias y x es 1 en el primer objeto, 2 en el segundo objeto, hasta 100 en el objeto 100, 100 consultas tienen que ejecutarse en DataConnection.
Es mejor volver a escribir la regla anterior dividiéndola en dos reglas.
Regla 1
IF A.x =7 AND DC.y = A.y
THEN DC.z = 10
Regla 2
IF A.x = 8 AND DC.y = A.y
THEN DC.z = 10
SQL no admite algunos predicados y funciones
SQL no admite algunos predicados y funciones que admite el motor de reglas. Si estos predicados y funciones no admitidos se utilizan en las condiciones de la regla, no se pueden incorporar a la consulta. Los términos siguientes no se pueden optimizar como una consulta SQL:
Algunas de las funciones integradas del motor no tienen equivalente en una consulta SQL. Estos son Power, FindFirst y FindAll. El uso de una columna DataConnection como uno o varios de sus argumentos no se puede optimizar como parte de una consulta; por ejemplo, Power( 2, dc.Column1).
Predicado integrado Match que usa una columna DataConnection como argumento de expresión regular (el primer argumento). Por ejemplo, Coincidencia("abc*", dc1.Column2) es válido, pero Coincidencia(dc1.Column1, dc1.Column2) no se puede traducir.
Usar una función de usuario que tiene una columna DataConnection como uno de sus parámetros. Por ejemplo, c1.M(dc.Column1) no se puede optimizar porque la función de usuario no se puede ejecutar en el servidor de base de datos, sino que debe ejecutarlo el motor de reglas de negocios.
Funciones de usuario que representan operaciones establecidas en DataConnection; por ejemplo, dc.Column1(5).
Funciones que usan objectReference para dataConnection; por ejemplo, ObjecRef(dc).
Si no es posible traducir uno o más argumentos de una función, la llamada a la función se convierte en intraducible; por ejemplo, Agregar(c1.M(dc.Column1), 5 ).