Selezione cursore sulla seconda chiave primaria sul campo db2 sql per il valore di posizione incorporato - Impossibile determinare la massima efficienza per la progettazione a lungo termine

-1

Ho una tabella SQL DB2 in cui i primi due campi sono le chiavi primarie (non includendo il terzo campo che è il timbro data / ora).
Il tavolo è stato progettato da un altro team con l'intento di renderlo generico.
Sono stato portato nel progetto dopo che il valore chiave per il secondo campo è stato codificato, per quando è stato inserito sul tavolo.

Questo mi porta a questo: Ora dobbiamo fare una selezione del cursore con una clausola WHERE che include la prima chiave primaria - e quindi per la seconda chiave primaria deve essere solo quando è un valore specifico in posizione 21 per 8 byte (E sapremo sempre quale sarà il valore per il secondo campo.) Il secondo campo è un campo generico di 70 byte (alfanumerico).

La mia domanda è: dovremmo usare un carattere jolly LIKE per l'istruzione della clausola WHERE per la seconda condizione del campo principale o invece un SUBSTR , poiché conosciamo la posizione del valore?

Chiedo perché ho già fatto un EXPLAIN , non vedo una differenza tra i due (nemmeno il mio analista di database).
E questo è per pochi milioni di record per una tabella lunga 1300 byte.

Tuttavia, la mia preoccupazione è che il volume dei dati sul tavolo crescerà su vari sistemi. Pertanto le prestazioni potrebbero diventare un problema. Proprio in questo momento è difficile misurare la differenza tra LIKE e SUBSTR . Ma vorrei fare la mia due diligence e codificarlo per prestazioni a lungo termine.

E se esiste una terza opzione, faccelo sapere.

    
posta Cindy LB 19.06.2018 - 01:23
fonte

1 risposta

0

Suppongo che i campi chiave primari siano immutabili, specialmente la seconda chiave. Quindi puoi aggiungere un'altra colonna alla tabella, mantenendo una copia di SUBSTR(secondKeyColumn,21,8) . L'immutabilità assicurerà che la ridondanza non porterà a problemi di incoerenza. Potrebbe essere una buona idea aggiungere un trigger di AFTER INSERT che assicuri che la colonna verrà sempre compilata correttamente quando viene creato un nuovo record.

Ciò renderà possibile aggiungere un indice alla nuova colonna e cambiare la query usando questo.

Nota che questa soluzione non è affatto speciale per DB2, funzionerà su qualsiasi database relazionale che supporti trigger e indici (come Oracle, MS SQL, PostgreSQL, Sybase o MySQL).

    
risposta data 19.06.2018 - 05:21
fonte

Leggi altre domande sui tag