SoCaseInsensitive ha un grande impatto sulle prestazioni di un TdxMemIndex su un TdxMemDataset?

Question

Sto aggiungendo alcuni indici al mio DevExpress TdxMemDataset per migliorare le prestazioni. TdxMemIndex ha SortOptions che includono l'opzione per soCaseInsensitive . I miei dati sono generalmente una stringa GUID, quindi non fanno distinzione tra maiuscole e minuscole. Mi chiedo se sto meglio solo forzando tutti i dati nello stesso caso o se il flag soCaseInsensitive e usando il flag loCaseInsensitive con la chiamata a Locate ha solo un minor penalità di prestazione (all'incirca uguale alla conversione del caso della mia stringa ogni volta che devo usare l'indice).

A questo punto lascio spento CaseInsentive e sto solo convertendo il caso.

Answer 1

IMHO, La cosa migliore è assicurare la qualità dei dati al momento delle Poste. Ragionamenti:

1. Tu (di solito) conosci la natura dei dati. Quindi, ad es. puoi usare UpperCase (sapendo che i GUID sono tutti nell'intervallo ASCII) invece di molto AnsiUpperCase più lento che un componente generale come TdxMemDataSet è costretto a usare.

2. I dati vengono immessi una sola volta. La ricerca / ordinamento / filtro che implica tutto il motore di upscassing interno di TdxMemDataSet è un'azione ripetuta. Inoltre, ci sono altre azioni concatenate che attiveranno questo motore senza rendersene conto. (Ad esempio un TcxGrid che è ordinato per impostazione predefinita con GridMode: = True (suppongo che tu usi i componenti DevEx.) E che una classe si comporti come un broker che passa il messaggio di ordinamento al set di dati sottostante.

3. Di solito l'inserimento dei dati avviene in passaggi, uno o pochi record in un batch. L'unica eccezione notevole è rappresentata dalle applicazioni di acquisizione dati. Ma in entrambi i casi sopra la cultura dell'usabilità dell'utente consente modo maggiori tempi di risposta con cui giocare. (IOW quanto aggiungerebbe una chiamata UpperCase a un post record che dura 0,005 ms?) OTOH, gli utenti sono molto esigenti con la velocità delle operazioni di recupero dei dati (ricerca, ordinamento, filtro ecc.). Mantenere il recupero dei dati il ??più velocemente possibile.

4. Avere i dati nel database pronti per essere esposti riduce il rischio di errori di elaborazione quando si scrivono ( se si scrive) altri moduli (è necessario ricordare ad AnsiUpperCase il dati in qualsiasi modulo in qualsiasi lingua tu scriva). Anche qui un esempio classico è quando userete altri strumenti esterni per accedere ai dati (per es. I gestori di db per eseguire un SELCT SQL sui dati).

hth.

Answer 2

Forse i forum DevExpress (o mai un'e-mail di supporto, se si ha accesso ad esso) sarebbe un posto migliore per cercare una risposta autorevole su quella domanda sulle prestazioni.

Ad ogni modo, è meglio garantire che i dati siano nel formato desiderato - per i motivi già spiegati - nel momento in cui li salvate. Quindi, in quello specifico, assicurati che il GUID sia scritto in maiuscolo (o in basso, è una questione di gusti). Se è SQL Server o un altro server di database che ha un tipo di dati guid, assicurati che SELECT funzioni, se applicabile e possibile , anche l'ordinamento.