m****a
发帖数: 1 | 1 【 以下文字转载自 Joke 讨论区 】
发信人: mababa (能做996是一种巨大的福气), 信区: Joke
标 题: 借人气问个SQL问题
发信站: BBS 未名空间站 (Sat Mar 5 17:45:19 2022, 美东)
最近我需要实现一个功能来做大量SQL数据更新，鉴于本人的SQL知识非常有限，借宝地
问问有没有高手能指点一下。这个功能大体要实现的功能是这样的，数据库里有两组数
据具有相关性, 分别存在两个table里，一个叫parent, 一个叫child。child里的每个
row有若干个attribute,而parent里的每个row则有个filter。这个filter用来判断一个
child row和这个parent row是否有相关性。如果是的话，就会在第三张表，parent-
child-relationship里面插入一条row来标记这两个记录是相关的。
由于每个parent row的filter可以改变，那么当filter发生变动时，需要重新计算并更
新parent-child-relationship中这个parent row所有相关的 row。
目前的算法是，先在parent-child-relationship table中找到和这个parent row相关
的现有row的集合, 然后根据新的filter算出新的集合，之后找出旧集合中那些row不再
需要。接下来把不再需要的那些row 删掉，然后对新集合里所有row做upsert。
功能上来说，这样实现没有问题，但是从性能的角度考虑，这种实现是不是最优的？比
如说，可以把旧集合全部删掉，然后插入新集合，理论上来说，这样实现性能更好还是
更差？
如有大拿能指点一下，鄙人不胜感激。 |
y****w
发帖数: 3747 | 2 你最好把数据量的具体量级说具体些，拿点典型数据，这样看着清楚些。你的
relationship这个表看起来只是个视图，有没有必要弄成实体表跟你的打算怎么用这个
数据有关系。如果频率强度不高，一个view，考虑啥更新删除merge。 |
m****a
发帖数: 1 | 3 目前是billion数量级，慢慢会涨到tens of billions。用view需要join,性能应该会差
不少。
【在 y****w 的大作中提到】
: 你最好把数据量的具体量级说具体些，拿点典型数据，这样看着清楚些。你的
: relationship这个表看起来只是个视图，有没有必要弄成实体表跟你的打算怎么用这个
: 数据有关系。如果频率强度不高，一个view，考虑啥更新删除merge。
|
n****f
发帖数: 905 | 4
这种数据库的设计方式， 是值得商榷的。我个人认为， 应该从开始就应该考虑一种可
以持续发展的合理设计。
当然， 如果不能从新设计， Oracle， 有一种特殊的 materialized view 不知道中文
叫什么。
当主表更新的时候， 这个 materialized view 会自动更新。
【在 m****a 的大作中提到】
: 目前是billion数量级，慢慢会涨到tens of billions。用view需要join,性能应该会差
: 不少。
|
n****f
发帖数: 905 | 5
这个相关的实时更新的具体落实方式， 需要考虑从新设计。
否则， 随着数据量的逐渐增大， 会导致更新速度逐渐增加， 以至于无法持续下去。
【在 n****f 的大作中提到】
:
: 这种数据库的设计方式， 是值得商榷的。我个人认为， 应该从开始就应该考虑一种可
: 以持续发展的合理设计。
: 当然， 如果不能从新设计， Oracle， 有一种特殊的 materialized view 不知道中文
: 叫什么。
: 当主表更新的时候， 这个 materialized view 会自动更新。
|
