|
|
1
12
我将考虑(1)使用包含起始和结束时间的格式,以及一周中的整数字段。我知道您说过块将始终为一小时,但这可以由您的代码强制执行。此外,如果有一天您的需求发生了变化,那么在第(2)步中,您需要担心的问题将比将DB语句全部编写为假设1小时块时少很多。
对于(2),如果每条记录都有一个与之相关联的开始和结束时间,那么就很容易检查任何给定时间的窗口:
(在哪里
每周每一天的允许或不允许将由单独的记录处理。IMHO,对于一周中的每一天,这比硬编码更灵活,因为您将使用某种case语句或if-else切换来检查您感兴趣的那一天的正确DB列。 注: 确保您知道数据库在一周的整数日使用哪种标准,并尝试使代码独立于它(始终询问数据库)。我们在一周的开始(周日或周一)和开始指数(0或1)的不同标准中玩得很开心。 |
|
|
2
2
如果每周都不一样,那么就这样摆桌子;
如果设置了特定日期/小时的开始时间,则假定它是允许的,否则拒绝。 如果这是一个普通周的普通配置,没有改变,试试这个;
然后为每小时/天的组合添加行。 |
|
|
3
1
我以前确实使用过这种设计,基本上是为你想要定期安排的时间跨度除以你想要的周期数创建一个位图。因此,在您的示例中,您需要一个带有小时周期的周计划,因此您将有一个只有21字节长的168位位图。一对datetimes总共是16个字节,您需要多行这些数据来表示给定一周的可能日程安排,因此如果您关心大小,我认为您无法超越它。 我承认,与以前的建议相比,处理这个问题有点棘手,也没有那么灵活。考虑一下,如果你突然想要使用1/2个小时的时间段,你需要将所有现有的数据转换成新的336位位图并分发值。 如果您使用的是SQL,您可以将其存储为二进制日志,并进行位旋转以比较位是打开还是关闭,或者可以将每个位存储为列。MS SQL Server支持高达1024的标准表或30k的宽表,因此您可以轻松地将其中一个表的粒度降低到10分钟,或将30k表的粒度细化很多。 我希望这能为如何做到这一点增加一点不同的视角。只有当你担心空间/大小,或者你可能有10到100个百万的空间/大小时,才有必要这样做。 |
|
|
4
1
您可以轻松地在表中记录“允许”的时间。这样,如果它不在那里,它是不允许的。如果您需要一个更可变的“时间表”,您可以轻松地添加一个年和月字段。
2008年12月:
您有2008年12月所有可以执行维护的天数。你想怎么显示就怎么显示。 |
|
|
5
1
每一个建议的解决方案对我都是好的,无论如何,我会考虑这一个你应该面对性能和/或表大小的问题。由于您可能会在时间和您的实体(即服务器)之间建立关系,因此大小将增加实体数*实体数倍。如果你每次都要吵架,这可能会很痛苦。 该方案在表结构方面稍显丑陋,但在磁盘空间和表扫描速度方面效率更高。
考虑在星期日和星期一将16:00至20:00正常运行时间分配给服务器的示例,您将只有两行
您将假定每一行缺失都意味着服务器已关闭。 如果你需要这个,你可以考虑使用DATA列的日期格式来设置特定的日期(即16:00和20:00之间的正常时间只有2013/10 / 02)。 希望能有帮助 |
|
|
6
0
也许像
|
|
|
7
0
用Python编写,这样的模块可能会工作- https://github.com/AndrewPashkin/pytempo |
|
|
blogger13 · 视频租赁店数据库的规范化 1 年前 |
|
|
ì¤ì¤í · 为什么LEFT INNER JOIN被弃用? 1 年前 |
|
|
relatively_random · 确保两个表之间一致的共同参考 1 年前 |
|
|
Grenish Rai · Firestore错误“用户文档不存在” 2 年前 |
|
|
Saijo-Shi · PLpgsql中的更新触发器 2 年前 |
|
Dante · Django::配置不当:池不支持持久连接 2 年前 |
|
YouLocalRUser · 删除重复行,保留第一行 2 年前 |