Стратегия для неполных дат

Question

Работа над приложением, в котором мы хотели бы, чтобы пользователь мог вводить неполные даты.

В некоторых случаях будет только год - скажем, 1854, или может быть год и месяц, например март 1983 г., или может быть полная дата - 11 июня 2001 г.

Мы хотели бы иметь один атрибут / столбец даты и иметь возможность сортировки по дате.

Есть предложения?

Answer 1

Сохранить дату как целое число - ггггммдд.

Затем можно обнулить любой месяц или день, который не был введен

Year only: 1954 => 19540000
Year & Month: April 2004 => 20040400
January 1st, 2011 => 20110101

Конечно, я предполагаю, что вам не нужно хранить информацию о времени суток.

Затем можно создать структуру для инкапсуляции этой логики с полезными свойствами, указывающими, какой уровень детализации был установлен, соответствующий System.DateTime и т. Д.

Редактировать: сортировка должна работать хорошо

Answer 2

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

Проблема, с которой вы столкнулись бы, если бы использовали январь в качестве месяца по умолчанию и 1 в качестве дня по умолчанию, как предлагали другие, - что произойдет, когда они на самом деле выберут январь?Как вы будете отслеживать, если это выбранный январь или январь по умолчанию.

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

M | D | Y | H | Min | S

Только месяц 1 | 0 |0 | 0 | 0 | 0 = 32

Только год 0 | 0 | 1 | 0 | 0 | 0 = 8

Месяц + Год 1 | 0 | 1 | 0 | 0 | 0= 40

AllButMinSec 1 | 1 | 1 | 1 | 0 | 0 = 60

Вы можете поместить это в Flag Enum, чтобы упростить использование в коде.

Answer 3

Когда я в последний раз решал эту проблему, я создал собственный тип даты, который отслеживал, какие части даты были фактически установлены, и предоставлял преобразования в и из DateTime. Для хранения в базе данных я использовал одно поле даты, а затем одно логическое значение / бит, чтобы отслеживать, какие компоненты даты были фактически установлены пользователем.

Answer 4

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

Поэтому будет сложнее запросить кодировку этих состояний в самой дате и времени.

Answer 5

Один из вариантов - использовать январь в качестве месяца по умолчанию, 1 в качестве дня по умолчанию и 1900 или что-то подобное в качестве года по умолчанию. Неполные даты будут дополнены этими значениями по умолчанию, а неполные даты будут отсортированы перед полными в том же году.

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

Answer 6

Что ж, вы можете сделать это через один столбец и поле с надписью 'IsDateComplete'.

Если у вас только есть поле даты, то вам нужно закодировать "неполнота »в самом формате даты, например, если дата, скажем, <1900, считается« неполной ». </p>

Лично я бы выбрал поле на стороне, помечающее его как таковое,Проще следовать, легче принимать решения и учитывать любые даты.

Само собой разумеется, что вы можете просто создать дату из DateTime.MinValue, а затем установить то, что вы «знаете».

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

В любом случае, некоторые мысли для вас.