質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Firebase

Firebaseは、Googleが提供するBasSサービスの一つ。リアルタイム通知可能、並びにアクセス制御ができるオブジェクトデータベース機能を備えます。さらに認証機能、アプリケーションのログ解析機能などの利用も可能です。

Amazon RDS

Amazon RDSは、米アマゾン社が提供しているRDBMSサービス。クラウド上でのリレーショナルデータベースの構築および運用が可能です。MySQL/PostgreSQL/Oracle/SQL Serverのインストールを容易にすることができます。

Flutter

Flutterは、iOSとAndroidのアプリを同じコードで開発するためのフレームワークです。オープンソースで開発言語はDart。双方のプラットフォームにおける高度な実行パフォーマンスと開発効率を提供することを目的としています。

Node.js

Node.jsとはGoogleのV8 JavaScriptエンジンを使用しているサーバーサイドのイベント駆動型プログラムです。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

Q&A

1回答

3791閲覧

Firestoreを使って、"1対1"ではなく、"1対多(1 : N)"のslackの様なグループチャットシステムを作りたい。

iiurefwr

総合スコア13

Firebase

Firebaseは、Googleが提供するBasSサービスの一つ。リアルタイム通知可能、並びにアクセス制御ができるオブジェクトデータベース機能を備えます。さらに認証機能、アプリケーションのログ解析機能などの利用も可能です。

Amazon RDS

Amazon RDSは、米アマゾン社が提供しているRDBMSサービス。クラウド上でのリレーショナルデータベースの構築および運用が可能です。MySQL/PostgreSQL/Oracle/SQL Serverのインストールを容易にすることができます。

Flutter

Flutterは、iOSとAndroidのアプリを同じコードで開発するためのフレームワークです。オープンソースで開発言語はDart。双方のプラットフォームにおける高度な実行パフォーマンスと開発効率を提供することを目的としています。

Node.js

Node.jsとはGoogleのV8 JavaScriptエンジンを使用しているサーバーサイドのイベント駆動型プログラムです。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

0グッド

0クリップ

投稿2019/07/19 07:27

編集2022/01/12 10:55

Firestoreを使って、"1対1"ではなく、"1対多(1 : N)"のslackの様なグループチャットシステムを作ろうとしています。
ただ、firestoreのchatコレクションのdocumentの構造が

chatId: "チャットのId" message: "チャットの投稿テキスト" senderId: "投稿した人のID"

だとすると、
一テキストごとに、毎度毎度、ユーザーの変更する可能性のあるユーザーの名前やimageを取得するクエリーを投げなければならず、
負荷的に正しいチョイスなのか懸念しています。

Relationalなデーターベースだと、クエリーが強く、
データーベースをジョインすれば、一回のクエリーでチャットメッセージとそのユーザーの詳細情報も取ってこれると思うので、
GCPで言うと、cloud sqlの様な物を使って、グループチャットを作った方が良いのでしょうか。
SNSみたいなアプリを作ろうとした時に、ユーザーのフォローワーを取得する時にも同じことが言えるので、
firestoreの利用は、基本的に変更のなく、他のテーブルと関係性のないデータを扱うのがベストなのかもしれないと思い始めてきました。
フロントでJoinすることも考えられますが、大規模なシステムの場合を想定しているので、大丈夫そうか懸念です。

Slackの様に高速なグループチャットの機能を実現したいです。

DBにFirestoreかSQLのどちらを採用すべきかを中心にアドバイスよろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

私としてはRDBを使うのが無難と思います。

確かにfirestoreを使えばリアルタイム処理など簡単ですが、
その設計ノウハウはまだ枯れているとは言えず、人によってかなり変わるし正解がないという印象です。
趣味開発なら気軽に使えるんですが、業務のメインのデータベースとして使うのはまだ怖いというか。

下記の

MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比べてどんな利点や欠点がありますか?

80%以上のユースケースでは、いまだSQLにまさるものはないでしょう。

と同じ見解です。

RDBを主軸として部分的にNoSQLを使うというのは全然有りだと思います。

