Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Di seguito sono riportate considerazioni utili per l'impiego di DataConnection con il Motore regole di business.
Utilizzare le chiavi primarie
Nei casi in cui esiste una chiave primaria, l'uguaglianza di due righe non è determinata dal confronto degli oggetti, bensì dal fatto che le righe condividono la stessa chiave primaria. Se si determina che le righe sono uguali, solo una copia viene mantenuta in memoria, mentre l'altra viene rilasciata. Ciò comporta un minore consumo di memoria.
Quando un dataConnection viene asserto nel motore delle regole per la prima volta, il motore tenta sempre di individuare le informazioni chiave primarie dal relativo schema. Se esiste una chiave primaria, le informazioni sulla chiave primaria vengono recuperate e utilizzate in tutte le valutazioni successive.
Nota
Una chiave primaria è obbligatoria se è necessario apportare modifiche al database.
Fornire una transazione in esecuzione a DataConnection tutte le volte che è possibile
Senza una transazione, ogni query e aggiornamento in DataConnection avvia la propria transazione locale e le diverse query potrebbero restituire risultati diversi in parti diverse delle valutazioni delle regole. Gli utenti possono sperimentare un comportamento incoerente in presenza di modifiche nella tabella di database sottostante.
Anche se è possibile usare una connessione DataConnection senza fornire una transazione quando la tabella non cambia nel tempo, è consigliabile usare una transazione anche quando dataConnection viene usato solo per le operazioni di lettura.
È tuttavia necessario utilizzare sempre una transazione in caso di aggiornamento dei dati.
Il numero di query può aumentare in modo lineare
Poiché le query su DataConnection vengono parametrizzate da altri oggetti aggiunti, il numero di query eseguite in DataConnection corrisponde direttamente al numero di oggetti join che raggiungono DataConnection. Pertanto, se il numero di oggetti che raggiungono l'oggetto DataConnection aumenta in modo lineare, il numero di query rispetto a DataConnection crescerà in modo lineare. Al momento non è disponibile alcuna soluzione per ridurre il numero di query.
Un esempio è rappresentato dalla regola:
IF A.x = 7 AND DC.y = A.y
THEN
Un oggetto rappresenta un oggetto ObjectBinding, DC rappresenta un oggetto DataConnection e x e y rappresentano attributi di A e DC.
Per ogni istanza di A che supera il test (x = 7), viene generata una query usando DataConnection. Se sono presenti più istanze corrispondenti, viene restituito lo stesso numero di query.
Utilizzare le condizioni OR con cautela
Se la regola usa solo le condizioni E (CONC), i test e le query verranno eseguiti il prima possibile, pertanto le istanze di oggetti che passano verranno ridotte. Di conseguenza, il numero di query rispetto al successivo DataConnection verrà ridotto in modo proporzionale. Se le condizioni OR (disjunctive) e dataConnection vengono usate insieme in una regola, tutte le valutazioni delle condizioni verranno push nella query finale. Se in una regola vengono usate più di una dataconnection , tutte le query tranne l'ultima diventano effettivamente un'istruzione di query Select-ALL.
In generale è preferibile dividere una regola con una condizione OR in due o più regole distinte, perché l'utilizzo delle condizioni OR comporta una maggiore riduzione delle prestazioni rispetto alla definizione di più regole atomiche. Ciò vale indipendentemente dal fatto che vengano utilizzati o meno oggetti DataConnection.
È anche possibile considerare l'uso di regole separate che sono costituite solo da condizioni congiuntive anziché una regola con condizioni OR . Con le condizioni OR , il numero di query aumenta alla velocità di moltiplicazione di istanze di tutti gli oggetti join. come illustrato nell'esempio seguente.
IF (A.x ==7 OR A.x == 8) AND DC.y == A.y
THEN DC.z = 10
In questo esempio, A rappresenta un oggetto ObjectBinding; DC rappresenta un oggetto DataConnection e x, y e z rappresentano attributi di A e DC. Se A ha 100 istanze e x è 1 nel primo oggetto, 2 nel secondo oggetto, fino a 100 nell'oggetto 100, 100 query devono essere eseguite su DataConnection.
È preferibile riscrivere la regola precedente suddividendola in due regole.
Regola 1
IF A.x =7 AND DC.y = A.y
THEN DC.z = 10
Regola 2
IF A.x = 8 AND DC.y = A.y
THEN DC.z = 10
SQL Server non supporta alcuni predicati e funzioni
Alcuni predicati e funzioni supportati dal Motore regole di business non sono supportati da SQL Server. Se nelle condizioni delle regole si utilizzano questi predicati e funzioni non supportati, non sarà possibile incorporarle nella query. I seguenti termini non possono essere ottimizzati come query SQL:
Per alcune delle funzioni incorporate del motore non esiste equivalente in una query SQL. Sono Power, FindFirst e FindAll. L'uso di una colonna DataConnection come uno o più argomenti non può essere ottimizzato come parte di una query; Ad esempio, Power( 2, dc.Column1).
Match predicato predefinito che usa una colonna DataConnection come argomento di espressione regolare (il primo argomento). Ad esempio, Match("abc*", dc1.Column2) è valido, mentre Match(dc1.Column1, dc1.Column2) non può essere convertito.
Uso di una funzione utente con una colonna DataConnection come uno dei relativi parametri. Ad esempio, non è possibile ottimizzare c1.M(dc.Column1) perché la funzione utente non può essere eseguita nel server di database, ma deve essere eseguita dal Motore regole di business.
Funzioni utente che rappresentano operazioni impostate su DataConnection; ad esempio dc.Column1(5).
Funzioni che usano Un oggettoReference per DataConnection; Ad esempio, ObjecRef(dc).
Se uno o più argomenti di una funzione non sono convertibili, diventa impossibile convertire la chiamata alla funzione; ad esempio, Add(c1.M(dc.Column1) 5 ).