数据库体系结构的最佳方法主要集中在按年份和按月份同时存储不同字段的数据

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
}

图表如下所示：图表

基本上，一个项目有一个唯一的项目ID，每个项目都有其ProjectMetaData和ProjectData务数据，该年的每个月都有KpiInfo或生产信息。因此，如果我正在获取过去4年到现在的数据，这意味着我正在为一个项目创建大约120多个表，如果是应用程序，这就是我所担心的。变得足够大，正如我之前提到的，这将意味着它以后将不会非常可扩展。

对于这种有许多相同字段版本的数据库，有什么通用的方法吗？

提前感谢，很抱歉，如果我没有说清楚，我很乐意回答任何关于我的问题的疑问

Answer 1

我曾经在一个团队中，为一个拥有奇怪公司日历的企业构建数据库。他们有一个财政年度，分为财政季度、财政月份和财政周。他们希望历史报告按任何一个日期分组。我们最终创建了一个名为Almanac的表，该表每天有一行，主键是某种合适格式的日期。该表包含会计年度、会计月份等列。
然后，我们创建了一个生成器程序，该程序使用大约十年的数据填充该表，并应用公司的所有会计日期分组规则
当我们需要根据这些分组生成历史摘要时，我们只需将交易数据加入日期的年鉴表，然后使用年鉴列进行分组。

你也许可以根据你的情况调整这个概念。数据库会增长，但在未来一段时间内，连接可能是合理的。

Answer 2

您提供的信息有限，很难判断，但我将使用一个表作为示例。

将年份和月份作为列添加到表中。更好的是，添加一个日期列。您可以将日期设置为当月的第一天或最长日期。

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

现在，这一张桌子将足以应付未来的所有时间。是的，您将每年插入12行。