我正在进行数据库增强，这将增加资源跟踪，为期12个月前滚（预测）。换句话说，一个人预计在本月，下个月和12个月后花在项目上的时间是多少;在他们目前正在进行的每个项目上都有。
我试图想出最好的方法，并提出以下表格格式（请记住这是一个现有的数据库，所以有些字段映射到其他表格中的字段）
表格式1：
百分比（这是一个人预计在项目上花费的一个月的时间）
基本上，这会为每个月（12个月）的每个项目创建一条记录，以便进行联系。我对此的保留意见是该表可以很快获得大量记录。这根本不是什么大不了的事，而是我个人试图避免的事情。
表格式2：
百分比
我还在考虑使用M0，M1 ... M11而不是月份名称，这是我的第二点：
现在，除了上面两个选项之外，我还需要考虑设计表单来输入数据的最佳方法。我希望有几个月的顺序，第一个月是当月，如下：
九月|十月| ... |八月
但我无法想到让Access在表单上以这种方式组织月份的方法。为了解决这个问题，我想到了使用M0 | M1 | ... | M11，但最终用户可能不知道哪个月等同于另一个月。
我确定我缺少信息，因此我会根据需要添加。我无法上传副本，因为它是专有信息。我或多或少地寻找关于做这些表的最佳方式的第二意见。任何建议或恶魔倡导者表示赞赏。
答案 0 :(得分：0)
在数据库设计中总是建议使用规范化，因此我会选择表格式1 - [CapacityMonth]选项。但是对于你的情况，这是第一种方法的几个原因：
结构：长格式表总是比宽格式表更好。在Access中，行是廉价的，因为列涉及表结构设计（例如，Access对行没有限制但对列有255限制）。 Think BackEnd更改与FrontEnd应用程序设计更改。此外，索引，查询，聚合，合并和重塑比使用宽格式（甚至更少的表单/报表控件）更容易，尤其是当您的应用程序随着时间的推移而增长时，所需的需求可能会增加复杂性。因此，从一开始就设计出效率和可扩展性的最佳实践。
查询：作为报告和数据处理的支柱，您希望构建查询优化。使用[CapacityMonth]列，与表中已分隔Month列相比，查询涉及的脚本更少，可维护性更好，可读性更高，效率更高。
例如，比较可读性（回忆SQL语句读作声明性句子）：
SELECT [January] FROM Format2Table
SELECT [Percent] FROM Format1Table WHERE [CapacityMonth] = 'January'
此外，比较季度/年度总计的汇总查询：
SELECT Sum([January]) + Sum([February]) + ... + Sum([December]) As [YearTotal] GROUP BY [Year]
SELECT Sum([Percent]) As [YearTotal] GROUP BY [Year]。
最后，要检索列中每月总计的报告，第一种格式需要一个按查询分组，而第二种格式需要堆叠联合查询。还有其他例子。
TRANSFORM：不用担心，[CapacityMonth]方法的优点是您可以运行交叉表查询以按任意指定的顺序为只读表创建月份列，报告或电子表格导出。
TRANSFORM Sum(Percent) AS SumOfPercent
SELECT ContactID, ProjectID
FROM Format1Table
GROUP BY ContactID, ProjectID
PIVOT Capacity IN ('September', 'October', 'November', 'December', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August');