Java RDBMSデータベースバックエンドを使用して）でAPI開発を行うのに適したアーキテクチャはどれですか？
この質問は、任意のRDBMSデータベースバックエンドを使用してJava）でAPI開発を行うためのより良いアーキテクチャに関するものです。
現在、以下のアプローチを使用してデータベースからデータをフェッチし、クライアントに渡します。
ここでは、残りのコントローラー（Spring Boot/Java EEなど）にリクエストが送信されると、データベースカーソルを返すデータベースプロシージャコールが行われます。このカーソルを使用して、データは行ごとおよび列ごとに解析され（例：Spring RowMapper/JDBC）、POJOのリストになります。その後、JSON API（Jackson/GSONなど）がこれらのPOJOをJSON応答メッセージにシリアル化し、Restコントローラーを介してクライアントに渡されます。
このアプローチにはいくつかの欠点があることに気づきました
- 大きな結果セットのパフォーマンスの問題
- ガベージコレクタをビジー状態に保つ、ヒープ内の多数のオブジェクト（POJOが多すぎる）
- 開発時間が遅い（すべての結果セットに対してPOJOを作成する）
ここで、アプリケーションのパフォーマンスを向上させ、ガベージコレクションを削減し、開発時間を最適化する新しいアプローチを考え出しました。このアプローチでは、リクエストが行われると、データベースプロシージャコールが行われ、データベース内のJSON API機能（Oracle/SQL Server JSON APIなど）を使用してJSON応答が返されます。このJSON応答はVARCHAR/CLOBとして返され、Java Restコントローラーを使用してクライアントに返されます。
これは、次の利点があるため、従来の実装方法と比較してより効果的で生産的であることがわかっています。
- SQLコマンドを使用してデータをフェッチするとJSONが生成されるため、パフォーマンスが向上します
- シリアル化はデータベースで行われるため、ガベージコレクションのオーバーヘッドが少なくなります。
- 開発者がSQLを手動でコーディングすることを心配するだけでよい高速開発（少なくとも私たちのチームでは）
中間層で行うのではなく、データベースレベルでデータをJSONにシリアル化する方が良いかどうか、誰かにアドバイスできますか？どちらが優れたアーキテクチャですか？
あなたの方法にはいくつかの欠点があります。
データベースクライアントから返されたネイティブデータセットをシリアル化するだけで、POJOを回避できます。
通常、データ構造はデータベースのテーブル構造と正確に一致しません。例：テーブルの結合
データベースサーバーは、以前にアプリケーションレイヤーで行った作業を実行しています。これは拡張性が低くなります
ビジネスロジックは適用できません
一部のクライアントはXMLを好むかもしれません
タイプインジケーター、HATEOSリンク、バージョン管理など、DBで処理するのが難しい特定のシリアル化要件がある場合があります。
Jsonがオブジェクトにデシリアライズできることをコンパイル時間チェック
そのため、APIを介してCRUD DBオペレーションを実行しているだけの場合、高速になる可能性がありますが、大規模ではパフォーマンスが低下し、柔軟性が低下します。
一般的なケースでは、データレイヤーを分離しようとする必要があります。
特定のケースでは、多分あなたのみにデータレイヤーがあり、API経由でクエリを送信するように強制されているだけです。
しかし、私は長期的には、分離されたソリューションを使用する方がよいと考えています。
また。 POJOの作成/ガベージコレクションが実際に実際にパフォーマンスの問題であるかどうかを質問します。測定しましたか？