在laravel中通过venue与show的一对多关系管理同一地点的多场演出，venue存共享配置（json字段+array类型转换），show关联venue_id外键并级联删除，推荐用wherehas关联查询替代内存过滤，事务保证场地配置与场次缓存同步更新。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你在Laravel中需要为同一物理地点（如“杭州西湖剧场”）管理多场演出（如《雷雨》19:00场、《茶馆》20:30场），且这些场次共享场地配置、设备状态、排班规则和库存资源，必须避免重复定义、数据割裂与调度冲突。
用模型关系绑定场地与场次
创建 Venue 模型代表地点，Show 模型代表单场戏，两者建立一对多关系：Venue → hasMany(Show)。在迁移中为 shows 表添加 venue_id 外键，并加索引。
运行 php artisan make:model Venue -m 生成模型与迁移，编辑迁移文件，在 up() 方法中添加 $table->foreignId('venue_id')->constrained()->cascadeOnDelete(); 这一步不可省略，否则删除场地时残留场次会破坏业务完整性。
在 Venue 模型中定义 public function shows() { return $this->hasMany(Show::class); }，在 Show 模型中定义 public function venue() { return $this->belongsTo(Venue::class); }。
统一维护场地级配置项
将座位图、灯光参数、音响通道、后台动线等静态配置全部存入 venues 表，而非每场戏重复存储。添加 JSON 类型字段 config（如 config('seating_map', 'lighting_profiles', 'access_rules')）。
使用 Laravel 的 cast 功能，在 Venue 模型中声明 protected $casts = ['config' => 'array']; 这样读写 config 字段时自动序列化/反序列化，无需手动 json_encode/json_decode。
若某场地需临时启用红外导览系统，只需更新 Venue 实例的 config['infrared_enabled'] = true，所有关联场次即时生效，无需遍历修改每条 Show 记录。
按场地聚合查询与调度
方法一：获取某场地今日全部场次
Venue::with('shows')->find($venueId)->shows->where('date', today()); 这种写法会先查出整个 Venue 及其全部关联 Show，再内存过滤，【严重低效，数据量大时极易 OOM】。
方法二（推荐）：直接关联查询
Show::whereHas('venue', fn ($q) => $q->where('id', $venueId))->whereDate('starts_at', today())->get(); 数据库层完成筛选，只返回目标场次，性能可控。
方法三：封装为作用域
在 Show 模型中添加全局作用域 scopeForVenue($builder, $venueId) { return $builder->whereHas('venue', fn ($q) => $q->where('id', $venueId)); }，调用时直接 Show::forVenue($venueId)->today()->get()，语义清晰且复用性强。
场地维度的事务性操作
当调整某场地的总座位数并同步刷新所有关联场次的余票缓存时，必须保证原子性：
第一步：DB::transaction 开始事务；
第二步：更新 Venue::find($id)->update(['total_seats' => 800])；
第三步：批量更新所有关联 Show 记录的 cached_remaining_tickets 字段，使用 DB::table('shows')->where('venue_id', $id)->update([...])；
第四步：提交事务。任一环节失败，两处数据均不变更，避免出现“场地显示800座，但某场次余票缓存仍为750”的不一致状态。
