ORM（O/Rマッピング）で、”生クエリを書かずに各言語からデータベース操作する”ということを前提として考えた時に大事になってくる視点は、
「Projectに適したSQLをどのように選ぶか」というテーマで学んだことを書いていきます。
なお、各SQLがどのような特徴なのかは調べればすぐにわかることなので、この記事では「Projectの要件や目的に合ったものを選ぶ際の基礎知識」という視点で進めます。
視点①：パフォーマンス
データ量、トランザクション処理の能力、処理速度、キャッシュのメカニズム等、全体のバランスを考えて検討する必要がある。
一例として、データの種類（関係データか、非関係データか）を挙げてみる。
関係データベース（RDBMS）
構造化データ：予め定義されたスキーマに基づいて構造化されたデータを扱い、整合性と正確性が保証され、複雑なクエリや結合操作に適している。
トランザクションの整合性：ACID（原子性、一貫性、隔離性、持続性）特徴を強くサポートしていて、金融システムや予約システムのような厳密なデータの整合性を求められる場合に適している。
ただし、垂直スケーリング（サーバーの性能向上）には適しているが、水平スケーリング（サーバー数を増やすこと）には技術的に課題が残る。
非関係データベース（NoSQL）
非構造化：柔軟なスキーマを持ち、JSON、キーバリュー、グラフなど様々な形式をサポートし、データの多様性や変化に柔軟に対応できるため、Webアプリケーションや大きなデータの処理に適している。
スケーラビリティ：水平スケーリング（サーバー数を増やすこと）を前提に設計されていて、データ量が増えても効率的に処理が出来る。
また分散システムに最適化されていて、高い可用性とフォールトトレランスを実現する。
＊フォールトトレランス＝異常が発生しても予備に切り替えて正常化を図ること
一貫性のトレードオフ：分散システムは一貫性、可用性、分割耐性のうち２つしか同時に保証できないとされる（CAP定理）。
そのため、NoSQLでは一貫性を犠牲にして、可用性と分割耐性を優先されやすい（BASE特性）。
視点②：技術スタックとの互換性
Projectで使用している言語やフレームワークとの互換性があるかどうかを確認する。
この記事ではTypeScriptとLaravelの例で説明する。
例：TypeScript（Prisma ORM）
多くのSQLデータべースをサポートし、特にPostgreSQL、MySQL、SQLiteなどと相性が良い。スキーマ駆動のアプローチを採用し、Prismaスキーマ言語を通じてデータモデルを定義する。このツールは。型安全なデータベースアクセスを提供し、効率的なクエリ生成と実行が出来る。
他、TypeORM,Sequelize,Knes.js,Drizzle等
例：Laravel（Eloquent ORM）
フレームワーク機能の中核を担うEloquentは、統合が簡単なMySQL、固有の機能をサポートしているPostgreSQL、SQLiteやSQLserverとの連携が整っている。
理由は、統合のしやすさ、直観性、コードの一貫性と可読性、データベース間の移行の容易さなど、様々な観点から見て非常に相性が良いため。
＊これらORMの深堀りは別記事にて
視点③：セキュリティ機能
例えばPostgreSQLは、アクセス制限や通信データの強制暗号化、操作の詳細な記録と監査に対応しているなど、データ保護とセキュリティ監査に強い特徴がある。
＊個人情報漏洩は信用問題に関わる。絶対に起こしてはいけない。
視点④：コスト/スケーラビリティ
結論から言うと、「イニシャルコスト/ランニングコスト」と「将来的な拡張を考慮する」のはWeb開発におけるデータベースサーバー選びで最もネックな課題になる。
例えば、商用はライセンスが高く、オープンソースはエンタープライズサポートが必要な場合は費用が掛かる。
管理する側の人件費などのスケーリングする場合を考慮した上での判断が求められる。
まとめ
データベース設計は、
「アプリケーションがどれくらいのデータ量になるか」
「容量が増えた場合はどう移行するか」
等をしっかりと見積もった上で、
「日々の運用コストはどれくらいかかるか」
「将来的に拡張する場合はどれくらいの費用が掛かるか」
などの”お金に関わる問題”がかなりネックな部分になる。
実務未経験の学習では、AWSやSupabaseの無料枠を使えばいいと軽視されがちだが
実際の開発と運用においては年単位で相当額が消費されることもザラにあるという。
甘く見てはいけなかった。
