Допустимые значения NULL против значений по умолчанию

Question

Я работаю над проектом ASP.NET, который заменяет многие существующие бумажные формы. Одним из требований является то, что пользователь может сохранить форму в любом состоянии, то есть он может создать новую пустую форму и сразу же сохранить ее без данных или с частичными данными. Я проверяю тип данных при каждом сохранении, но проверка обязательных полей не происходит, пока пользователь не пометит форму как заполненную.

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

1. Разрешить пустые значения для любого поля, которое может не иметь данных. Это похоже на «правильный» подход, но требует, чтобы почти каждое поле базы данных позволяло принимать значения NULL, и мне приходилось кодировать множество обнуляемых типов. Кроме того, когда форма завершена, в базе данных нет обязательных полей.
2. Заполните мои бизнес-объекты значимыми значениями по умолчанию. В некоторых случаях существуют значимые значения по умолчанию для многих (но не всех) полей, которые я мог бы использовать. Этот подход граничит с «магическими числами», что делает меня неудобным.

Какой подход лучше? Или есть третий путь? Я не готов идти на крайние меры, такие как разделение таблиц.

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

Answer 1

Если разделение таблицы (таблиц) (их больше одного?) Не вариант, я бы подумал о создании одной таблицы для хранения сериализаций объектов неполных форм и фиксации формы в «реальных» таблицах только тогда, когда Форма полностью отправлена ​​пользователем.

Answer 2

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

• людей, которые отправили форму
• людей, которые не

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

Это также повышает эффективность - большинство ваших запросов о совокупных данных будут по первой таблице, а не по второй. Вторая таблица будет использоваться только для поиска индекса.

Answer 3

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

Настройте предварительную таблицу (таблицы) со всем, кроме вашего ключа, обнуляемого. Когда пользователь помечает заполненную форму и проходит проверку, переместите ее в финальную таблицу. Мало того, что это правильно, но это, вероятно, меньше усилий, чем «кодирование обнуляемых значений» при работе с готовыми формами.

Если вам нужно просмотреть все формы, готовые или нет, создайте представление Union.

Answer 4

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

Answer 5

Если разумного значения по умолчанию нет и вы не хотите разделять данные, тогда нулевые значения почти наверняка являются вашим лучшим вариантом. Если БД не проверяет, что они не равны нулю, когда завершено ... хорошо, если вы не хотите разбивать таблицу, вы ничего не можете сделать (если не использовать ограничение CHECK или INSTEAD OF триггер для запуска проверки). Но БД не является единственным местом, ответственным за проверку данных. Логика вашего приложения может сделать это тоже.

Answer 6

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

Answer 7

NULL обычно означает «Не знаю» (в базе данных), тогда как пустая строка может фактически представлять пустую строку.

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

Answer 8

ПРОВЕРЬТЕ ОГРАНИЧЕНИЕ + ПРОСМОТР

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

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

Когда вы пишете свои запросы в «готовых» формах, вы можете игнорировать проверку на наличие нулей везде, если вы делаете один из следующих двух вариантов:

• просто добавьте Status = "F" в предложении where
• смотреть только готовые

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

Answer 9

NULL значения не доступны для поиска по индексам.

Если вам нужно выполнить запрос типа «выберите первые 10 форм с определенным незаполненным полем», этот запрос будет использовать FULL TABLE SCAN, что может быть неэффективно.

Oracle не различает NULL и пустую строку, но другие базы данных делают. Возможно, вы захотите создать пустую строку, которая будет DEFAULT для незаполненных полей, и использовать ее в поиске.

Если вам не нужно искать на незаполненных полях, просто сделайте их NULL.

Answer 10

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

Это мое предложение обойти это.