Лучший подход к архитектуре базы данных, ориентированной на одновременное хранение данных разных полей по годам и месяцам.

Question

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

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

entity Project {
    projectId Long required
}

entity ProjectData {
    yearId Long required
}

entity ProjectMetaData {
    projectManager String,
    company String,
    agency String
}

entity FinancialData {
    monthId Long required
}

entity KpiInfo {
    otd Long,
    oqd Long,
    cumulatedOqd Long,
    cumulatedOtd Long
}

entity ProductionInfo {
    averageDailyCost Long,
    averageDailyRevenue Long,
    managementWorkload Long,
    internalWorkload Long,
    offshoreWorkload Long
}

relationship OneToOne {
    Project to ProjectMetaData
    ProjectData to FinancialData
}


relationship OneToMany {
    Project to ProjectData
    FinancialData to KpiInfo
    FinancialData to ProductionInfo
}

Диаграмма выглядит так: диаграмма

Обычно Project имеет уникальный идентификатор проекта и у каждого проекта есть свои ProjectMetaData и ProjectData , после этого для каждого года, в течение которого проект реализуется, у проекта есть FinancialData , и для каждого месяца этого год, есть KpiInfo и ProductionInfo . Поэтому, если я получаю данные за последние 4 года до настоящего времени, это означает, что я создаю около 120+ таблиц для одного проекта, и меня это беспокоит, если приложение. становится достаточно большим, как я упоминал ранее, это будет означать, что впоследствии он не будет очень масштабируемым.

Есть ли какой-либо общий подход для такого рода баз данных, где есть много версий одних и тех же полей?

Заранее спасибо и извините, если я не совсем ясно выразился, я буду рад ответить на любые сомнения относительно моего вопроса

Answer 1

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

Добавьте год и месяц в качестве столбцов в таблице. А еще лучше добавить столбец даты. Вы можете установить день как 1-й или максимальный для этого месяца.

entity KpiInfo {
    year
    month
    otd Long,
    oqd Long,
    cumulatedOqd Long,
    cumulatedOtd Long
}

Этой одной таблицы теперь хватит на все времена в будущем. Да, вы будете вставлять 12 строк каждый год.

Answer 2

Однажды я был в команде, которая должна была создать базу данных для предприятия, у которого был странный корпоративный календарь. У них был финансовый год, разделенный на финансовые кварталы, разделенные на финансовые месяцы, разделенные на финансовые недели. Им нужны исторические отчеты, сгруппированные по любой из этих групп дат. в итоге мы создали таблицу под названием Almana c, в которой была одна строка в день, а первичным ключом была дата в некотором подходящем формате. В таблице были столбцы для финансового года, финансового месяца и т. Д. c. Затем мы создали программу-генератор, которая заполнила эту таблицу данными примерно за десять лет, применив все правила компании для группировки финансовых дат. Когда нам нужно было составить исторические сводки на основе этих группировок, мы просто присоединяли данные транзакции к таблице Almana c по дате, а затем использовали столбцы Almana c для целей Group By.

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