Как вы эффективно обрабатываете BLOB и числовые данные при обмене данными с базой данных?

Question

Базы данных SQL являются краеугольным камнем большинства программного обеспечения. Тем не менее, он кажется оптимизированным для текстовых данных. Фактически, при выполнении любых запросов, включающих числовые данные, в частности целые числа, кажется неэффективным, что числа преобразуются в текст, а затем возвращаются в собственные форматы в обоих направлениях между приложением и базой данных. Такая же неэффективность, похоже, применима и к данным BLOB. Насколько я понимаю, даже с чем-то вроде Linq to SQL это двустороннее преобразование происходит в фоновом режиме.

Существуют ли общие способы обойти эти издержки с помощью SQL? Существуют ли определенные системы управления базами данных, которые обрабатывают это более эффективно, чем другие (например, с нестандартными расширениями / API)?

Разъяснение. В следующем операторе select список чисел после IN легче передать в виде необработанного массива int, но, похоже, нет способа достичь этого уровня оптимизации.

SELECT foo FROM bar WHERE baz IN (23, 34, 45, 9854004, ...)

Answer 1

Не думай. Измерить.

Преобразование формата вряд ли будет измеримой стоимостью для работы с базой данных, если только вы не используете базу данных как арифметический движок.

Стоимость ввода-вывода для LOB, особенно для CLOBS с преобразованием символов, может стать значительной; Решение проблемы, если вы знаете, что простейшая вещь, которая может сработать на самом деле, оказывает заметное влияние на производительность, заключается в минимизации количества копий данных больших объектов. Используйте любой стиль привязки параметров SQL, который позволяет передавать данные непосредственно между точкой их создания или использования и базой данных - часто это связывает большой объект с потоком или каналом ввода-вывода.

Но не делайте этого, пока у вас не будет способа измерить удар и покажите, что это ваше узкое место.

Answer 2

Числовые данные в базе данных не сохраняются в виде текста. Я предполагаю, что это зависит от базы данных, но это, конечно, не обязательно.

BLOB хранятся именно так, как вы их установили - по определению, БД не имеет возможности интерпретировать информацию - я думаю, она может сжаться, если сочтет это полезным. BLOB не переводятся в текст.

Вот как Oracle хранит числа:

http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#i16209

Внутренний числовой формат

База данных Oracle хранит числовые данные в формате переменной длины. Каждое значение хранится в научной записи: 1 байт используется для хранения показателя степени, а до 20 байт - для хранения мантиссы. Полученное значение ограничено 38 цифрами точности. База данных Oracle не хранит начальные и конечные нули. Например, число 412 хранится в формате, аналогичном 4.12 x 102, с 1 байтом, используемым для хранения показателя степени (2), и 2 байтами, используемыми для хранения трех значащих цифр мантиссы (4,1,2). Отрицательные числа включают знак в длину.

Информация MySQL здесь:

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

Посмотрите на таблицу - TINYINT представлен в 1 байте (диапазон от -128 до 127), что невозможно при сохранении в виде текста.

РЕДАКТИРОВАТЬ: с пояснениями - я бы сказал, использовать API на вашем языке, который выглядит примерно так (псевдокод)

stmt = conn.Prepare("SELECT * FROM TABLE where x in (?, ?, ?)");
stmt.SetInt(0, x);
stmt.SetInt(1, y);
stmt.SetInt(2, z);

Я не верю, что базовые протоколы используют текст для передачи параметров.