Очистка возвращаемых данных базы данных

Question

Мне интересно, что все думают, что лучший способ обработки результатов из вашей собственной базы данных. Могут быть задействованы другие команды, и всегда есть вероятность, что процедура / данные могут быть изменены, и могут возникнуть ошибочные результаты. У меня вопрос такой. Лучше позволить и возникновение исключения, поймать и зарегистрировать его или попытаться обработать все непредвиденные обстоятельства и скрыть ошибку? Скажем, что-то вроде ниже.

if (dr.Table.Columns.Contains("column") && !dr["column"].Equals(DBNull.Value))
{
    this.value = (type)dr["column"];
}
else
{
   this.value= null;
}

Answer 1

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

Конечно, я бы также попытался настроить некоторые тесты дыма, чтобы убедиться, что вы узнаете об этом перед производством:)

Answer 2

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

Например, из поста jonSkeet. Если вы ожидаете ненулевое условие для столбца, есть ли ограничение для этого столбца? Если нет, вы, вероятно, ожидаете этого, потому что разработчик DBA / DB сказал вам, что так и будет. Я бы сказал им, что вы будете полагаться на этот факт, и побудите их подтолкнуть их к добавлению ненулевого ограничения. Если вы ожидаете уникальных значений, попросите об уникальном ограничении. Только заглавные буквы, добавьте проверочное ограничение. В вашем коде нет смысла проверять все прописные буквы, а затем следующее приложение, следующее приложение и следующее приложение, когда это можно сделать один раз. Помни СУХОЙ - не повторяйся.

В случае ошибки отсутствующего столбца мой упреждающий подход заключается в том, чтобы команда разработчиков баз данных понимала, какие таблицы, представления и процедуры используются приложениями. Каждое приложение должно иметь свое собственное имя пользователя, имя пользователя каждого приложения должно быть предоставлено, выбирайте только те таблицы, которые ему нужны - не в качестве функции безопасности, а в качестве документации. Если вы измените ЭТУ таблицу, она будет использоваться этими приложениями. То же самое с процессами, предоставьте выполнение приложениям, которые его используют. Если вы соблюдаете строгие правила и внедряете «проверку на наличие внешних зависимостей при внесении изменений» , вы исключите многие из этих ошибок.

Answer 3

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

Как говорит @ AviewAnew , возможно, вы немного параноик, но это не значит, что вы ошибаетесь!

Я бы подумал, что отсутствие столбца будет намного хуже, чем нулевое значение, так как насчет исключения для отсутствующего столбца?

try // wrap everything in a try/catch to handle things I haven't thought of
{

    if ( !dr.Table.Columns.Contains("column") )
    {
        throw new SomeSortOfException("cloumn: " + column + " is missing" );
    }
    else // strictly don't need the else but it makes the code easier to follow
    {
        if (dr["column"].Equals(DBNull.Value))
        {
            this.value= null;
        }
        else
        {
            this.value = (type) dr["column"];
        }
    }
}
catch( SomeSortOfException ex )
{
    throw;
}
catch( Exception ex )
{
    // handle or throw impossible exceptions here
}

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

Ваш звонок!

Answer 4

Ограничения базы данных должны позаботиться о большей части этого для вас. В противном случае я бы предложил вернуться к дизайну БД и исправить эти ограничения.

Если это не так, лучше всего будет вернуть исключение в этом поле, чтобы данные могли быть исправлены (или удалены).