DataReader - ординалы hardcode?

Индексирование программы чтения данных по имени немного дороже. Для этого есть две основные причины.

• Типичные реализации хранят информацию о полях в структуре данных, которая использует числовую индексацию. Чтобы преобразовать имя в число, необходимо выполнить операцию сопоставления.
• Некоторые реализации выполняют поиск имени в два прохода. Первый проход пытается сопоставить имена полей с включенной чувствительностью к регистру. Если этот проход не прошел, второй проход начинается с отключенной чувствительностью к регистру.

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

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

• Код легче читать.
• Код более терпим к изменениям схемы набора результатов.

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

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

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

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

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

Для каждого поля вам нужно будет вручную проверить наличие нулей.

var dr = command.ExecuteQuery();

if (dr.HasRows) {
    var customer = new Customer();
    // I'm assuming that you know each field's position returned from your query.
    // Where comes the importance to write all of your selected fields and not just "*" or "ALL".
    customer.Id = dr[0] == null || dr[0] == DBNull.Value ? null : Convert.ToInt32(dr[0]);
    ...
}

В дополнение к этому, это позволит вам использовать отражение и сделать этот метод GetData () более универсальным, предоставив typeof (T) и получив соответствующий конструктор для правильного типа. Привязка к порядку каждого столбца - единственное, чего некоторые хотят избежать, но в этом случае это становится достойным.

Поиск имени строки намного дороже, чем вызов ординалов, но более удобен в обслуживании и менее "хрупок", чем жесткое кодирование ординалов. Вот как я это делаю. Это лучшее из двух миров. Мне не нужно запоминать порядковые значения или заботиться об изменении порядка столбцов, но я получаю преимущества производительности при использовании ординалов.

var dr = command.ExecuteQuery();
if (dr.HasRows)
{
    //Get your ordinals here, before you run through the reader
    int ordinalColumn1 = dr.GetOrdinal("Column1");
    int ordinalColumn2 = dr.GetOrdinal("Column2");
    int ordinalColumn3 = dr.GetOrdinal("Column3");

    while(dr.Read())
    {
        // now access your columns by ordinal inside the Read loop. 
        //This is faster than doing a string column name lookup every time.
        Console.WriteLine("Column1 = " + dr.GetString(ordinalColumn1);
        Console.WriteLine("Column2 = " + dr.GetString(ordinalColumn2);
        Console.WriteLine("Column3 = " + dr.GetString(ordinalColumn3);
    }
}

Примечание: это действительно имеет смысл только для читателей, в которых ожидается приличное количество строк. Вызовы GetOrdinal() являются дополнительными, и окупаются только в том случае, если суммарная экономия от вызова GetString(int ordinalNumber) в цикле больше, чем затраты на вызов GetOrdinal.

Edit: пропустил вторую часть вопроса. Что касается значений DBNull, я начал писать методы расширения, которые справляются с этой возможностью. пример: dr.GetDatetimeSafely() В рамках этих методов расширения вы можете делать все, что вам нужно, чтобы быть уверенным, что вы получите ожидаемое значение обратно.