投稿2019/07/19 10:06

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

iiurefwr

2019/07/19 10:26

ご回答ありがとうございます。 グループチャットの様な機能を作る時、RDBと比べNoSqlはクエリーも数倍以上も多くなると言う見解も正しいでしょうか。
退会済みユーザー

退会済みユーザー

2019/07/19 10:31

設計によります。 非正規化すれば何度もクエリかけなくても良いはずです。
iiurefwr

2019/07/19 10:42

ご回答ありがとうございます。 例えば、 ``` { chatId: "チャットのId" message: "チャットの投稿テキスト" senderId: "投稿した人のID" } ``` を ``` { chatId: "チャットのId" message: "チャットの投稿テキスト" senderName: "投稿した人の名前" senderImage: "投稿した人の画像" } ``` の様な感じでしょうか。 ちなみにこれだと、変更に弱くなってしまうので、想定していない設計です。
退会済みユーザー

退会済みユーザー

2019/07/19 11:24

しかしNoSQLでは、積極的にしていくべきといわれる設計です。 NoSQLで正規化に拘ると、確かに何回もクエリ発行することになります。 正規化したいならRDBを選びましょう。
退会済みユーザー

退会済みユーザー

2019/07/21 10:49

その後どうなったのでしょうか?
iiurefwr

2019/07/21 11:36

ご回答ありがとうございます。 今firebaseでスマホアプリのグループチャットを作ろうとしていて、 その後調べると、DBにGCPのSpannerを採用できそうかもしれないと考えているのですが 如何思いますでしょうか。 SpannerはRDSとNosqlのいいとこ取りらしいですが、あまり"Spannerは素晴らしい"みたいな記事や、そもそもの技術記事が確認できなく使用するにあたって不安です。 AWSに全部差し替えて、Aurora使うとか、firebaseなので、GCP使って、cloud sqlを使う選択肢も考えておりますが、今のところまだ判断できていないです。。。 Joinできないと言うことは、基本的にSNSの様なアプリに向かないはずなのに、firestoreがもてはやされている理由がよくわからないです。。
退会済みユーザー

退会済みユーザー

2019/07/21 12:25

私はGCPのSpannerについては何も知識がないため回答できません。 繰り返しになりますがNoSQLが辛いならRDBを使いましょう。 > Joinできないと言うことは、基本的にSNSの様なアプリに向かないはず これも既に言っていますがNoSQLはJoinしない代わりに非正規化設計を行います。 正規化にこだわるならNoSQLを使うメリットはないのでRDBを使いましょう。
退会済みユーザー

退会済みユーザー

2019/07/21 12:26

向かないというわけではないです。 設計の考え方をガラっと変えないといけないということです。
iiurefwr

2019/07/22 07:20

ご回答ありがとうございます。 設計の仕方を変えて、正規化しない様にDBに突っ込んだとしても、 ユーザーの名前に変更があった際、そのユーザーが投稿したテキストと共に入っているユーザーの名前のdocument全て変更する必要があり、スケールすればするほど変更に弱くなるので、SNSに向かないと言う内容です。 上記の設計ではSNSに向かないと思いますは、他に方法があると言うことでしょうか。
退会済みユーザー

退会済みユーザー

2019/07/23 08:42 編集

ドキュメント志向DBを使うなら、正規化すべきではありません。 どうしても正規化するなら、クエリを何度も発行する必要がありパフォーマンスが低下するでしょう。 基本的に、非正規化が嫌であればRDBを使うべきです。 > document全て変更する必要があり その通りです。必要に応じて都度関連するデータすべてを追加・更新することになるでしょう。 それが非正規化設計というものです。 繰り返し言われる「変更に弱い」という意味がよくわかりませんが、重複したデータを持つのが嫌ならRDBを選択し正規化設計すれば良いだけです。 これ以上どのような回答を求めているのでしょうか。
退会済みユーザー

退会済みユーザー

2019/07/23 08:51

> DBにFirestoreかSQLのどちらを採用すべきかを中心にアドバイスよろしくお願いいたします。 これについての回答は行ったつもりです。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問