通常のデータベースレイアウトのデータアクセスパターン

Question

大きなデータベースが付属しているアプリケーションのメンテナンスを開始しましたが、これは部分的に正規化されていません。重複したデータがたくさんあり、テーブルには多くのフィールド（30+）があります。たとえば、多くのフィールドを含むOrdersというテーブルがあります。私はこのテーブルを分割して分割しますが、データベースレイアウトの変更は許可されていません。例えば、私がリポジトリパターンに固執すれば、OrderエンティティとそのためのCRUDメソッドを作成する必要があると思います。問題は、ビジネスロジックでOrder Entity全体がロード/更新されることはほとんどありませんが、サブセットのみが必要であることです。それは多くのエンティティ（FullOrder、OrderMetaInfo、OrderProcessingDetailsなど）を構成します。

私の質問は、このようなデータベース混乱に対処するにはどうすればよいでしょうか？私は、Ordersと呼ばれる単純なクラスを作成することを考えていました.POCOとして前述したエンティティと、UpdateOrderMetaInfo（）やGetOrderProcessingDetails（）などのメソッドを持つよりも、それは2つのテーブルがあり、1つはOrdersであり、もう1つはArchivedOrders（そして、いいえ、フィールドは同一ではありませんが、非常によく似ています。私は大量の重複したコードを実行しているようです。今、私は手作りのSQLクエリを渡し、レコードセットを取得する、本当にシンプルなデータベースアクセスクラスを書くことについて考えるようになりました。あなたはこれよりも良いアイデアを持っていますか？

事実と限界：これはSQLデータベースであり、プロジェクトはC＃で書かれています。同じデータベースを使用する別のシステムがあるので、データベースレイアウトを変更すると、ではなく、というオプションがあります。データアクセスにEFやその他のサードパーティ製品を使用すると、でなく、のオプションもあります。

ご迷惑をおかけして申し訳ありません。

Answer 1

実際にプロパティーセッターを使用して、更新する必要があるものを実際に「マーク」するだけではどうですか。例えば

、ユーザーが

Order.Client = "Jorge"; 
Order.Price = 300; 
Order.Provider = "Microsoft"; 

を行うことができ、あなたのセッターは

public string Client{ 
set 
{ 
    mClient = value; 
    ModifiedFields.Add("ClientField"); 
} 

のようになりますし、最終的にあなたのUpdateメソッドは、ModifiedFields情報に必要と実際のクエリに基づいて、決定します変更されたフィールドを更新するために実行されます。

実際にデータを取得するには、クエリがそれほど遅くない場合は一般的なGetOrder（）メソッドを使用するか、実際にパフォーマンスを低下させるほどの重さの場合は、各プロパティのゲッターで必要な情報を取得しますキャッシュポリシーを持つか、またはGetLastValueをプロパティに指定することによって、データの特定のサブセットを取得します。

例：

public class DBField<T> 
{ 
    private DBCommand getCommand; 

    public T Value {get;set;} 
    public T GetLastValue() 
    { 
    // Execute getCommand here 
    } 

    public DBField<T>(DBCommand GetCommand) 
    { 
    this.getCommand = GetCommand; 
    } 
} 

Iのユーザーが行います：私は仕事で似たような状況にいるよ

string Client = Orders["Id"].Client.GetLastValue(); 

Answer 2

。

私はそれを扱う方法は、既存のデータベースの混乱にビューだけで構成される新しいデータベースを作成することでした。私たちのアプリは、すべての荒れ果てた操作のためにビューを使用します。

Answer 3

これは他のすべての開発者が遭遇した問題のようですこのデータベースを変更しないの要件は吸うが、あなたはそれに固執する必要がある場合、私は、私は私が働いて非常に近いアプリでやったことのいくつかを共有することができます...私は、LINQ to SQLのを持っていたDAOオブジェクトを持っていましたDataContextの。私は、Orderエンティティが完全にロードする必要がないことに同意するが、我々はそれのまわりで得た方法がここで説明されているもののようにLINQ to SQLはいくつかのグッズを使用していた：

http://www.sidarok.com/web/blog/content/2008/05/02/10-tips-to-improve-your-linq-to-sql-application-performance.html

はに特別な注意を払いますデータ・ロード・オプションおよびコンパイルクエリ。

私はこれが最善の解決策ではなく、なんとかであることを伝えるために持っていて、非常に複雑なものではありませんLINQ to SQLはときれいあなたのコードを維持することができます...このことができます願っています。