バージョン管理をサポートし、データの重複を減らすために、次の表構造を使用しました(一部の列を削除してスタブを作成しました)。記事のレビュープロセスを想像してみてください。各ステップはデータベース(article_meta)に保存されています。記事自体が変更されるたびに、データはDBにも格納されます。 バージョン管理は、先行者(pre_meta_id)への参照によって行われます。DB2:間接参照データの結合方法
WITH
t_article_meta (id, pre_meta_id, user_id, state) as (
values (1, NULL, 101, 'submitted')
union all values (2, 1, 7, 'inreview')
union all values (3, 2, 7, 'rejected')
union all values (4, 3, 101, 'submitted')
union all values (5, NULL, 202, 'submitted')
union all values (6, 5, 7, 'inreview')
union all values (7, 6, 7, 'accepted')
union all values (8, 4, 7, 'inreview')
union all values (9, 8, 7, 'accepted')
),
t_article (id, meta_id, content) as (
values (1, 1, 'Hello wordl')
union all values (2, 4, 'Hello world')
union all values (3, 5, 'Lorem ipsum doloret')
)
SELECT ...;
は、今私は(前任者を経由して間接的にのみ)は直接の言及がなくても何とかメタデータや商品データを組み合わせたビューを作成したいです。
id | pre_meta_id | user_id | state | content (left join) | content (I want to have)
---|-------------|---------|-----------|---------------------|-------------------------
1 | NULL | 101 | submitted | Hello wordl | Hello wordl
2 | 1 | 7 | inreview | NULL | Hello wordl
3 | 2 | 7 | rejected | NULL | Hello wordl
4 | 3 | 101 | submitted | Hello world | Hello world
5 | NULL | 202 | submitted | Lorem ipsum doloret | Lorem ipsum doloret
6 | 5 | 7 | inreview | NULL | Lorem ipsum doloret
7 | 6 | 7 | accepted | NULL | Lorem ipsum doloret
8 | 4 | 7 | inreview | NULL | Hello world
9 | 8 | 7 | accepted | NULL | Hello world
DB2のようなものを実現するにはどうしたらいいですか?私の最初のアイデア:機能に関する参加(記事に関連する先行者を取得する)は、本当に私にとっては高価なものです。このSQLは、仕事をするだろう
をそれは限り動作します。それはこのようになります - 私たちはすべてのお子様のためのタイトル/コンテンツを取得するために再帰クエリを定義するために持っているようにSQLが複雑になり、調整要件について
idとsuccessor_idのシーケンス(実際には先行者ID ...)は同期しています。この問題を示すために例を更新しました。 – Mrks83
@ MRKS83あなたの新しい要件を満たす調整済みのソリューションをチェックしてください – MichaelTiefenbacher