ベストプラクティス：データベースアプリのプログラミングパターン

私はこれまで多くのデータベース（MySQL）Webアプリを書いてきましたが、私の構造はちょっと不器用だといつも思っています。ここでいくつかのアドバイスを期待して、使用しているプログラミング/設計パターンを改善したいと思います。特に、データベース（スキーマ）の実装をカプセル化するOOPアプローチを補完する構造を見つけることができません。私

私の質問は例で最もよく説明できると思います。Invoiceオブジェクト/クラスがあると言う2つのアプローチがあります。

最初は静的メンバー関数を使用することです

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

2番目のアプローチは、すべてのものをデータベースオブジェクトに入れることです。

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

（SQL）メンバー関数はどちらの方法でも「ビュー」から非常に切り離せないことがわかります。「ビュー」はクラスに必要なものを決定するため、ドキュメント/ビューアーキテクチャを壊すようです。

また、たとえばSELECTステートメントは必要なものだけを選択する必要があるため、一種の非効率的と思われますが、Invoiceのメンバー変数の存在は「データの保証」を意味するようです。

質問を明確に説明したかどうかわからない、このアーキテクチャ/デザインパターン/ what-it-is-known-asへの他のベストアプローチは何ですか？

アドバイスをありがとう

さて、ORMを使用できると思います。

しかし、実際には、データベース設計はOOP原則に従うべきではなく、正規化などのデータベース設計原則に従うべきです。また、アプリケーションではなくデータベースで設計する必要があります。また、データ整合性ルールは、アプリケーションではなくデータベースレベルで適用する必要があります。

データベース設計の本をいくつか読んでから、選択したデータベースのパフォーマンスチューニングについて読むことをお勧めします。

データベースの実装をカプセル化するOOPアプローチを補完する構造が見つかりません

オブジェクトリレーショナルインピーダンスの不一致を説明しているようです。

このOODBMS、ORMツール、データアクセスツールのホストを解決することになっているものがいくつかあります。

たくさんの解決策があるという事実から、One True Solution™は存在しないと思うようになります。

そのため、一部の人はそれを嫌い、一部の人はそれを愛するという知識の中で、安全な方向を選ぶことができます。

ORMラッパーを使用したくない場合は、MongoDBなどのOOPスタイルのストレージをサポートするデータベースを使用してください。

MongoDBの（「HUからモンゴたち」）クロスプラットフォームでのドキュメント指向データベースシステム。「NoSQL」データベースとして分類されるMongoDBは、従来のテーブルベースのリレーショナルデータベース構造を避けて、ダイナミックスキーマ（MongoDBはBSON形式と呼びます）を含むJSONのようなドキュメントを優先し、特定のタイプのアプリケーションでのデータの統合をより簡単かつ迅速にします。 ..