Должен АННУЛИРОВАТЬ быть обработанным в коде или в базе данных? Преимущества и Недостатки?
При попытке попасть в точку оператор (общее количество плюс подкачка страниц). Вы, возможно, должны были бы исследовать поддержку SQL Server для раздела пунктом (функции работы с окнами в терминах ANSI SQL). В Oracle синтаксис точно так же, как пример выше использования row_number (), но я также добавил раздел пунктом для получения общего количества строк, включенных с каждой строкой, возвращенной в подкачке страниц (строки итогов 1,262):
SELECT rn, total_rows, x.OWNER, x.object_name, x.object_type
FROM (SELECT COUNT (*) OVER (PARTITION BY owner) AS TOTAL_ROWS,
ROW_NUMBER () OVER (ORDER BY 1) AS rn, uo.*
FROM all_objects uo
WHERE owner = 'CSEIS') x
WHERE rn BETWEEN 6 AND 10
Примечание, которое я имею, где владелец = 'CSEIS' и мой раздел находятся на владельце. Таким образом, результаты:
RN TOTAL_ROWS OWNER OBJECT_NAME OBJECT_TYPE
6 1262 CSEIS CG$BDS_MODIFICATION_TYPES TRIGGER
7 1262 CSEIS CG$AUS_MODIFICATION_TYPES TRIGGER
8 1262 CSEIS CG$BDR_MODIFICATION_TYPES TRIGGER
9 1262 CSEIS CG$ADS_MODIFICATION_TYPES TRIGGER
10 1262 CSEIS CG$BIS_LANGUAGES TRIGGER
9 ответов
Мой общий совет - объявлять поля в базе данных как NOT NULL , если только у вас нет особой потребности разрешить нулевые значения, поскольку они обычно очень сложно для людей, плохо знакомых с базами данных.
Обратите внимание, что пустая строка и поле с пустой строкой не обязательно означают одно и то же (если вы не определите их так). Часто null означает «неизвестно» или «не предоставлено», тогда как пустая строка - это всего лишь предоставленная и известная пустая строка.
Разрешение или запрет пустых полей полностью зависит от ваших потребностей.
NULL хранится более эффективно (битовая карта NULL), чем пустая строка (2 байта для длины varchar или «n» для char)
Блог механизма хранения: Почему растровое изображение NULL в запись оптимизация?
Я видел несколько статей, в которых говорится по-другому, но для char / varchar я обнаружил, что NULL полезен и склонен рассматривать пустую строку так же, как NULL. Я также обнаружил, что NULL быстрее в запросах, чем пустая строка. YMMV, конечно, и я буду оценивать каждый случай по достоинству.
Вы смешиваете проблему реализации с проблемой архитектуры логических данных.
Вы должны решить, разрешать ли пустые значения в поле, основываясь исключительно на том, точно ли оно моделирует данные, которые вы ожидаете хранить в базе данных. Часть путаницы, как указали некоторые другие, заключается в том, что пустые и пустые строки - это не просто два способа хранения одной и той же информации.
Нулевое значение означает, что либо значение отсутствует, либо значение неизвестно.
Пустая строка означает, что есть значение, и это пустая строка.
Позвольте мне продемонстрировать на примере. Скажем, например, у вас есть поле отчества и вам нужно различать ситуации, когда отчество не указано, и когда у человека нет отчества. Используйте пустую строку, чтобы указать, что второго имени нет, и значение null, чтобы указать, что оно не было введено.
Почти во всех случаях, когда значение null имеет смысл с точки зрения данных, они должны обрабатываться в коде приложения, не база данных в предположении, что БД должна различать два разных состояния.
Краткая версия: Не выбирайте пустую или пустую строку на основе проблем производительности / хранения в БД, выберите тот, который лучше всего моделирует информацию, которую вы пытаетесь сохранить.
Основное преимущество заключается в том, что вы можете обрабатывать пустые и пустые строки отдельно как в коде .NET, так и в SQL - в конце концов, они могут означать разные вещи.
Обратной стороной является необходимость быть осторожным; в .NET вы не должны вызывать obj.SomeMethod () для null, а в SQL вам нужно следить за тем, чтобы пустые значения распространялись при объединении (в отличие, например, от конкатенации строк C #).
На самом деле нет заметная разница в размерах между нулевым и пустым. В коде .NET я надеюсь , что он использует интернированную пустую строку, но это не будет иметь большого значения.
Я думаю, что нулевое значение и пустая строка - две разные вещи как в коде, так и в базе данных. Нулевое значение переменной или поля означает, что у них нет значения, но если одно из них является пустой строкой, оно имеет значение, которое оказывается пустой строкой.
1: Очень субъективно, как отмечается в других ответах, есть ощутимая разница между NULL (нет ответа / неизвестно) и «» (известно, что ничего / не применимо, т.е. человек без середины имя).
2: Так не должно быть.
3: AFAIK (я все еще младший / обучающийся администратор баз данных, так что воспринимайте это с недоверием), но эффекта не должно быть.
4: Это спорно. Теоретически, если вы применяете ограничение NOT NULL к полю базы данных, вам никогда не придется обрабатывать значение NULL. На практике разрыв между теорией и практикой в теории меньше, чем на практике. (Другими словами, вам, вероятно, все равно следует обрабатывать получение NULL, даже если это теоретически невозможно.)
Я обычно при проектировании по умолчанию использую NOT NULL , если не указано иное - особенно денежные / десятичные столбцы в бухгалтерском учете - обычно обычно никогда не неизвестный аспект к этим. Могут быть случаи, когда денежный столбец является необязательным (например, система опросов или деловых отношений, в которую вы указываете свой семейный / деловой доход - это может быть неизвестно до тех пор, пока / если отношения будут установлены менеджером по работе с клиентами). Например, для datetime я бы никогда не разрешил столбец NULL RecordCreated, тогда как столбец BirthDate разрешил бы NULL .
NOT NULL столбцы удаляют много потенциального дополнительного кода и гарантируют, что пользователям не придется учитывать NULL с особой обработкой - особенно хорошо в представлениях уровня представления или словарях данных для отчетов.
Я думаю, что во время разработки важно уделять много времени обработке типов данных (char vs. varchar, vs. nchar vs. nvarchar, money vs. decimal, int vs. varchar, GUID vs. identity), NULL / NOT NULL, первичный ключ, выбор кластерного индекса и некластеризованных индексов и столбцов INCLUDE. Я знаю, что это, вероятно, звучит так же, как и все в дизайне БД, но если ответы на все эти вопросы будут понятны заранее, вы получите гораздо лучшую концептуальную модель.
Обратите внимание, что даже в базе данных, где нет разрешенных столбцов NULL , a LEFT JOIN в представлении может привести к NULL
Для конкретного случая процесса принятия решения, давайте возьмем простой случай Address1, Address2, Address3 и т. д. all varchar (50) - довольно распространенный сценарий (который лучше представить в виде одного столбца ТЕКСТ, но предположим, что он смоделирован таким образом). Я бы не допустил NULL и по умолчанию использовал бы пустую строку. Причина этого:
1) На самом деле это не неизвестно - пусто. Природа UNKNOWN между несколькими столбцами никогда не будет четко определена. Маловероятно, что у вас будут ИЗВЕСТНЫЙ адрес1 и НЕИЗВЕСТНЫЙ адрес2 - вы либо знаете весь адрес, либо нет. Если у вас не будет ограничений, оставьте их пустыми и не допускайте NULL.
2) Как только люди начинают наивно делать такие вещи, как Address1 + @CRLF + Address2 - NULL начинают превращаться в NULL из всего адреса! Если вы не собираетесь заключить их в представление с ISNULL или изменить настройки ANSI NULL, почему бы не оставить их пустыми - в конце концов, именно так они видны пользователям.
Я бы хотел использовать, вероятно, ту же логику для отчества или инициала отчества, в зависимости от того, как оно используется - есть ли разница между кем-то без второго имени или кем-то, чье имя неизвестно?
В некоторых случаях я бы, вероятно, даже не разрешил пустую строку - и я бы сделал это по принуждению. Например - имя и фамилия пациента, название компании клиента. Они никогда не должны быть пустыми или пустыми (или все пробелы или что-то подобное). Чем больше этих ограничений существует,
Помещение поддельных данных (пустая строка для строковых данных, 0 для чисел, некоторая неопределенная дата для дат) вместо null в базе данных почти всегда является плохим выбором. Эти поддельные значения не означают одно и то же, и особенно для числовых данных трудно получить поддельное значение, которое не совпадает с реальным значением. И когда вы вводите неверные данные, вам все равно нужно писать код, чтобы убедиться, что все обрабатывается правильно (например, не возвращать те записи, у которых нет даты окончания), поэтому вы фактически ничего не сохраняете на стороне разработки.
Если вы не можете знать данные во время вставки записи, лучшим выбором будет null. Тем не менее, если данные будут известны, по возможности используйте not null.
You should look into sixth normal form. 6NF was specifically invented to get rid of the problems introduced by the use of NULLS. A lot of those problems are made worse by SQL's three valued logic (true, false, unknown), and the programmer's common use of two valued logic.
In 6NF, every time a row/column intersection would have to be flagged as NULL, the situation can be handled by simply omitting the row.
However, I generally do not try for 6NF in database design. Most of the time, NULLable columns are not used as part of search criteria or join criteria, and the problems with NULLS don't surface.