###・前提条件 ・発生している問題・エラーメッセージ ・実装したい機能
ノーコードラボさんの記事など、twitterなどのデータベース設計において、
user テーブルに、tweetリストを保持する必要はないのでしょうか？
自分がツイートしたリストを表示する時に、「tweetのuserfieldが自分である」という条件でdo search forをかけると思うのですが、tweettableのデータが膨大になったときに、検索コストがかかってしまうということはないのでしょうか？
良い着眼点ですね！Bubbleも通常のソフトウェア開発と同じく、データベース設計を間違えるとパフォーマンス的に物凄く遅くなる可能性はあります。
ご指摘の通り「userIdとtweetIdを保持するTimeline(ツイート表示用)」のテーブルを1つ追加する必要があると自分も考えてます。以下は2010~2年頃のTwitterのデータベース設計の説明記事です。(実際にTwitterが使っていたとされています。)
ただ一点注目したいのが、データベース設計の他に、良くあるRDSではなく「NoSQL + キャッシュ」が使われていた、というところです。
Bubbleがどのようなシステム構造になっているのかは分かりませんが以下の記事が少し参考になるかもしれません。
要点をかいつまむと、
- DBの最適化を常日頃から行なっている
- 重めのクエリが何度か来た場合はキャッシュを行う
- 1つのレコードで大きなデータが保存され呼び出す場合、それがボトルネックとなる
テーブル内の件数よりも、テーブルのキーに保存されるデータ量に影響を受ける、と読み取れます。なので、先に述べたTimeline用のテーブルを追加で作るだけで十分と自分は考えています。
ただ、実際に大きなデータ量をBubbleで取り扱ったことがないので「理論的」な回答なので、どなたか「実践的」な数値、回答を補足いただけますと助かります。
「いいね！」 5
ちょうど今Twitterクローンを制作しているところです。
個人的には、UserテーブルにList of Tweetsを持たせる必要はないと感じています。
Do a search forで検索をかけるだけで、問題ないかと。
もし表示件数が膨大になるなら、Repeating Groupの表示件数を絞ったり、
「Show all items immediately」のチェックを外したり、
「もっと読み込む」ボタンを配置するなど、色々と対処の方法はありそうです。
また、Timelineテーブルも用意しなくていいかなぁーと。
Userテーブルの中に、フォローしているユーザーをList of Usersで持たせて、
Tweetテーブルの中からCreator is in Current user’s followingで検索をかければ、
フォローしているユーザーのみのツイートが表示されます。
ただこの方法だと、Sign the user upの時点で自分自身をフォローしておく必要があります。
そして、フォロー数の表示などの時には、minus itemでCurrent Userを引く。
Timelineテーブルを用意すると、フォロー / フォロー解除の際に、
毎回Timelineテーブルからそのユーザーのツイートを
リストで足したり引いたりする必要が出てくるので、
少し動作が重くなりそうな気がします。
（このあたりの処理はBackend workflowへ回せば解決できそうですが）
@amezousan いかがでしょう
「いいね！」 4
お二方とも、とても詳しいご回答くださり感謝です。とてつもなく勉強になってます。
かなり奥が深いということがわかり、今の自分の実力だと、bubbleのサーバー側でのdo search forのクエリパワーに期待して、実装していくのが妥当なのではないかと思いました。
また、do search forのパフォーマンスに支障がでてしまうくらいまでユーザーが増えてきたサービスなのであれば、マネタイズも可能ということから、徐々にyesコードプログラマーを巻き込んだサービスにシフトしていく可能性が高いとも感じた次第です。(し、実際twitterもフォローしている人の全ツイートを見せているというわけではなく最近は島分けを行なっている)
しかし、いずれにしてもTimelineテーブルを作るという程度の労力でそれが回避できるのであれば、勉強して実行するに越したことはない、という認識です。
「いいね！」 2
そう言われると、Bubble独自のやり方に合わせたやり方が１番運用しやすそうですね！
仮にTwitter並みのデータ量とトラフィックがあったとして、Bubbleがどのようなパフォーマンスを出してくれるのかは分かりませんが、少なくともその時点で通常のソフトウェア開発に移行すべきなのかな、と。
あくまでノーコードはビジネスアイディアをいかに効率よく早く実現させるか、なので、表示件数を絞ったり対応できるのであればあきさんの設計の方が管理もしやすそうです 
「いいね！」 5
なるほどですです。ノーコードをどのように捉えて学んでいくべきかという部分も含めて学びにつながっております！ありがとうございます。