Я должен позволить нулевые значения в схеме дб?
Я не знаю, конвертируется ли это из VB в C #, но если вам не нужны кавычки вокруг ваших чисел, вы можете сравнить тип данных следующим образом.
public string DataTableToCSV(DataTable dt)
{
StringBuilder sb = new StringBuilder();
if (dt == null)
return "";
try {
// Create the header row
for (int i = 0; i <= dt.Columns.Count - 1; i++) {
// Append column name in quotes
sb.Append("\"" + dt.Columns[i].ColumnName + "\"");
// Add carriage return and linefeed if last column, else add comma
sb.Append(i == dt.Columns.Count - 1 ? "\n" : ",");
}
foreach (DataRow row in dt.Rows) {
for (int i = 0; i <= dt.Columns.Count - 1; i++) {
// Append value in quotes
//sb.Append("""" & row.Item(i) & """")
// OR only quote items that that are equivilant to strings
sb.Append(object.ReferenceEquals(dt.Columns[i].DataType, typeof(string)) || object.ReferenceEquals(dt.Columns[i].DataType, typeof(char)) ? "\"" + row[i] + "\"" : row[i]);
// Append CR+LF if last field, else add Comma
sb.Append(i == dt.Columns.Count - 1 ? "\n" : ",");
}
}
return sb.ToString;
} catch (Exception ex) {
// Handle the exception however you want
return "";
}
}
14 ответов
Наиболее важной причиной для разрешения NULLS является отсутствие разумной альтернативы. Логически значение NULL представляет собой «неопределенное». Из-за отсутствия NULL вы в конечном итоге попытаетесь указать «фиктивное» значение везде, где результат не определен, а затем вам придется учитывать это «фиктивное» значение во ВСЕЙ логике вашего приложения.
Я написал статья в блоге о причинах включения значений NULL в вашу базу данных. Вы можете найти его здесь . Короче говоря, я ДЕЙСТВИТЕЛЬНО верю, что значения NULL являются неотъемлемой частью дизайна базы данных и должны использоваться там, где это необходимо .
Я согласен с большинством приведенных здесь ответов, но, говоря по-другому, «вы не можете иметь значение, которое означает две вещи». Это просто сбивает с толку. 0 на самом деле означает 0? или это значит, что мы еще не знаем? и т. д.
НИКОГДА не будет случая, когда NULL имеет логический смысл. NULL не является частью реляционной модели, а в реляционной теории нет такого понятия, как NULL.
NULL является «полезным» в том смысле, что дрянные СУБД не оставляют вам другого выбора, кроме как использовать его на ФИЗИЧЕСКОМ уровень, который сами эти дрянные СУБД серьезно путают с логическим уровнем,
Как бы то ни было, SQL-99 определяет предикат IS [NOT] DISTINCT FROM , который возвращает истину или ложь, даже если операнды равны NULL.
foo IS DISTINCT FROM 1234
Is эквивалент:
foo <> 1234 OR foo IS NULL
Поддержка PostgreSQL, IBM DB2 и Firebird ОТЛИЧАЕТСЯ ОТ .
Oracle и Microsoft SQL Server этого не делают (пока).
MySQL имеет собственный оператор <=> , который работает так, как будто НЕ ОТЛИЧИТСЯ ОТ .
В дополнение к веским причинам, упомянутым в других ответах, NULL может быть очень важным для новых выпусков существующих продуктов.
Добавление нового столбца, допускающего значение NULL, в уже существующую таблицу имеет относительно небольшое влияние. Добавление нового столбца, не допускающего значения Nullable, представляет собой гораздо более сложный процесс из-за миграции данных. Если у вас или ваших клиентов имеется много данных, время и сложность миграции могут стать серьезной проблемой.
Теоретически разницы между теорией и практикой нет. На практике это так.
Теоретически вы можете разработать базу данных, в которой никогда не будет NULL, поскольку она полностью нормализована. Всякий раз, когда значение должно быть опущено, всю строку, содержащую его, можно опустить, поэтому нет необходимости в каком-либо NULL.
Однако степень декомпозиции таблицы, которую вы должны пройти, чтобы получить этот результат, просто не стоит выгода с точки зрения теоретической эстетики. Часто лучше, чтобы некоторые столбцы содержали NULL.
Хорошими кандидатами для столбцов, допускающих значение NULL, являются столбцы, в которых, помимо того, что данные являются необязательными, вы никогда не используете столбец в условии сравнения в предложении WHERE или HAVING. Хочешь верь, хочешь нет, внешние ключи часто работают нормально с NULLS в них, чтобы указать на экземпляр отношения, которого нет. INNER JOINS удалит NULLS вместе со строками, которые их содержат.
Когда значение часто используется в логических условиях, лучше всего спроектировать так, чтобы не было NULLS. В противном случае вы можете получить таинственный результат, что в SQL значение «NOT UNKNOWN» равно «UNKNOWN». Это вызывало ошибки у многих людей до вас.
"НЕИЗВЕСТНО". Это вызывало ошибки у многих людей до вас. "НЕИЗВЕСТНО". Это вызывало ошибки у многих людей до вас.CJ Date в своей книге «SQL и Relational Theory» (2009: O'Reilly; ISBN 978-0-596-52306-0) высказывает очень сильную позицию против NULL. Он демонстрирует, что наличие NULL в SQL дает неправильные ответы на определенные запросы. (Этот аргумент неприменим к самой реляционной модели, потому что реляционная модель не допускает NULL.)
Я попытаюсь резюмировать его пример словами. Он представляет таблицу S с атрибутами SNO (Номер поставщика) и Город (Город, где находится поставщик) и одну строку: (S1, Лондон). Также таблица P с атрибутами PNO (номер детали) и City (город, где производится деталь) и одна строка: (P1, NULL). Теперь он выполняет запрос «Получить пары (SNO, PNO), в которых либо город-поставщик и город-часть отличаются, либо город-часть не является Парижем (или обоими)».
В реальном мире, P1 создается в городе, который является или не является Парижем, поэтому запрос должен возвращать (S1, P1), потому что частичный город либо является Парижем, либо не является Парижем. (Простое присутствие P1 в таблице P означает, что с этой деталью связан город, даже если он неизвестен.) Если это Париж, то города-поставщики и города-детали различны. Если это не Париж, то город-часть - это не Париж. Однако по правилам трехзначной логики ('London' <> NULL) оценивается как UNKNOWN, (NULL <> 'Paris') оценивается как UNKNOWN, а UNKNOWN OR UNKNOWN сокращается до UNKNOWN, что не является ИСТИНОЙ (и не ЛОЖЬ тоже), и поэтому строка не возвращается. Результатом запроса «SELECT S.SNO, P.PNO FROM S, P WHERE S.CITY <> P.CITY OR P.CITY <> 'Paris'» является пустая таблица, что является неправильным ответом.
Я' м не эксперт и в настоящее время не оборудован, чтобы высказывать здесь за или против. Я действительно считаю CJ Date одним из ведущих авторитетов в области теории отношений.
PS Верно и то, что вы можете использовать SQL не как реляционную базу данных. Он может многое.
Нулевые значения должны и должны использоваться в любое время, когда информация может быть недоступна на момент ввода исходных данных (например, дата отгрузки в заказе ).
Конечно, бывают ситуации, когда нули могут указывать на необходимость изменения дизайна (таблица, состоящая в основном из пустых записей в большинстве полей, вероятно, не нормализована должным образом, поле, содержащее все нулевые значения, вероятно, не требуется).
Чтобы не было используйте нули, потому что ваши младшие разработчики не понимают их должным образом, указывает на то, что у вас есть более серьезная проблема, чем нули. Любой разработчик, который не понимает, как получить доступ к данным, содержащим нули, должен пройти базовое обучение SQL. Это так же глупо, как не использовать триггеры для обеспечения соблюдения правил целостности данных, потому что разработчики забывают смотреть на них, когда возникает проблема, или не используют объединения, потому что разработчики их не понимают, или используют select *, потому что разработчики слишком ленивы, чтобы добавлять имена полей.
поле, содержащее все значения NULL, вероятно, не требуется.)Отказ от использования NULL из-за того, что ваши младшие разработчики не понимают их должным образом, означает, что у вас есть более серьезная проблема, чем с нулями. Любой разработчик, который не понимает, как получить доступ к данным, содержащим нули, должен пройти базовое обучение SQL. Это так же глупо, как не использовать триггеры для обеспечения соблюдения правил целостности данных, потому что разработчики забывают смотреть на них, когда возникает проблема, или не используют объединения, потому что разработчики их не понимают, или используют select *, потому что разработчики слишком ленивы, чтобы добавлять имена полей.
поле, содержащее все значения NULL, вероятно, не требуется.)Отказ от использования NULL из-за того, что ваши младшие разработчики не понимают их должным образом, означает, что у вас есть более серьезная проблема, чем с нулями. Любой разработчик, который не понимает, как получить доступ к данным, содержащим нули, должен пройти базовое обучение SQL. Это так же глупо, как не использовать триггеры для обеспечения соблюдения правил целостности данных, потому что разработчики забывают смотреть на них, когда возникает проблема, или не используют объединения, потому что разработчики их не понимают, или используют select *, потому что разработчики слишком ленивы, чтобы добавлять имена полей.
Чтобы понять, как получить доступ к данным, содержащим пустые значения, необходимо пройти базовое обучение SQL. Это так же глупо, как не использовать триггеры для обеспечения соблюдения правил целостности данных, потому что разработчики забывают смотреть на них, когда возникает проблема, или не используют объединения, потому что разработчики их не понимают, или используют select *, потому что разработчики слишком ленивы, чтобы добавлять имена полей. Чтобы понять, как получить доступ к данным, содержащим пустые значения, необходимо пройти базовое обучение SQL. Это так же глупо, как не использовать триггеры для обеспечения соблюдения правил целостности данных, потому что разработчики забывают смотреть на них, когда возникает проблема, или не используют объединения, потому что разработчики их не понимают, или используют select *, потому что разработчики слишком ленивы, чтобы добавлять имена полей.Значение NULL полезно всякий раз, когда вам нужно указать, что значение отсутствует вообще.
Вместо этого вы можете использовать магическое число, но обработка значений NULL более интуитивно понятна, чем обработка магических значений. , и легче запомнить, какое значение обрабатывать. (Хм ... это было -1, или 99999, или 999999, что было магическим значением ...?)
Кроме того, магические значения не имеют никакого реального волшебства, нет никаких безопасных ошибок, чтобы удержать вас от использования значения тем не мение. Компьютер не знает, что вы не можете умножить 42 на -1, потому что -1 оказывается в этой ситуации необоснованным значением, но он знает, что вы не можете умножить 42 на null.
Для текстового значения пустая строка может работать как «без значения», но и здесь есть некоторые недостатки. Если у вас, например, три пробела в поле, это '
Обычно, если вы разрешаете NULL для столбца в базе данных, это значение NULL имеет отдельные , что означает в отношении структуры самой базы данных. Например, в схеме базы данных StackOverflow , NULL для столбца ParentId или Tags в таблице сообщений указывает, является ли сообщение вопросом или ответом. Просто убедитесь, что в каждом случае значение хорошо задокументировано.
Теперь ваша конкретная жалоба касается обработки этих значений в клиентском коде. Есть два способа смягчить проблему:
Большинство случаев со смыслом, подобным описанному выше, никогда не должны возвращаться клиенту в первую очередь. Используйте NULL в своих запросах для сбора правильных результатов, но не возвращайте сам столбец NULL.
В остальных случаях вы обычно можете использовать такие функции, как COALESCE () или ISNULL (), чтобы вернуть то, что легче
Нулевые значения хороши, когда ваш столбец действительно может иметь неизвестное значение, которое не имеет значения по умолчанию. Мы не можем ответить, применяется ли ваш столбец к этому правилу.
например, если у вас есть дата окончания, у вас может возникнуть соблазн ввести datetime.maxvalue в качестве значения по умолчанию вместо null. это совершенно верно, но вы должны принять во внимание отчеты, которые делаются по этому поводу и тому подобное.
Это больше для удобства. Нет официального способа сказать. Но использование XML-файлов имеет смысл, поскольку ими можно манипулировать с помощью различных других приложений / библиотек.
А вот несколько советов с точки зрения производительности:
- В
Oracle,NULLне индексируются. Вы можете сэкономить пространство индекса и ускорить запросы, используяNULLдля значений, которые вам не нужно индексировать. - В
OracleконечныйNULLне занимают места. - В отличие от нулей,
NULLможно безопасно разделить на. NULLвносят вклад вCOUNT (*), но не вносят вклад вCOUNT (столбец)
Причины наличия нулей
- Это общепринятая практика, и каждый, кто работает с базой данных, знает, как работают нули.
- Это ясно показывает, что отсутствует значение.