整场被占与另一半仍可订，Skedda怎样描述重叠空间

同一片运动空间同时有整场和半场名称，是否就意味着这些名称全部互相排斥？Skedda的Space Sharing帮助页给出更具体的例子：篮球整场可以分成两个羽毛球半场，当半场一被预约，整场在同一时间不能预约，但半场二仍可以预约。这里的关系来自空间重叠，而不是所有名称被合并为一个资源。

页面先将Space Sharing用于物理重叠或冲突的空间，并说关联是双向的。若空间一的预约使空间二不能预约，空间二被预约也会阻止空间一。两个方向共同表达同一冲突关系，不能只摘取其中一个方向，便声称另一项预约不受影响。本文描述的是原厂软件语义，没有创建预约或测试账号。

半场例子说明双向并不等于任意两个成员都互相排斥。半场一与整场重叠，半场二也与整场重叠；但文档仍明确说，半场一预约时，半场二保留可订状态。因此，整场和各半场的关系需要逐项读，不能从它们都属于同一大场地，就推出所有组合拥有相同结果。

组合场馆例子使用了类似思路。页面列出一个较大礼堂、几个较小大厅与会议室，它们可分别预约，也有代表整个场馆的预约对象。单个空间同整体场馆关联后，单项被订会使整体不可订，整体被订也会影响所关联单项。这段描述同时保留整体与部分，重点不是给整体再取一个名字，而是避免同一物理范围在同一时间被重复作为不同对象提供。

还有一个必须单列的例外。原文说，Unavailable类型预约只有System users可以创建，并会有意忽略这些依赖，让个别空间可以不受依赖关系影响而被置为不可用。这不是普通预约都可以绕过规则的说明；类型与创建者条件要同例外一起保留。本文不提供创建或更改这类记录的方法。

问答再次明确，页面所述规则目前只支持双向，不支持单向依赖。这个问答与前面的定义相呼应，却不能被扩展成所有场馆软件的通用能力。读者理解整场与半场例子时，也需要把产品文档的范围留下来，不能把软件所表达的可订关系当成现实场地容量或合同权益的判断。

这份资料关注同一物理空间怎样以不同预约对象出现，并怎样限制重叠。它与预约前后缓冲、未来可提前多少天或旧记录保留多久，处理的是不同问题。页面显示二〇二五年三月四日，首次发布未知。本文采用连续文字，未看图或配置系统，不采纳定价、社交距离或场地安全方案，也不保证任何实际场馆当前的空位。