Как хранить в БД неполные/неточные даты?

[XelaX]

Если точная дата не известна, но надо сохранить, то что известно, например (формат DD.MM.YYYY):
1) 21.06.???? - год не известен, но известно, что это 2011 +/- 3 года.
2) 21.??.2011 - месяц не известен, но известно, что это весна, возможно Март +/- 2 месяца
3) ??.03.2011 - дня нет, однако, вероятно, что это во вторая половина Марта, т.е. с 15 по 31
В то же время, могут вводиться полные даты.

По-простому можно реализовать так:
- в форме ввода даты три раздельных поля MM, DD, YYYY
- к этим трём полям есть три check-boxes, означающих примерное или точное введёное значение
- если примерное, то к введёному примерному значению есть ещё одно дополнительное поле, где вводится значение отклонения (+/-), например, 3 и 2 как в примерах 1 и 2.
Т.е., всего 9 не всегда заполняемых полей.
Но даже в этом сильно избыточном подходе непонятно, как это всё сохранить в БД в максимально компактном виде (с минимальным количеством полей) с одной стороны, а с другой стороны, чтобы сохранение-хранение/извлечение/индексирование/фильтрование/обработка занимали минимум времени-места.
Гуглил, но безрезультатно.

Кто нибудь встречался с оптимальными вариантами решения подобной проблемы?
Заранее спасибо!

[ak3]

В одном поле - скорее никак. Будет либо компактно, либо удобно, либо точно.
Надо определиться, как оно потом будет использоваться.
Да и откуда оно приходит такое, кто решает насчёт примерных дат?

Я бы хранил в нескольких полях:
- Собственно оригинальный вариант:
- строкой в каком-нибудь стандартном написании типа YYYY-MM-DD , с placeholders на месте неизвестных частей (можно и без этого поля, кмк)
- эту примерную дату как дату/время
- отклонение (+/-) value + units - два отдельных поля.
- Флаг (точное|примерное) значение ... он из оригинального варианта может быть получен - если в строке есть placeholder. Можно и без него обойтись. Разве что просто для истории. Отклонение может его заменить.
- Примерный/точный период: начало и конец как отдельные поля дата/время, значения получены так как у вас указано. Может быть даже вычислено из оригинального варианта + отклонение.
(для точных/полных дат начало и конец бы совпадали)

Тогда поиск бы был всегда по периоду. По нему же можно и индексировать.

[ie]

как вариант заводится одно поле date второе как индикатор what's missing

например если у вас may ?? 1981 в первом поле будет 05/01/1981 во втором 2 - индиктор того что день не точен,
ну и может быть еще одно поле которое указывает насколько не точен.

мне кажется с date должно быть легче работать в некторых случаях....

[Relict17]

1) 21.06.???? - год не известен, но известно, что это 2011 +/- 3 года.
2) 21.??.2011 - месяц не известен, но известно, что это весна, возможно Март +/- 2 месяца
3) ??.03.2011 - дня нет, однако, вероятно, что это во вторая половина Марта, т.е. с 15 по 31

Храним 2 даты, начала и конца диапазона неопределенности.
1) 21.06.2008 - 21.06.2014
2) 21.01.2011 - 21.05.2011
3) 15.03.2011 - 31.03.2011

[zgur]

Я бы завел child таблицу в которой бы хранил все возможные варианты;
1. 21.06.2008, 21.06.2009, 21.06.2010,21.06.2011,21.06.2012,21.06.2013,21.06.2015
2. 21.01.2011,21.02.2011,21.03.2011,21.04.2011,21.05.2011,21.06.2011
3. 15.03.2011,16.03.2011 - 31.03.2011

[vdfs]

Если бы мне поставили такую задачу, я бы, наверное, уточнил, какие объёмы данных будут, и как их потом собираются использовать. Т.е. прикинуть типовые запросы к этому хранилищу и, исходя из этого, продумывать структуру.

[Palych]

Если пихать в varchar - надобно придумать язык (формат) для описания диапазонов/неточностей.
Мне лично пока нравится идея хранения начала и конца диапазона.