我有一个关于如何设计季度和财政年度的自我辩论。
案件：
对于某些公司而言，本季度可能会有所不同，例如： 2011 第1季（Q1）：1 / 1-3 / 31 Q2：4 / 1-6 / 30 Q3：7 / 1-9 / 30 Q4：10 / 1-12 / 31
但2012年季度开始和结束可能会发生变化： Q1：1 / 1- 4/15 Q2： 4 / 16-7 / 15 Q3： 7 / 16-10 / 15 Q4： 10/16 -12/31
所以我提出了两个不同的解决方案，但我不知道哪个更好。
解决方案1：
FiscalYear（year，fromDate，q1ToDate，q2ToDate，q3ToDate，toDate，otherColumns）
在此解决方案中，将存储所有季度末，所有内容都在同一个表中。
解决方案2：
FiscalYear（year，otherColumns）
季度（financialYearId，fromDate，toDate，quarter）
FiscalYear和Quarter有1到4的关系。
思维：
我可以比较的是解决方案1 是好的，因为我们知道这些年将会有4个季度。所以设计实际上是标准化的。
然而，解决方案2 看起来更具扩展性。但是在检索数据时你必须做一些连接。
你们认为哪个更好？你的理由是什么？
------ ------编辑
环境：
数据库：MySQL
答案 0 :(得分：2)
多年前，当我们不得不处理这个问题时，我们想出了一个对我们有用的解决方案。我们建了一个表，让我们称它为Almanac，每个日期有一行。表示为日期的日期是此表的主键。
它有各个相关时间段的列，例如财政年度，财政季度甚至是财政月，这些都是年复一年的。它还有列表示工作日，周末，公司假期等。简而言之，公司日历的所有功能。
然后，我们编写了一个程序来填充此表，其中包含大约十年的数据。公司日历的所有奇怪逻辑都内置于这一个程序中。
稍后，当我们想要对其他事件（例如销售）或工作班次的结果进行分类时，我们所要做的就是在日期加入此表，并选择相关列。非常非常容易。
对报告数据库非常方便。您可以在几分钟内按财政季度或财政年度制定相同的报告。
答案 1 :(得分：1)
脱离我的头脑我喜欢解决方案2因为我认为总的来说，我能想象的各种查询会更容易。您可能会遇到一些交叉表变得很重要的情况，但这些情况让我很少见。
现在你没有提到哪个数据库，这些可能会提供更多选项。例如，在PostgreSQL中，您有远程类型，这将允许您做两件事：
现在，如果你在没有这种能力的数据库上，那么你的第一个模型的一个优点就是它确保没有重叠。您可以假设所有季度都是连续的，并且您可以省去开始日期（并根据前一行查看，也许使用窗口函数），在第二个模拟中进行模拟。