gpt4 book ai didi

mysql - 避免在 SQL 语言中对数据做出与在域中相同的断言

转载 作者:行者123 更新时间:2023-11-29 18:13:57 25 4
gpt4 key购买 nike

想象一下 Purchasable 类scala 中看起来像这样

case class Purchasable(product: ProductData,store: StoreData,seller: UserData){
require {
//seller is active &&
//seller has defined personal info &&
//seller has defined means of accepting payment
//product contains a price in seller's current currency
//product has defined shipping policies for atleast on of the store's locations
//product is not past expiration date
//product is either new or has uploaded images
//and so on!
}
}

object Purchasable {
def validate(p: ProductData,s: StoreData,u: UserData): Either[String,Purchasable] = {
Try(Purchasable(p,s,u)).toOption.toRight("unpurchasable.product")
}
}

类型 ProductDataStoreDataUserData 所有代表来自 3 个数据库表的行。

当买家想要购买产品或将其添加到购物车时,必须可以从这三个提取的行中获取成功的 Purchasable 实例。

但自然地,在买家将此商品添加到购物车之前,她必须首先查询我们的数据库以获取可购买产品的列表。

很明显,查询这些可购买商品会在 SQL 中产生非常复杂的条件子句(这不是我主要关心的问题)。我主要关心的是必须用两种完全不同的语言编写的重复逻辑所以我想做的是创建另一个名为purchasables的表,它保存所有通过的产品ID可购买标准;我从 db 流式传输三行,使用 scala 中的 Purchasable.validate 验证它们,并将它们插入到新表中。所以现在我有两个好处:

  • 我的查询变得简单如下:
select * from products p 
join stores s on p.storeId = s.id
join users u on s.userId = u.id
join purchasables pur on pur.productId = p.id
  • 没有重复的逻辑和可维护性问题。如果业务需求发生变化,我只需要更改代码中的一处即可。

我看到的缺点是,我的可购买产品现在具有所谓的最终一致性,而不是立即一致性。因为 purchasables 表仅定期刷新,即使每 2 分钟刷新一次。

我的问题:我在这里所做的事情是惯例吗?我在互联网上搜索了它,所有有关最终一致性的讨论和技术都是针对分布式系统问题的。我还没有找到任何关于讨论该选择的文章或 stackoverflow 问题。在这样的情况下,我感觉自己完全偏离了轨道,对自己在做什么一无所知。

最佳答案

我可能错过了一些东西,但我认为你的第一种方法更简单并且步入正轨。

你说你需要用两种语言复制逻辑,但我不明白为什么会这样。

据我了解,验证产品是否可购买和查找所有可购买的产品实际上是同一件事。它在此源表中查找所有可购买商品,源表可能小到单个元素表,也可能大到整个项目表。因此,您应该为其提供一个函数,并且相同的代码将处理这两个用例。

例如,如果你使用 slick,你可能会有这样的功能

def findPurchasablesIn(table: Query[ProductTable, ProductRow, Seq])

并使用不同的源表调用它?

关于mysql - 避免在 SQL 语言中对数据做出与在域中相同的断言,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47178957/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com