おすすめ記事

おすすめ記事一覧

Bubble・データベースクエリに関する説明、タイプとタイプを結びつける

ノーコードでWebアプリ作成 ~Bubble編~|濱口 まさみつ|note

ごきげんよう。いかがお過ごしでしょうか。bubbleの操作には慣れてきたでしょうか。この記事ではノーコードツールbubbleのデータベースクエリに関する説明とタイプ(型)とタイプ(型)の結びつけ方についてご説明します。お気付きの方も多くおられるでしょうが、以前からtypeの訳語をタイプ(型)とあてて解説しています。bubbleのマニュアルは英語原文ですのでtypeに充てる最適な訳語を考えているのですが、今のところ一貫してタイプ(型)としています。ご理解ありがとうございます。それでは張り切ってLet’s Go!

データベースクエリに関する説明

このページでは、データベースクエリがどのように動作するかについての特別なポイントを説明します。これらはデータベースがどのように動作するかについての技術的な詳細を説明していて、アプリ内のクエリが期待通りに動作しない状況をデバッグするのに役立ちます。

“ストップワード “と呼ばれる特別な言葉があります。これらの単語は短く、一般的な単語である傾向があり、フレーズの文脈を除いては、データベースはこれらの単語を検索しても無視します。例としては、”the”、”I”、”do “などがあります。実際には、このことは、これらのストップワードのいずれかに対してクエリを行った場合や、いくつかのストップワードを含むクエリを行った場合には、結果が期待したものとは異なる可能性があることを意味します。

“ステミング “とは、データベースが検索クエリを一般化して、同じステムの他の単語を探すことです。例えば、 “test “と “testing “は同じステムを持っているので、”test “を検索すると “testing “という単語が検索結果に含まれます。  

ステム処理は、意味的に似た意味を持つ単語にマッチするので、”temp” と “temps” はマッチしますが、”temp” と “tempo” はマッチしません。同様に、”test” と “intestine” は一致しません。

ノーコードでウェブアプリが作成できる【Bubble】をご紹介! | セブテク

以上ここまでがデータベースクエリに関する説明でした。ここからはタイプとタイプの結びつけに関する説明です。後半も頑張っていきましょう。

タイプとタイプの結びつけ

“どのようにデータベースを構成すべきか “というのは、よくある質問であり、重要な質問です。幸いにも、bubbleデータベースは非常に柔軟性があり、正解がたくさんあります。この記事では、あるデータタイプと別のデータタイプを接続するための一般的なパターンをいくつか紹介します。特に、 あるモノが別のデータタイプの多くのモノに関連している可能性がある場合には注意が必要 です。

どんな時に使うの?

アプリのデータタブでデータタイプの新しいフィールドを定義するときに、それがテキスト、数値、YES/NO、または別のデータタイプであるかどうかを指定できます。また、そのフィールドにそのタイプの値を1つだけ持つか、そのタイプの値のリストを持つかを指定することもできます。

下に示すのは、フィールドが他のデータタイプの(単数)値である場合の例です。

・ブログ投稿データタイプには、ユーザーを示すクリエーター(作者、投稿者)フィールドがあります。

・イベントデータタイプには、建物を示す会場フィールドがあります。

・採用候補データタイプには、出身校を示す最終学歴フィールドがあります。

・コミュニティデータタイプには、州フィールドがあります。

下に示すのは、フィールドが別のデータタイプの値のリストである場合の例です。

・ブログ投稿データタイプには、タグのリストであるタグのフィールドがあります。

・プロジェクトデータタイプには、フォロワーのリストであるフォロワーのフィールドがあります。

・派遣アプリのコントラクターには、過去と現在の職歴のリストである職歴のフィールドがあります。

異なるオプション

ブログであるbubbleアプリを例に、投稿とタグのデータタイプで実行してみましょう。 個々の投稿は多くのタグを持つことができ、もちろん1つのタグは多くの投稿で使用することができます。 これをどのように設定するのでしょうか?

答えは「状況によって異なり、いくつかの答えが存在する」です – bubbleの他の領域と同様に、さまざまな方法でこれを構築する柔軟性を持っています。

ここでは、この関係を作成するために使用することができるさまざまな主要なオプションを紹介します。

オプション1:各投稿にタグのリストであるタグフィールドがあるとき

つまり、「ブログ記事#123」には「#料理」「#旅行」「#日々の楽しみ」というタグがあり、すべて投稿のタグフィールドに格納されている可能性があります。このアプローチの利点は、 何かを投稿し、それがどのタグを持っているかを調べたいときに、簡単に調べることができる ことです。例えば、投稿のデータタイプが割り当てられたページがあるとしましょう (それぞれの投稿が独自のページにあるとします) – タグを取得するには、現在のページのタグを取得する必要があり、これは簡単なクエリです。

このアプローチの欠点は、 先にタグを思いついて、そこからそのタグを持っている投稿を調べたい場合、クエリが少し堂々巡りになってしまうこと です。それぞれのタグが、そのタグを持つすべての投稿を一覧表示するページを持っているとしましょう。その投稿のリストを見つけるためには、「現在のページのタグが含まれているタグ」というフィルターを使って「投稿」を検索する必要があります。これはより遅いクエリです。

オプション2:各タグが、そのタグを持つ投稿の一覧をつくるとき

つまり、タグ「料理」には「ブログ記事#123」「ブログ記事#153」「ブログ記事#89」などのフィールドがあります。 (あるタグがついている記事をナンバリングして一覧化する、ということです。)  ここでの長所と短所は、上記のオプション1の逆です。特定のタグのすべての投稿を取得するクエリは簡単ですが、1つの投稿ですべてのタグを見つけるには少し長いクエリになります。

