今回の記事について
本記事では噂のノーコード"Glide"について、調査したことをまとめます。
Glideについてはhttps://www.glideapps.com/ 参照のこと。
Glideは簡単にいうと、Googleスプレッドシートからプログラミングなしで非常に簡単にPWA（Progressive Web Apps）を作成できるノーコード環境です。
今回は前回からの続きで、GlideのData Editorの機能に焦点を当てていきます。
Archtecture編 Glideのアーキテクチャ
Data Editor編 DB・BEの代わりになるか？
Layout Component編 思い通りのUIをレイアウトできそうか？
Action編 思い通りのイベントリスナーを設定できそうか？
Plugin編 過去資産を生かした開発ができるか？
Security編 安全なWebAppを開発できるのか？
Data Editor
Data Editorとは
Official Material
Google Driveに置かれたGoogleスプレッドシートとは別にGlideでのデータの編集を行うインターフェースです。
ここでデータの編集が行えるだけでなく、ロジックの埋め込みや、データ構造定義ができるようになっています。
こちらで追加が可能なデータのデータタイプの一覧がこちら
Basic Column | テキストや数字、日付などGoogleスプレッドシートで追加できるデータタイプと等価のデータ。Basic Columnで編集した内容はGoogleスプレッドシートにも反映される |
Relation Column | 各Table間の紐づけを定義できる。Single RelationとMultiple Relationを定義できる |
Template Column | 別のColumnの値を代数に置き換え、それを取り込んだ文章を定義できる |
Single Value Column | すべての行を代表値ひとつで設定する。どの列の何番目のデータなどかを指定できる |
If->Then -> Else Column | Conditionに合わせて、参照するColumnを変更するようなロジックを定義できる |
Lookup Column | Relationを用いて接続した別のデータテーブルの中で、参照したいColumnを指定できる |
Array Column | 複数の同じデータ名＋数字 の列をCombineしてArrayのように表示させることができる |
Math Column | 別のColumnの値を用いた数式の定義ができる |
Rollup Column | その列全体の SumやAverage,Countなど、集計した値を定義できる |
Row ID Column | Row追加時にGlideが自動的に付与する各Rowに対するUniqueバリュー。主キーとして用いる |
Distance to Location | 位置情報から距離を算出する |
Joined List | 別Columnのデータを連結させた文章作りを定義できる |
Split Text Column | 別Columnのテキストを単語ごとに指定したデリミタで区切って配列化させる |
Generate Image | Image データを指定Columnの値をSeedとして生成する |
Construct URL | URLの生成ができる |
Experimental Code Column | Plugin編で説明。別のHostサーバー上（バックエンドサーバー）で加工したデータ結果をjsonで取得するためのI/F |
これらのデータタイプの詳細1個1個については, 公式のドキュメントをご参照ください。以下では各疑問に対して上記のColumnデータタイプをどのように使うと解決できるかを述べます。
データベースとして使える？
にてGlideは内部でFirebaseを使用していると述べたかと思います。
自分は全然知りませんでしたが、firestoreって非SQL型DBなんですね。Amazon Dynamo DBなどもそうで、メリット·デメリットについては別途調べていきたいと思います。
とりあえずココで言いたいのは、今までMysqlなどのRDBMS(Relational Data Base Management System)などを使って開発されていた方からすると、
“非SQLなので表示に合わせた正規化されてないデータを作ってスプレッドシートに置いとかなきゃいけない"
は結構きついはず。。。
それを解決するためにGlide ではData EditorでRelation機能などを提供し、スプレッドシート上には正規化されているデータを置けるようになっています。
Data Editorで提供している機能
Relation
https://docs.glideapps.com/all/reference/data-editor/computed-columns/relation-column
Lookup
まさにExcelのVLOOKUPです。
このRelationというのが各スプレッドシート、つまりデータテーブル間を繋ぎ、テーブル同士の親子関係を作ります。
例えば、ホテルの予約サイトで、部屋詳細一覧のテーブルと、予約一覧のテーブルがあったとします。
各部屋は複数の予約番号を持つことができ、各予約も複数の部屋番号を持つことが出来る多 対 多の関連を持ちます。
この時ある部屋についての詳細と予約一覧を画面表示したかったとします。
非SQL環境であれば
予約一覧から該当の部屋番号のついた予約をフィルタリングする
しかないのでしょうが、SQL環境であればトランザクションを減らすために
left join 関数を用いて結合させたテーブルから引っぱれるようにしておく
SELECT
部屋名前 部屋写真 部屋キャパシティ 予約時間
FROM 部屋詳細一覧
LEFT JOIN 予約一覧
ON 部屋一覧.部屋ID = 予約一覧.部屋IDのではないでしょうか。
Glide では部屋一覧テーブルにおいて、予約一覧テーブルへのRelationコラムを定義しておくことにより、left joinしたテーブルを予め準備しておくことが出来ます。
逆に予約一覧から、予約した部屋の詳細を表示したい。という場合はright join したテーブルが欲しいかと思うのですが、Glide でも予約一覧テーブルから部屋一覧テーブルへRelationを張って置くことでそれが可能です。
Relationの使いどころ
Relationはシートを跨ぐ場合だけではなく、シート内でも利用出来ます。これはデータの親子関係を定義するのに役立ちます。
例えば名前というカラムと上司の名前というカラムを作り、そこにRelationを作成しておくと上司の上司の上司といったような回帰的なカスケード構造のデータを2列で定義出来るので便利です。
例：下記の表から部下一覧画面などが作れます。
名前 | 上司の名前 | 部下（名前=上司の名前のRelationを設定） |
山田 | 伊藤 | |
鈴木 | 伊藤 | |
伊藤 | 加藤 | 山田 鈴木 |
加藤 | 田中 | 伊藤 |
LookUpの使いどころ
Lookupは、上記のようにRelationを通じて他のシートのどのデータ列を参照するか定義するものです。
先程のSQL文で selectで指定した部分ですね。
Join操作はサポートされるのか？
上述のようにGlide では left join, right joinは可能です。(最もGlide の場合、性能のためではなく、テーブル毎にTabを作るレイアウトのため、Tab間を超えたデータ定義が必要だから存在するのだと思われますが)
だいぶ調べましたが、inner join, outer joinみたいなことは出来ないです。それでも必要となった場合、、
Inner Join
非常に無理やりですが、Relationを用いてleft joinかright joinしたテーブルにこれまたGlideのComponentが持つフィルタを適用することでデータ取り出しが可能です。このフィルタはList/inline Listで設定ができます。ここでいったんleft/right join したデータからEmptyでない列のみを抜き出せば実現できます。
(例:inline ListのFILTER）
Outer join
こちらはGlideの機能だけでは実現できません。
ただGoogle スプレッドシートの機能を用いて似た感じにできます。
例えば、各予約プロバイダ (Hotels.com, 楽天トラベルなど）ごとに予約一覧シートが別になっていて、Appとしては集約されたテーブルが欲しいとなったとき、1つ集約用専用のシートAを作っておいて
= IMPORTRANGE('url名','シート名!B1:B12')
といったような数式を入れておきます。範囲は一致させたいキーのある範囲のみでOKです。
Glideで紹介しているIMPORTRANGEの機能
2つのシートを縦結合したい場合は
= {IMPORTRANGE('URL-A','シート名!A2:J);IMPORTRANGE('URL-B','シート名!A2:J)}
とし、;で繋げることで実現できます。この方法の良いところはそれぞれの予約一覧シートが成長して行が伸びていっても範囲指定をし直さなくて済むところです。
同様に2つのシートを横結合したい場合は
= {IMPORTRANGE('URL-A','シート名!A2:J),IMPORTRANGE('URL-B','シート名!A2:J)}
とし、,で繋げることで実現できます。
ただしこのままですと、重複しているリストがそのままですので、更に
= UNIQUE()
で上記の式を囲い、重複も取り除きます。この数式の場所ですが、このシートAをGlide に設定してAppに表示するのでGlide が自動的に番号を降るために上書きしてくるRow IDの列は避けたほうが無難です。
このuniqueは非正規テーブルから正規テーブルを作成する際にも役立ちます。
Glideで紹介しているUNIQUEの機能
最後にこのシートAをGlideのComponentから指定し、接続します。
コーディングなしに高度なQueryの作成は可能？
Data Editor には更に色々と機能があります。
If Then Else
Math
Rollup
Single Value
これらはコーディングをしない代わりにロジックを埋め込むために有効な機能となってきます。実際にRoom Reservationのtemplateでは予約一覧から空きを探す機能はコーディングではなく、Data Editorの機能だけで完結していました。
ユースケース
Userが部屋を使用したい日時を設定 → その日時に空いている部屋の一覧を表示
上記のため、ユーザーが選択した日時に対する予約日時の関係性を図に書いてみます。
まず、予約の開始日ー終了日、ユーザー洗濯の開始日ー終了日の関係性のパターンをすべて書き出し、図に上げたような5つのケースに対してどの関係が当てはまるかを書きだします。
If (Start|End) of Reservation is (before|after) (Start|End) of User Selection
みたいな形で書き出します。2 x 2 x 2のパターンですので8パターン書けます。
それを、図に書いたような5つのパターンにおいて、どれが当てはまるかを書いていきます。図を見てわかる通り、緑のReservation BとReservation Eであれば、ユーザーの選択日とバッティングしません。逆に一個でもオレンジ色のタイプの予約が入っていたらバッティングしてしまうので、この部屋を候補に挙げることはできなくなります。
ですので、これをもしコーディングするなら、こんなフローチャートになるのかな、、と思います。（もっとスマートなアルゴリズムはきっとありますが、ここでは気にしない）
条件分岐だらけですね。こんな条件分岐だらけのフローをGlideでも表現できるのでしょうか？
できます。
以下のようなかんじのIf Then Elseのコラムを設定できる機能があります。
If Then Else
右側の各条件を＆(and）で確認していくようなフローは以下のMath関数を使って積をとってしまえばできます。
Math
|| (or)で取りたいときは上記のMath関数で和をとればOKです。
一方左側のForループだらけのフローは、各予約毎にバッティングするかしないか判断済の結果を、最初に紹介したRelation機能を用いて、”バッティングしている予約をひとつも持たない部屋一覧”として抽出します。
"バッティングしている"を 0, "バッティングしていない”を1で表現します。
SQLで書くとこんな感じかと思います。
空きのある部屋一覧 =
SELECT
部屋ID
FROM 部屋詳細一覧
WHERE NOT EXIST (
SELECT 予約ID
FROM 予約一覧
WHERE バッティング結果(0 or 1)＋部屋ID = バッティング(0)＋部屋ID
) 上記のバッティング結果＋部屋IDの取得には、バッティング結果のカラムと部屋IDのカラムをJoinするようなJoinコラム、またはTemplateコラムが使えます。
その他にも、有用なカラムがこちら
Rollup
その列全体の平均値や合計値、要素数などを列に設定してくれます。複数のユーザーが付けたRatingの平均値を表示したいときなどはこれを一発呼べばOKです。
Single Value
ある別の列で指定した行の値を、列に設定してくれます。例えば検索条件の履歴一覧から、ある検索条件行を指定してすべての列に更新をかけたいときなどに使えます。
まとめ：データベースとして使える？
Data Editorを用いて色々とデータの持ち方を工夫することでSQLの機能に似たことはやれるようになっている。といった印象でした。
例えGlideが対応していなくてもGoogle スプレッドシートにExcel同様Query関数などが存在しているので、そちらで頑張れば何でもできてしまうのではないでしょうか？
またロジックを含むデータ抽出に関しても、コーディングは必要なくて、むしろ高速に動作しそうな感じがします。ただ、別の人が作ったロジックは目に見えにくい形でカラムに設定されているので読解が難しいかもしれません。