设计具有以下级别功能的级别系统：无警告天数，该持续时间内的收入，订单响应率等级...每个级别都有其要求，但是如何设计其数据库模式和关系
public function level(){
return $this->hasOne(Level::class);
}
数据库表：
表格：
Level_table:
id,name
User_table:
id,level_id,user_rating
答案 0 :(得分：1)
您可以通过两种流行的方法来解决此问题。在提供许多指标（订单，等级，持续时间，收入）的同时，让我们将示例简化为“点”。
第一种情况是公式级别的系统，您的积分概念构成一个阈值，可以即时计算。例如，> 10分始终是“银色”。如果您有能力在系统中失去积分，则可以在此模型中躲在白银之下。
第二个是更以事件为中心的模型，在该模型中更改阈值可以更改您的级别，但是还原并不会降低您的级别。对于您的得分，这更像是“最佳赛季”得分。
我最初的想法是代码中的复杂性来自于级别的计算，而不是存储（因此不一定是模型中的存储）。
建模的方式很大程度上取决于取决于您的级别或分数的事物。一些探索性的问题是：
我的本能是将“状态”字段映射到您的主要实体或模型。例如，您的用户模型可能有一个level字段。然后可以由状态机（进行一些进一步的搜索）来处理您级别字段中的转换，该状态机会影响您所有的计算和评分算法。或者，您可以将其作为模型上的自定义访问器，并即时进行计算。
考虑到我的本能，我将简单地设置一个受保护的字段：
class User {
//...
protected $guarded = ['level'];
// ...
}
“级别”（作为API）之间的状态转换的一个很好的例子是查看Stripe的“帐单/发票”工作流。尽管这是一个非常不同的业务领域，但是它是一个简单的API，在工作流状态之间的转换中有很多 复杂性。您可以参考这些业务规则作为示例，以启发您如何构造自己的代码和数据结构。
最后，您可能想挂入Laravel的事件系统以触发“水平”事件，并确保这些水平之间的转换仅由一组代码处理（请避免在运行过程中即时计算水平）。一堆控制器-将它们整合到您的服务中。
哦，当您考虑架构时...您是否需要存储某人的关卡历史记录以及通过这些关卡“过渡”的原因？令人回味的食物= D