オプション1&オプション2:上記の両方を行うことができるとき

各投稿はどのタグを持っているかを記録し、各タグはどの投稿がそのタグを持っているかを記録します。 上記のオプションの両方を実行しても何も問題はありません!この方法では、与えられた投稿のすべてのタグを素早く取得することができます。この方法では、与えられた投稿のすべてのタグを素早く取得することができ、また、与えられたタグのすべての投稿を素早く取得することができます。 

ここでの欠点は、二重の作業をしなければならないことです。投稿に新しいタグが割り当てられるたびに、そのタグを投稿のタグリストに追加し、タグの投稿リストにも追加しなければなりません。余分な作業はそれほど多くありませんが、これを忘れてしまうとデータの整合性に問題が生じてしまいます

オプション3:投稿用のフィールドとタグ用のフィールドを持つ新しい投稿タグデータタイプ

これは、 各投稿 +タグのペアリングを処理するために新しい投稿タグを作成する ことを意味します。ですので、「ブログ記事#123″」+ 「料理 」のための1つの投稿タグ、「ブログ記事#123」 + 「旅行 」のための別の投稿タグ、および 「ブログ記事#123」+ 「日々の楽しみ 」のための別の投稿タグ、ということになります。bubbleのみならず、こうしたことに詳しい方は今紹介していることを「テーブルの追加」(joining table)として理解されているかもしれませんね。

これはオプション1とオプション2の間の「妥協」の解決策のようなものです。ある投稿のすべてのタグを見つけるためには、投稿 = 現在のページの投稿の場合はすべての投稿タグを検索するか、逆にタグのすべての投稿を見つける必要があります。これは、オプション1または2によって提供される高速な検索よりも、両方の方向での検索が少し遅くなります。また、別の小さな欠点は、あなたがオプション1または2でリストを使用していた場合、bubbleは自動的にリスト内のエントリをd-dupesするのに対し、それは重複した投稿エントリを作成することが可能である、ということです。

では、なぜこのオプションを選ぶのでしょうか?答えは、 その方がはるかに規模の拡大に対応できる形であるから です。データタイプが与えられたフィールドのリストを持っている場合、そのリストは最大で10,000エントリになります。これは多いように見えるかもしれませんが、例えば、一人のユーザーが一生のうちにどれだけのPinterestの投稿に心を奪われるかを想像してみてください!オプション1または2はその時点で壊れてしまいますが、オプション3なら問題ありません。

実際には、このような関係を作っていて、あるモノが別のモノの100以上の値のリストを持っていることを期待している場合は、オプション3で行うことをお勧めします。

要約すると、選択するオプションは、まずbubbleアプリに必要な規模(オプション1または2がオプションであるかどうかを決定するかもしれない)に依存し、次にクエリを超高速にしたいと考えている方向性に依存します。また、オプション1または2から始めて、後でオプション3に移行することもできます。

特別な例:フレンドシップが複雑な場合

多くのアプリでは、ユーザーが他のユーザーを友達にすることができるような「相互」関係を構築したいと思うかもしれません。一般的には同じオプションが適用されますが、すべてが同じデータタイプで行われるため、少し混乱してしまいます。この場合、オプション1+2の方が良いでしょう。オプション3では、設定を少し変更してみましょう。一方のユーザーに1つのフィールドを、もう一方のユーザーに2つ目のフィールドを設ける代わりに、ユーザーのリストである “フレンドシップメンバー “に1つのフィールドを設けても良いでしょう。(ソーシャルネットワークにはこのような関係が多いので、この場合はオプション3を試してみることをお勧めします)。

まとめ

この記事では、ノーコードツールbubbleでのデータベースクエリに関する説明とタイプ(型)とタイプ(型)の結びつけ方について解説しました。ステミングがうまく使いこなせるようになると、同じ言葉ベースの類似単語がお互いに引っかかり合うので、スマートな仕上がりにすることができますね。また、タグとフィールドを丁寧に操作することも大切ですね。ハッシュタグをつけて何かを投稿することが圧倒的に多いこの時代で、最も大切なパートの一つかもしれません。ではまた別の記事でお会いしましょう。See You!

 

 

 

 

 

 

 

 

Katsu

Katsu

高校まで日本で育ち、大学からアメリカ・ニューヨークへ。マスメディア、ジャーナリズム、インターネットメディア戦略を専門に修学。コロナ禍でオンライン主体になりつつある世の中で、記事が何かの手助けになれば幸いです。







関連記事

  1. Adalo Resource・フォームとトグル(スクリーンとコンポーネントセクション)について

  2. Adalo Resource・アプリ内課金のためのデジタル購入(スクリーンとコンポーネントセクション…

  3. 記事作成

    Bubble・API使用ケース&APIを使う

  4. Adalo Resource・FAQ一般的な質問

  5. 会社ロゴ

    .bubble

  6. 記事作成

    Bubbleの重要な原則とマルチページアプリについて解説!!

  7. 記事作成

    Bubble・オプションセット、エレメントカスタムステート

  8. 記事作成

    Bubble・スケジュール化されたワークフロー・再帰的なワークフロー

  9. 記事作成

    【2020年】NoCodeでスタートアップ構築!ツール14選!

人気記事

  1. topimage
  2. 記事画像
  3. 特集記事
  4. top_image

おすすめ記事一覧

  1. Productivity
  2. 勤怠管理
  3. タスク
  4. 飲食店 会計
  5. 記事画像
PAGE TOP