我需要创建一个表来存储每个人在每个任务上每周工作的小时数。该表将是这样的：数据库设计;如何有效存储星期？
[TaskID] [User] [Week 1] [Week 2] ....... [Week 52] [Year]
所以我的问题是，我会碰上这样的数据库设计性能问题？我总是可以找到正确的参考。例如第2周= 2011年1月3日 - 2011年1月9日。
闰年的最佳处理方法是什么？像2011年12月26日 - 2012年1月1日。我想我可以考虑这仍然是2011年的最后一周。
任何意见/建议将不胜感激。
谢谢！
这是非常规格化的数据，不推荐。数据意味着增长减少而不是输出。这样的事情将是可取的：
create table YourWeeks
(
TaskID int identity(1, 1) not null,
User varchar(100) not null,
Week varchar(100) not null,
WeekEnum int not null,
Year int not null,
constraint ck_weeknum check (WeekEnum between 1 and 52)
)
go
，并处理闰年，你可以得到花哨的外键引用，就像这样：
create table Years
(
Year int not null,
IsLeapYear bit not null
)
go
alter table YourWeeks
add constraint fk_weeks foreign key (Year) references Years (Year)
go
你甚至可以使用'TaskId' -UserId'''Date'''NumberOfHours'结构化表格，然后创建一个按周累计时间的视图。 – slugster 2011-12-18 04:43:29
@slugster同意，有很多方法来处理这种设计，这也是一个很好的方法。 – 2011-12-18 04:44:23
“非常规格化的数据” - 注意说明你认为它是哪种正常形式，为什么？提示：您可能误解了[在1NF的情况下重复的组是真的意味着什么]（http://www.simple-talk.com/content/print.aspx?article=712）。 – onedaywhen 2011-12-19 11:09:50
使用你在你的问题中常用的格式，我将设立以下三个规范化表：
[id] [name]
[id] [description]
[id] [task_id] [user_id] [year] [week_no] [hours]
是的，你会遇到性能问题有这样的设计。您将拥有许多完全无用且空白的许多字段，但每次您想要执行查询时都必须进行扫描。
你会好起来有这样的结构：
TaskID
User
WeekNumber
Year
Hours
至于你的其他问题......“闰年”无关，与你提到的日期。但我们不一定能回答如何处理这些问题。这更像是一种商业规则 - 企业认为这是第一周的开始？
那里有趣的链接，谢谢你。 – Melikoth 2012-06-13 01:12:37
我不明白你的插图。如果这些表示列名称，那么这是一个糟糕的数据库设计。 – jamieb 2011-12-18 04:36:10