Description Firestore vs RDBMS
特徴 Firebase Firestore (NoSQL) RDBMS
データ保管方法 - ドキュメントとコレクション形式で保存。
- テーブル形式で保存。
Create（作成） - スキーマレスなので新しいフィールドやデータ型を簡単に追加可能。
- 事前にスキーマを定義する必要があるため、変更にはデータベース全体の再設計が必要。
Read（読み取り） - リアルタイムクエリが得意。
- 高度な結合（JOIN）や集計クエリに対応可能。
Update（更新） - ドキュメント単位での更新が中心。
- 特定のフィールドのみを効率的に更新可能。
Delete（削除） - ドキュメント単位で削除可能。
- テーブル単位または特定の条件での削除が容易。
スケーラビリティ - 水平スケーラビリティに優れる（サーバーレス設計）。
- 垂直スケーラビリティが基本。
リアルタイム機能 - クライアント間でデータのリアルタイム同期が可能（リスナーで即時反映）。
- データのリアルタイム同期には専用の仕組みやカスタムAPIが必要。
オフライン対応 - オフライン時にも読み書きが可能。
- オフライン対応は手動での実装が必要。
セキュリティ - セキュリティルールで細かいアクセス制御が可能（ドキュメント単位）。
- ユーザー認証やアクセス制御はアプリケーションや外部システムに依存。
得意な分野 - チャット、コラボレーションツール、IoTアプリ。
- 金融データ、在庫管理、トランザクション処理など整合性が重要なシステム。
不得意な分野 - 複雑な結合や多対多関係の処理が苦手。
- 非構造化データや動的なデータスキーマには不向き。
コストモデル - サーバーレスで使った分だけ課金（リクエスト数やストレージ量）。
- サーバーの台数やスペックに応じた固定コストがかかる。
Reactions are currently unavailable
You can’t perform that action at this time.
Firestore vs RDBMS
- スキーマレスまたは動的スキーマを採用。
- JSONライクなデータ構造を使用。
- 明確に定義されたスキーマ（列と型）が必要。
- データの正規化を通じて重複を排除。
- データスキーマの変更が即座に反映される。
- 簡単な検索やフィルタリングは高速。
- クエリの構造に制限がある（複雑な結合や集計は不得意）。
- SQLを使用した複雑なデータ分析が得意。
- 部分更新も可能だが、柔軟性が劣る場合も。
- トランザクションでデータの整合性を保証。
- コレクション全体の削除には工夫が必要。
- 外部キー制約により、参照整合性が保証される。
- トラフィックに応じて自動スケーリング。
- スケーリングにはデータベースの分割や再設計が必要。
- 再接続時に自動的に同期される。
- リアルタイム性が求められるアプリ。
- データの正規化や高度な分析には不向き。