Формат даты SQL для дат, когда пользователь может не знать всю информацию

Question

Система позволяет зарегистрировать новые пользователи и ввести дату их свадьбы. Будучи пуристом, я хотел сохранить это как дату. После интервью с пользователем было ясно, что реальность отличается от этого подхода. Пользователи часто не уверены в день или месяц, и хотят хранить частичные даты, поэтому «июнь 2009» или «когда-то в 2012 году».

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

Answer 1

Возможно, «нечеткая» дата. Если они скажут «июнь 2009 года», это может быть сохранено как 15 июня 2009 года с разницей в +/- 15 дней.

«примерно в 2010 году» будет 01 июля 2010 года с разницей в 180 дней.

Итак, храните дату и # дней.

Если/как это будет работать на практике, я не знаю. Просто идея. Диапазон дат может быть проще реализовать.

Answer 2

Вы всегда можете хранить дату в отдельных колонках:

• год
• месяц
• день-месяц

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

Answer 3

Вы можете сохранить его в виде диапазона с колонкой после даты и до даты.

Answer 4

Вы можете сохранить даты как YYYYMMDD, с неизвестными месяцами/днями, установленными в 0. например, 20090200 будет «в один прекрасный день в феврале 2009 года». Это позволит вам сортировать и сравнивать относительно легко, и если вам нужно преобразовать его в дату, вы можете просто добавить 1 к месяцу или дню, чтобы приблизиться к более продвинутым сравнениям даты.

Answer 5

У меня была аналогичная проблема с датами; с добавленной проблемой, что некоторые люди также хотели сказать «15 июня», не указав год. Это дело, с которым вам приходится обращаться?

Я сохранил день, месяц и год в трех отдельных столбцах базы данных, с каждой нулевой, затем (несколько) повторно изобрел колесо в моей заявке (а также запретил некоторые случаи, такие как люди, говорящие " 15 марта 1974 года).

Однако, поскольку я поместил всю логику обработки даты в мое приложение, я никогда не обращался к трем столбцам отдельно. Оглядываясь назад, мне хотелось, чтобы я поместил их в одну колонку, содержав частичные даты в виде строк (что-то вроде «19740615», «1974 ----», «---- 0615» и т. Д.), d имеют меньше помех колонок.

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