用面向对象思想设计数据库

对于开发者来说 由于数据结构的变化导致程序的修改无疑是让人头疼的 。尤其是那些频繁的修改 今天加一个字段 明天又加一个字段， 大量的时间都浪费在修改这些无关紧要的工作上了。

好了，言归正传  先看下面一个小例子

//商品类
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<RecommendProduct>到首页， 操作完成

如果想下面这样设计就不太合理，而且也打破了类设计的原则----功能单一性

//商品类
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;
}

好了 现在把这个设计照搬到数据的设计上
如果将product和recommendProduct设计在一张表中如下
Product表
product_id   number(12)
category     varchar2(16)
productCode  varchar2(16)
productName  varchar2(32)
recommend_flag char(1) //推荐标志位
一开始可能是这样
如果我要推荐到10个二级域名的首页怎么办？要加10个标志字段吗？显然这样做不行

采用面向对象的思想设计如下
Product表(只包含产品相关信息的字段)
product_id   number(12)
category     varchar2(16)
productCode  varchar2(16)
productName  varchar2(32)

RecommendProduct表（作为单独表 而不是一个标志为）
recommend_id (PK)
product_id (Fk)
recommend_username
recommend_date

这样做的另外一个好处是：两个表的变化是独立的 可以在RecommendProduct表中添加字段而不会影响到product表 如果设计在一起的话就会出现开头说的问题 今天加一个字段明天加一个字段情况

借鉴了一些面向对象设计的开闭原则

的确，反复的对数据库中的字段进行增加和修改是个头疼的问题，经常导致修改代码。运用面向对象的思想对数据库进行设计和改动还是十分不错的。

非常认同，但是我们公司的两个老鸟总是说我设计的数据库表太多，字段太少。看他们的设计真是吓人啊，表的字段多得让人直冒汗，还有许多在功能上是重复的。

你就不考虑查询效率了？！
难道不考虑两个过万的表JOIN是灾难性的？

这还叫老鸟啊，许多在功能上是重复的就没有必要了吧，一般来说以前的程序员在使用事务脚本编程的时候确实会把表的字段搞的很多，但是人家并不是面向对象编程，所以问题不大，但是在设计的时候搞出很多冗余来就不应该了吧，可能那些所谓的老鸟还是喜欢事务脚本，而不是oo