Relational Database と Firebase Realtime DB の違い

先日、Google の Firebase を知って、バックエンド部分の開発工数がだいぶ減ると思っていましたが、

Firebase のデータ構造(ツリー形式)な場合、「nosql」というくらいなので、「キー」とか「並び順」などは、どうやって設定するのだろう?と疑問に思いました。

↓以下のサイトでは、今までのRDB(リレーショナルデータベース)との違いが、わかりやすく書かれていました。

各モデルが相互で参照を持つ構造は、Firebase Realtime DBでのModel設計の定石です。 RDBの正規化の考え方からすると非常に冗長に見えるかもしれませんが、Firebaseでは、この割り切った考え方こそが重要になってきます。

そもそも、「Firebase Realtime DB 」を使用する場合、今までのRDBとは全く考え方を変えなければいけないようです。

クライアント側の環境をみると、デスクトップPC向けのサービスだったものが、モバイル・スマホ向けになってきているので、

今まで、表示スピード向上のため、多くのデータを取得しクライアントにもたせていたのが、

モバイル・スマホでは、表示領域のみ必要なデータを取得し、隠れているところでは「キー」だけ保持しておく。

この仕様に、Firebase のデータ構造 がマッチしているみたいです。

サービス開始時に、「Firebase Realtime DB 」を導入するなら、問題なさそうだけど、

既存のサービスを変更するとなると、かなり工数がかかりそうな気がします。

Firebase Realtime DBにはRDBのように複合的なクエリを実行できる仕様ではないため、もし既存のシステムがクエリを実行することによって成り立っているのであれば、根本的にFirebaseの導入を見直した方がいいでしょう。

という話もありました。