寻找以下场景中的最佳策略。
考虑 Rails 4 在线商店应用程序,其模型订单具有状态
class Order
enum status: [ :placed, :processed, :shipped ]
end
我们将应用程序发送给客户,一个月后他们回复我们说想要再添加一个状态 - 缺货。我们进去更新代码/测试/并部署。
class Order
enum status: [ :placed, :processed, :shipped, :backordered ]
end
几个月后,他们再次回来并想要另一种状态 - :work_in_progress 。等等
过去,我们通过聚合模型 - 状态 - 来避免这个问题,这将是一个 STI 模型并包含诸如此类的内容
OrderStatus < Status
和
CustomerStatus < Status
这使得客户添加状态或更改状态名称变得微不足道,但它会导致 SQL 查找速度变慢并且连接变得繁琐,尤其是在复杂查询上。
所以我想知道是否有一个好的策略来处理这个问题?现在我们有两者的组合 - 在模型上我们认为客户不想添加/删除状态 - 我们将其保留为枚举,否则我们确实属于某种状态/类别模型。
最佳答案
a month later they come back to us saying the want to add one more status
更改一行代码,即使每月发生一次,也不应该是一种痛苦的经历。您已经有了最佳策略:当客户要求更改时,咬紧牙关,添加新值(value),进行测试和部署。如果这太繁重,我会说问题在于部署过程而不是客户。
经过几轮之后,客户将用完新的值来添加并转向其他烦人的请求。
关于ruby-on-rails - 最终用户更新 Rails ActiveRecord 模型中的枚举,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26186695/