オブジェクト指向の思想でデータベースを設計する

1896 ワード

データ構造プログラミング仕事をするスクリプト OO

開発者にとって、データ構造の変化によって、プログラムの修正は頭を悩ませているに違いない.特に、頻繁な修正は今日フィールドを追加します.明日はフィールドを追加します.多くの時間はこれらのどうでもいい仕事を修正するために無駄になります.
じゃ、本題に戻ります. まず次の例を見ます.


//   
public class Product{
     private long productId;
     private String category;
     private String productCode;
     private String productName;
}

//      ，      
public class RecommendProduct{
    private String recommend_username;
    private String recommend_date;
    private Product product;
}

一般的に私たちのデザインはこうです.
検索でListをホームに戻し、操作が完了しました.
もし次のように設計するならばあまり合理的ではありませんて、その上も類の設計の原則----機能の単一性を打ち破りました.


//   
public class Product{
     private long productId;
     private String category;
     private String productCode;
     private String productName;

    //     
     private String recommend_flag;//     
     private String recommend_username;
     private String recommend_date;
}

はい、このデザインをデータのデザインに移します.
プロジェクトとrecommendProductを一枚の表に設計すれば、次のようになります.
プロジェクト表
プロジェクトid.   number(12)
category     varrchar 2(16)
productCode varrchar 2(16)
productName varrrhar 2(32)
recommund_fragchar(1)//推奨フラグビット
最初はそうだったかもしれません.
もし私が10の二級ドメイン名のトップページを紹介したいなら、どうすればいいですか?マークフィールドを10個追加しますか?明らかにこうしてはいけない
対象に向けたデザインを採用しております.
Productテーブル(製品に関する情報のみを含むフィールド)
プロジェクトid.   number(12)
category     varrchar 2(16)
productCode varrchar 2(16)
productName varrrhar 2(32)
RecommendProduct表(別表としてマークではなく)
recommund_id(PK)
プロジェクトid(Fk)
recommund_username
recommund_ダテ
このようにするもう一つの利点は、二つの表の変化は独立してRecommendProductテーブルにフィールドを追加してもいいです.プロジェクトテーブルを設計すれば、最初の問題が発生します.今日はフィールドを追加して明日フィールドを追加します.
対象に向けたデザインの開閉原則を参考にしました.

データ構造——C言語実現シーケンス表