Подход для хранения около и фактических дат в модели данных генеалогии - PullRequest
Новая
       32

Подход для хранения около и фактических дат в модели данных генеалогии

1 голос
/ 24 марта 2012

Я занимаюсь разработкой приложения по генологии, и мне нужно хранить даты событий.Однако мне нужно иметь возможность поддерживать приблизительно даты и фактические даты, поэтому я думаю о наличии столбцов evendate и ceventdate (для приблизительно), чтобы я мог индексировать дату события, когда она доступна.

Однако, чем больше я думаю о том, тем больше я задаюсь вопросом, должно ли у меня быть вместо этого: eventyear, eventmonth, eventday, около (определение), чтобы я мог хранить годы и месяцы от анализа около.

Мысли

Ответы [ 2 ]

2 голосов
/ 28 марта 2012

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

Я недавно написал сообщение в блоге о датах GEDCOM . Вот что я сказал:

Базовая дата в GEDCOM выглядит следующим образом: дд МММ гггг, например 02 июля 1917 года.

Что нужно знать об этой базовой дате: вы можете указать «день» месяц год », или« месяц год »или« просто год ». День может быть 1 или 2 цифры, то есть 02 июля 1917 года или 2 июля 1917 года.

Для приблизительных дат они используют:

  • ABT дата
  • CAL дата
  • EST дата

где ABT означает «примерно» и является для неточной даты. CAL рассчитывается математически, например, по дате и возрасту события, а EST оценивается на основе алгоритма с использованием какой-либо другой даты события.

Существует также множество других конструкций, включая интерпретированные даты и фразы.

Поскольку вы, скорее всего, захотите, чтобы ваше генеалогическое приложение импортировало из GEDCOM и экспортировало в GEDCOM, вы можете выбрать некоторую реализацию дат, которую будет легко перевести в / из формата GEDCOM.

0 голосов
/ 27 марта 2012

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

Если вы ожидаете использовать только приблизительную дату, которая может иметь точность либо месяца, либо года, я бы предложил следующее: Используйте поле event_date для точных дат в любой таблице, которую вы отслеживаете, вероятно, в таблице events. Для приблизительных дат используйте event_date, но добавьте month или year к столбцу accuracy. Ваша система может затем принять введенную дату только с точностью, указанной в этом столбце. Если ваши даты должны быть датой-временем, то accuracy можно легко расширить, чтобы принять во внимание день.

Если вы имеете дело с датами, которые могут охватывать две точности, я бы предположил, что вы используете предыдущую информацию с несколькими дополнительными критериями: Если допущения в таблице events верны, вам потребуется дополнительная таблица для event_dates, в которой будут использоваться столбцы даты, которые я обсуждал ранее. Эта новая таблица также будет нуждаться в столбце для date_type, который представляет начало или конец события около даты. Для таблицы event_dates потребуется ссылка на event_id, чтобы поддерживать связь.

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

Надеюсь, это поможет.

...