Как насчет того, чтобы использовать вспомогательный метод как это:
attribs.something = getString(
entry.Properties["something"].Value,
attribs.something);
static String getString(
Object obj,
String defaultString)
{
if (obj == null) return defaultString;
return obj.ToString();
}
, С другой стороны, Вы могли использовать ??
оператор:
attribs.something =
(entry.Properties["something"].Value ?? attribs.something).ToString();
(отмечают избыточное ToString()
вызов, когда значение null
)
Я предполагаю, что вы спрашиваете о производительности? Есть функция instr . Но это, вероятно, будет работать почти так же за кулисами.
Может быть, вы могли бы изучить полнотекстовый поиск .
В качестве последнего средства вам нужно будет обратить внимание на кеширование или предварительно вычисленные столбцы / индексированное представление.
Вы можете сделать это таким образом, используя INSTR:
SELECT * FROM users WHERE INSTR(LOWER(last_name), 'z') > 0;
INSTR возвращает ноль, если подстрока отсутствует в строке.
Из интереса, почему бы вам не использовать подобное ?
Редактировать: Я взял на себя смелость сделать поисковый регистр нечувствительным, чтобы вы не пропустили Боба Зебиди. : -)
Если бы вас интересовал только 'z', вы могли бы создать индекс на основе функций.
CREATE INDEX users_z_idx ON users (INSTR(last_name,'z'))
Тогда ваш запрос будет использовать WHERE INSTR (last_name, 'z')> 0
.
При таком подходе вам нужно будет создать отдельный индекс для каждого символа, который вы, возможно, захотите найти. Я полагаю, если вы делаете это часто, возможно, стоит создать один индекс для каждой буквы.
Также имейте в виду, что если ваши данные имеют имена, написанные с заглавной буквы стандартным способом (например, "Zaxxon"), тогда и ваш пример, и мой не будут соответствовать именам, начинающимся с Z. Вы можете исправить это, включив LOWER в поисковое выражение: INSTR (LOWER (last_name), 'z')
.
Имейте в виду, что для поиска этих значений имеет смысл использовать что-либо, кроме полного сканирования таблицы, только если количество блоков, содержащих строку, соответствующую предикату, значительно меньше общего числа блоков в таблице. Вот почему Oracle часто отказывается от использования индекса для полного сканирования, когда вы используете LIKE '% x%', где x - очень маленькая строка. Например, если оптимизатор считает, что использование индекса все равно потребует чтения одного блока (скажем) 20% блоков таблицы, то полное сканирование таблицы, вероятно, будет лучшим вариантом, чем сканирование индекса.
Иногда вы знаете, что ваш предикат намного более избирательный, чем может оценить оптимизатор. В таком случае вы можете рассмотреть вопрос о предоставлении подсказки оптимизатору для выполнения быстрого полного сканирования индекса в соответствующем столбце (особенно, если индекс является гораздо меньшим сегментом, чем таблица).
SELECT /*+ index_ffs(users (users.last_name)) */
*
FROM users
WHERE last_name LIKE "%z%"
Базы данных сильно оптимизированы для общих сценариев использования (и LIKE - один из таких).
Вы не найдете более быстрого способа выполнения поиска, если хотите остаться в БД. -уровень