这个问题其实本来无所谓,考虑一下也不浪费太多时间。
先考虑一个只有一个模块的系统,这样可以屏蔽很多干扰,假设这是一个库存管理模块,显而易见有两个核心实体:品种及库存,再考虑品种的设计,我们又可以得出分类这样一个字典表。在这个分析过程中,实体是表还是对象因人而异。我属于那种后来学习直拍反打的选手,因此习惯上直接把实体建成了数据库表。但对于类似王皓这样的不会推挡只会反打的选手,那就一定是对象了。
从O->R有一些好处就是在分析设计的时候有了更细腻的方法(直拍反打称为手法)对设计进行细嚼慢咽,但是同时也消耗了更多的时间。
从R->O的好处是你直接与数据库进行了对话,因此你了解它的实际构造。在需要的时候将R变为O来操作,你仍然可以使用你所熟悉的SQL对数据库进行直接了当的操作。
再考虑有多个模块的系统,假设系统的模块已经划分妥当(不在本文讨论范围之内),从O出发的选手有很多的方法和理论来实现模块之间的松耦合。而从R出发的选手则只有一个方法,即为两个模块建立R,而这个R最好只建立在一张表上。
因此,考虑到OODB的局限性,如果你是老选手,你仍然具有优势,但这个优势能保持多久则很难讲。
先考虑一个只有一个模块的系统,这样可以屏蔽很多干扰,假设这是一个库存管理模块,显而易见有两个核心实体:品种及库存,再考虑品种的设计,我们又可以得出分类这样一个字典表。在这个分析过程中,实体是表还是对象因人而异。我属于那种后来学习直拍反打的选手,因此习惯上直接把实体建成了数据库表。但对于类似王皓这样的不会推挡只会反打的选手,那就一定是对象了。
从O->R有一些好处就是在分析设计的时候有了更细腻的方法(直拍反打称为手法)对设计进行细嚼慢咽,但是同时也消耗了更多的时间。
从R->O的好处是你直接与数据库进行了对话,因此你了解它的实际构造。在需要的时候将R变为O来操作,你仍然可以使用你所熟悉的SQL对数据库进行直接了当的操作。
再考虑有多个模块的系统,假设系统的模块已经划分妥当(不在本文讨论范围之内),从O出发的选手有很多的方法和理论来实现模块之间的松耦合。而从R出发的选手则只有一个方法,即为两个模块建立R,而这个R最好只建立在一张表上。
因此,考虑到OODB的局限性,如果你是老选手,你仍然具有优势,但这个优势能保持多久则很难讲。