Forum Academy Marketplace Showcase Pricing Features

みなさんデータのjoinは使われていますか?

複数テーブル間のJOIN的なものについて質問です。

BubbleでJoinを調べると下記のような記事がヒットしますが、このような方法だと、結構強引というか、綺麗に作れない気がしていて、ノーコード開発をされてる方々が、このような方法を実際に利用しているのかを伺いたく。

背景としては、Slackのクローンを作っているのですが、下記のようなDB設計になっていて、例えば、ログインして特定のworkspaceを選んだ際に、チャンネル一覧をRGで出したいのですが、JOIN的なものが使えないと難しいのではないかと思っています。(RGのタイプをChannelにした場合は、「自分が含まれている」という絞り込みをするために、Channel MemberをJOINする必要があり、また、RGのタイプをChannel Memberにした場合は、「該当のworkspaceに一致」という絞りこみをするために、ChannelをJOINする必要があるなど)

Workspace
└ title(text)

Channel
└ workspace(Workspace)
└ title(text)

Message
└ channel(Channel)
└ contents(text)

Channel Member
└ channel(Channel)
└ user(User)
└ is_admin(yes/no)*管理者機能のために用意
└ unread_messages(List of Message)*既読機能のために用意

ChannelテーブルにList of Usersの型で参加メンバーをrelationとして持たせるだけなら、上記のような悩みは無用なのですが、管理者機能や、既読機能の実装に当たっては、Channel Memberのような関連テーブルが必要かと思っています。(Channelテーブルにmembersおよびadmin_members、Messageテーブルにunread_usersなどを持たせれば、このテーブルは不要かもですが、設計が汚くなり過ぎるなと思い)
まとめると、質問は下記2点です

  1. Bubble開発で上記参考記事のようなJOINはよく使うのでしょうか?それとも別の方法が使われているのでしょうか?(JOINせずに済むようにテーブルを非正規化しまくるなど)

  2. 私の上記のSlackクローンのケースの場合に、どのようにすれば良いかなど、アドバイスありますでしょうか?

Bubbleでパフォーマンスを上げるために、クエリを1階層(または2階層)程度までにおさめるため、非正規化を使用することがよくあります。
(Channel Memberテーブルに、channelのWorkspaceを追加するなど)
これにより
Do a search for Channel Member(以下の制約)から、 each Channel をリストで取り出すことができます。(1つのみなら:first item)
・Workspace = 選択Workspace
・user = Current User

絞り込み条件が複雑になるとjoinを使用する必要がある場面も出てきますが、パフォーマンスが落ちるため、多用は避けています。