Question

首先，我是数据库设计的新手，因此对使用不正确的术语表示歉意。

对于大学作业，我的任务是为网站创建数据库架构。用户选择托管活动的可用性的网站的一部分，但事件可以是任何时间，例如来自12/12/2015 - 15/12/2015和16/01/2016 - 22/12/2016以及单个日期，例如05/01/2016。他们也可以随时选择活动

所以我不确定如何在不使用大量行的情况下将所有这些变量存储在数据库表中。下面的例子是一个基本的例子，它可以存储每个可用日期，但这是很多记录，只适用于一个事件。是否有更好的方法来存储这些值，或者将其存储在数据库之外的其他地方。

calendar_id | event_id | available_date
---------------------------------------
     492    |    602   | 12/12/2015
     493    |    602   | 13/12/2015
     494    |    602   | 14/12/2015
     495    |    602   | 15/12/2015
     496    |    602   | 05/01/2016
     497    |    602   | 16/01/2016
     498    |    602   | 17/01/2016

等...

Answer 1

这肯定需要一个数据库。我认为你不应该关心数据库中的记录数量......这就是数据库最擅长的。但是，从大学的角度来看，有一种叫做Normalization的东西。简单来说，规范化就是最大限度地减少数据重复。

设计架构的步骤

识别实体

作为设计数据库模式的第一步，我倾向于识别系统中的所有实体。查看您的示例，我看到（1）Events和（2）EventTimes（事件发生/预订）与一对多关系，因为一个Event可能有多个{{1 }}。我建议你将这两个实体分开放在数据库中。这样，EventTimes可以使用更多属性/字段进行扩展，而不会影响其Event。最重要的是，您可以在EventTimes上添加多个EventTimes，而无需重复所有事件的字段（如果您使用单个表格就是这种情况）。

识别属性

我的第二步是识别每个实体的所有属性/字段。另外，我总是建议在每个表中自动增加Event以唯一标识一行。

识别约束

这可能会更高级，但大多数情况下，您对可接受的数据值或在现实生活中唯一标识行的内容有约束。例如，id可能会标识数据库中的行，但您可能还需要每个事件都有唯一的Event.id

示例架构

这必须根据指配进行调整，或者在实际应用中根据系统的要求进行调整

活动表

id int auto-increment
title varchar unique：活动标题
always_on boolean / enum：如果'Y'则事件始终为
...此处有更多字段......（类别，标签，备注，说明，场地......）

EventTimes

id int auto-increment
指向title
start_datetime datetime或int（如果你使用unix时间戳，则为int）
end_datetime：如上所述
......更多领域......（下面的递归很难！如果可以，请避免使用）
recursion enum / int：事件是否重复？每周，蒙特利等
recursion_interval int：每x天，几个月，几年等

关于日期/时间的注释，根据经验，每当您处理数据库中的日期和时间时，始终以UTC格式存储它们。你可能不希望/需要在作业中弄乱时区......但要记住它。

示例的可能扩展

设计一个完整的系统可以添加表格：场地，组织者，地点等......这可以永远持续下去！我确实在设计时考虑了未来的要求，但是不要过度使用，因为你最终会遇到许多不使用的领域，并且会增加复杂性。

结论

规范化是设计数据库时必须记住的事项，但是您可以看到，规范化架构越多，Event.id和select越复杂。在数据效率和查询效率之间存在权衡......这就是我之前使用“从大学角度”的原因。在具有复杂数据结构的实际系统中（例如图形！），您可能需要对表进行不规范化，以使查询更有效/更快或更容易。还有其他方法可以处理这些问题（数据库中的函数，临时/临时表，视图等），但总是取决于具体情况。

要记住的另一个非常有用的事情是：要求总是改变！设计您的数据库时认为将添加/删除字段，将添加更多表，将出现新约束等，从而使其尽可能可扩展且易于修改...（现在我们正在抓一点“敏捷” “方法论”

我希望这会有所帮助，而不会让事情更加困惑。我不是DBA本身，但我设计了一些方案。以上所有内容均来自经验而非书籍，并且可能不是100％准确。绝对不是设计数据库的唯一方法......这是一项艺术工作：）

用于存储各种可用日期的表架构

1 个答案: