Любое предложение для дизайна данных БД для этой проблемы?

Question

Это немного сложно. Я постараюсь быть максимально ясным.

Это рабочий план. Мы оцениваем общее время, необходимое для выполнения задачи, скажем, 100 часов, и разбиваем его на месячные периоды. Например, 30 часов должно быть сделано в марте, 20 часов в апреле и 50 часов в мае. После каждого месяца план может быть изменен. Мне нужно хранить как обновленную версию, так и исторические версии плана в БД, чтобы увидеть тенденцию и предсказать будущее.

Важна сумма оставшихся часов для каждой задачи (чтобы нарисовать диаграмму разбивки, вы, возможно, уже заметили, что мы используем скрам-модель). Я не уверен, как сделать его максимально гибким. И я планирую использовать Access 2003. Я немного обеспокоен производительностью, если число записей растет слишком быстро.

Есть какие-нибудь предложения для меня? Большое спасибо.

Answer 1

TaskMaster
   tid
   datecreated
   estimatehours

TaskBreak
   tid
   dateupdate
   month
   hours

здесь, в TaskBreak (tid, dateupdate), это первичный ключ.Когда вы обновляете часы своей задачи, вносите новую запись в таблицу TaskBreak.Таким образом, у вас будут как обновленные версии, так и исходная версия задачи.
Если вы обновляете план задач только раз в месяц, вы можете хранить только месяц и год в столбце dateupdate таблицы TaskBreak.

Answer 2

Я бы разработал это с каждым набором ежемесячных прогнозов, обработанным как группа строк. Для поддержки исторических данных добавьте поле «дата создания». Так что-то вроде (это синтаксис T-SQL, я давно отказался от Access):

CREATE TABLE dbo.TaskEstimates
(
    DateCreated         datetime    NOT NULL,
    EstimateYearMonth   datetime    NOT NULL,
    HoursRequired       decimal     NOT NULL,

    CONSTRAINT PK_TaskEstimates PRIMARY KEY CLUSTERED
    (
        DateCreated     ASC,
        EstimateMonth   ASC
    )
);

Поле DateCreated будет, например, одинаковым для всех членов оценочного набора, введенного сегодня. Поле EstimateYearMonth содержит только год и месяц (день = 1, часть времени = 0: 00: 00.000).

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

В дополнение или вместо поля DateCreated вы также можете использовать GroupID, который увеличивается для каждого набора. Таким образом, первый набор all имеет GroupID == 1, следующий набор == 2 и так далее. Это может быть проще для исторического выбора, если вам задают вопросы с подсчетом запросов вместо вопросов с датированными запросами; например «дайте мне оценки за 3-й цикл» вместо «дайте мне оценки, сделанные в июне».

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