我有两张桌子:
CREATE TABLE store_category (
store_id int NOT NULL PRIMARY KEY,
category_id char NOT NULL
)
CREATE TABLE category (
category_id char NOT NULL PRIMARY KEY,
parent_id char NULL,
name char NOT NULL
)
store_id | category_id |
---|---|
1 | 1a |
2 | 2b |
3 | 3c |
category
表:该表有 3 个级别的类别。最高级别的类别在 NULL
中有 parent_id
:
category_id | parent_id | 名称 |
---|---|---|
1a | NULL | a |
2b | 1a | b |
3c | 2b | c |
我想获取商店类别的所有相关类别名称。
预期查询结果:
store_id | category_id | lv1 | lv2 | lv3 |
---|---|---|---|---|
1 | 1a | a | b | c |
2 | 2b | a | b | c |
3 | 3c | a | b | c |
我有个想法,我将category_id
表中与每个category
相关的所有类别名称都放入临时表中,然后将临时表与store_category
表连接起来。我想知道这是否是个好主意。
答案 0 :(得分:0)
我有一个想法,我将与类别表中的每个 category_id
相关的所有类别名称放入临时表,然后将 join
临时表与 store_category
表。我想知道这是否是个好主意。
它是一个好主意 - 除非您不需要临时表 - 也不需要循环。您只需要一个递归(自引用)CTE。 CTE 是您选择数据层次结构和其他图形结构的方式。
不过,我认为将您的数据PIVOT
(或更具体地说,UNPIVOT
)放入lv1
、lv2
和{{1 }} 列 - 我知道您的业务规则说只有 3 个深度级别,但是您的数据模型确实允许超过 3 个深度级别(除非您有 lv3
使用相同样式的 CTE 查询来限制最大 CHECK CONSTRAINT
的 UDF
)。如果您的数据维度随查询而变化(就像这个!),那么您应该将它们作为行返回,然后将它们格式化以在您的应用程序代码中显示给最终用户,而不是直接在 SQL 中显示。
至于分层查询:阅读:CTE Recursion to get tree hierarchy
像这样:
depth