C # Int против производительности байтов и SQL Int против двоичной производительности

Question

В приложении на C # windows я работаю с шестнадцатеричными строками.Одна строка HEX будет состоять из 5-30 частей HEX.

07 82 51 2A F1 C9 63 69 17 C1 1B BA C7 7A 18 20 20 8A 95 7A 54 5A E0 2E D4 3D 29

В настоящее время я беру эту строку и разбираю ее на N целых чисел, используя Convert.ToInt32(string, 16).Затем я добавляю эти значения int в базу данных.Когда я извлекаю эти значения из базы данных, я извлекаю их как Ints, а затем преобразовываю их обратно в строку HEX.

Было бы лучше с точки зрения производительности преобразовать эти строки в байты, а затем добавить их как двоичные типы данных вбаза данных?

РЕДАКТИРОВАТЬ:

Части 5-30 HEX соответствуют определенным таблицам, где все части составляют 1 запись с отдельными частями.Например, если у меня было 5 значений HEX, они соответствуют 5 отдельным столбцам 1 записи.

РЕДАКТИРОВАТЬ:

Чтобы уточнить (извините):

У меня 9 таблиц,Каждая таблица имеет заданное количество столбцов.

table1: 30

table2: 18

table3: 18

table4: 18

table5: 18

table6: 13

table7: 27

table8: 5

table9: 11

Каждый из этих столбцовв каждой таблице соответствует определенное значение HEX.

Например, мое приложение получит «полезную нагрузку» из 13 компонентов HEX в формате одной строки: 07 82 51 2A F1 C9 63 69 17 C1 1B BA C7,В настоящее время я беру эту строку и анализирую отдельные компоненты HEX и преобразую их в целые, сохраняя их в массиве int.Затем я беру эти значения int и сохраняю их в соответствующей таблице и столбцах в базе данных.Когда я читаю эти значения, я получаю их в виде целых чисел, а затем преобразую их в строки HEX.

Что мне интересно, так это то, нужно ли преобразовывать строку HEX в массив байтов и хранить байты как типы двоичных переменных SQL.

Answer 1

Что касается производительности, вы, конечно, должны проверить в обе стороны.

Однако, с точки зрения читаемости , если это просто произвольные данные, яконечно, предложил бы использовать массив байтов.Если это на самом деле предназначено для представления последовательности целых чисел, это нормально - но зачем вам представлять произвольный байтовый массив, используя коллекцию 4-байтовых целых чисел?Он не подходит ни к чему другому:

• Вы должны учитывать заполнение, если ваши входные данные не кратны 4 байтам
• Работать вусловия чтения и записи данных с потоками
• Не ясно, как вы храните целые числа в базе данных, но я бы ожидал, что BLOB-объект будет более эффективным, если выпросто пытаясь сохранить все это

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

Answer 2

Модель данных часто зависит не только от того, как вы хотите написать , но также от того, как вы хотите найти и прочитать данные.

Некоторые соображения:

• Если вам когда-нибудь понадобится найти определенную "шестнадцатеричную часть", даже если она не находится в начале "шестнадцатеричной строки", тогда каждая "шестнадцатеричная часть" должна находиться в отдельная строка, чтобы индекс базы данных мог ее забрать.
• В зависимости от вашей СУБД / API может быть нелегко искать через BLOB или байтовый массив. Это может быть важно для загрузки без префикса "HEX parts" или для выполнения изменений в середине "HEX string".
• Если «шестнадцатеричная строка» должна быть ПЕРВИЧНЫМ, УНИКАЛЬНЫМ или КЛЮЧЕВЫМ КЛЮЧОМ или должна быть доступна для поиска по префиксу, то обычно вам нужен тип базы данных, который фактически индексируется (обычно BLOB-объектов нет, но большинство СУБД имеют альтернативные типы для меньших байтовых массивов, которые равны ).

В общем, байтовый массив, вероятно, то, что вам нужно, но остерегайтесь приведенных выше соображений.

Answer 3

Да, безусловно. Вставка многих строк намного хуже, чем вставка нескольких больших строк.