Nullable вводит в таблицах данных/наборах данных со строгим контролем типов - обходные решения?

Я согласен, что было бы неплохо разрешить типы, допускающие значение NULL.

Если вы установите для свойства «NullValue» в столбце значение «-1» вместо «(Вызвать исключение)», свойство вернет -1, когда столбец имеет значение NULL, вместо того, чтобы генерировать исключение. Вам все равно нужно установить столбец, чтобы разрешить нули.

В качестве альтернативы вы всегда можете установить тип данных «System.Object» и разрешить nulls = true. Вы можете получить доступ к значению столбца, не используя метод «IsMyFieldNull ()». Значение столбца будет «System.DbNull.Value», если столбец имеет значение NULL. Если вам не нравится использовать «System.DbNull.Value», вы можете установить для свойства «NullValue» значение «(Nothing)» вместо «(Throw exception)», а затем сравнить объект с пустой ссылкой.

В VS 2008 вы можете просто ввести «0» в свойство nullvalue.
Если вы используете vs2005, вы должны сделать это с помощью редактора XML. Вы должны добавить msprop: nullValue = "0" в качестве атрибута к столбцу.

Не знаю, почему var x =! IsMyFieldNull ()? MyField: null (или аналогичный) - такая головная боль.

Я полагаю, вы могли бы написать оболочку вокруг SqlDataReader, чтобы каким-то образом улавливать эти нулевые значения, когда вы читаете данные в свой DataTable, или вы могли бы написать эквивалент .TryParse () для ваших запросов: что-то приятное и инкапсулирован как:

var x = myDataTable.TryParse(myField);

где .TryParse - это метод расширения, который выглядит примерно так:

public static TryParse(DataRow myField)
{
    if(!myField == DbNull) //Or similar
       return myField.Value;
}

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

Нулевые типы были введены в .net 3.0, их можно использовать с наборами данных. Вы объявляете nullable int следующим образом. int? myNullableInt = null Вот ссылка на статью в MSDN: Nullable Types C#

Лично я бы вообще избегал нулей в базах данных (если у вас есть такая возможность). NULL действительно существует для того, чтобы обеспечить статус "Неопределено" или "Неизвестно". Редко возникает такая проблема, например, строковое поле, содержащее фамилию, часто устанавливается как nullable, тогда как значение по умолчанию "" было бы гораздо лучшим вариантом. Помещение нулей в базы данных излишне усложняет работу Null Values In Databases, кроме того, это распространяет нули в код, и вам приходится работать над тем, чтобы избежать исключений нулевой ссылки.

К сожалению, в Интернете написано много плохого о БД (например, о том, что чрезмерное использование null - это нормально). Эти точки зрения обычно высказываются людьми, которые действительно не понимают теории, стоящей за ними. Другой классический пример - БД без отношений, "потому что гибче/быстрее обрабатывать их в коде". Это означает, что разработчику приходится переписывать существующую функциональность [уровня базы данных], которую база данных неизбежно обрабатывает более эффективно и с гораздо большей надежностью. Я говорю "неизбежность", поскольку, конечно же, разработчик, выполняющий переписывание, переделывает то, на что Oracle/Microsoft/Whoever потратили много времени, оптимизируя и т.д. Тем не менее, время от времени вы видите, что кто-то выступает за такой дизайн. Этот парень действительно разбирается в базах данных, DBDebunkings он потратил много времени, пытаясь развенчать множество бессмысленных аргументов, которые уводят реляционные базы данных от их теоретических корней.