Сильно ли soCaseInsensitive влияет на производительность TdxMemIndex в TdxMemDataset?

Question

Я добавляю некоторые индексы в свой DevExpress TdxMemDataset Набор данных TdxMemDataset для повышения производительности.Тот Самый TdxMemIndex имеет Варианты сортировки которые включают в себя возможность Очень чувствительный.Мои данные обычно представляют собой строку GUID, поэтому они не чувствительны к регистру.Мне интересно, будет ли мне лучше просто перенести все данные в один и тот же случай или Очень чувствительный флаг и использование Чувствительный к местоположению флаг с вызовом Locate имеет лишь незначительное снижение производительности (примерно равно преобразованию регистра моей строки каждый раз, когда мне нужно использовать индекс).

На данный момент я оставляю CaseInsentive выключенным и просто конвертирую case.

Answer 1

ИМХО, лучше всего обеспечить качество данных во время публикации.Рассуждения:

1. Вы (обычно) знаете природу данных.Так, например.вы можете использовать верхний регистр (зная, что все идентификаторы GUID находятся в диапазоне ASCII) вместо многое более медленный заглавный код, который вынужден использовать общий компонент, такой как TdxMemDataSet.

2. Вы вводите данные только один раз.Поиск / Сортировка / Фильтрация, которые все подразумевают внутренний механизм обновления TdxMemDataSet, - это повторяющееся действие.Кроме того, существуют другие связанные действия, которые запускают этот движок, не осознавая этого.(Например.TcxGrid, который сортируется по умолчанию, имея GridMode:=True (я предполагаю, что вы используете DevEx.компоненты) и наличие класса, действующего как брокер, передающий сообщение сортировки базовому набору данных.

3. Обычно ввод данных выполняется поэтапно, по одной или нескольким записям в пакете.Единственным заметным исключением являются приложения для сбора данных.Но в обоих вышеперечисленных случаях культура юзабилити пользователя позволяет способ увеличьте время отклика, с которым вы можете играть.(Сколько будет стоить добавление вызова в верхнем регистре к записи, которая длится 0,005 мс?) OTOH, пользователи очень требовательный со скоростью операций восстановления данных (поиск, сортировка, фильтрация и т.д.).Восстанавливайте данные как можно быстрее.

4. Наличие данных в базе данных, готовых к раскрытию, снижает риск ошибок обработки при записи (если вы будете писать) другие модули (вам нужно не забывать указывать данные в верхнем регистре в любом модуле на любом языке, который вы будете писать).Также здесь классическим примером является использование других внешних инструментов для доступа к данным (например.менеджеры БД для выполнения SQL-запроса по данным).

хтх.

Answer 2

Возможно, форумы DevExpress (или когда-либо письмо поддержки, если у вас есть к нему доступ) были бы лучшим местом для поиска достоверного ответа на этот вопрос о производительности.

В любом случае, лучше всего гарантировать, что данные будут в нужном вам формате - по понятным причинам - в момент их сохранения. Итак, в этом конкретном случае, убедитесь, что GUID написан в верхнем (или нижнем, дело вкуса). Если это SQL Server или другой сервер баз данных, имеющий тип данных guid, убедитесь, что SELECT выполняет работу - если это применимо и возможно , даже сортировку.