Y
yyanghhong
Unregistered / Unconfirmed
GUEST, unregistred user!
按照class model driven的思想, 应当先设计类, 再设计表结构, 按照data model driven的思想, 应当先设计表结构, 然后在程序的设计中设计类. 我想看看大家都是怎样做的.
安
安稼
Unregistered / Unconfirmed
GUEST, unregistred user!
准确地说按照usercase driven的思想，应当是先设计类，表结构的设计应当放在后面的设计过程中。建议参考RUP
B
billy_yuan
Unregistered / Unconfirmed
GUEST, unregistred user!
这个问题有点意思，按面向对象的思想，绝对是先设计类，然后设计物理的表结构，
但是实际开发中，一般都是先设计表，然后再设计类（就我所碰到的情况而言）。
但是实际开发中，一般都是先设计表，然后再设计类（就我所碰到的情况而言）。
Q
quickp
Unregistered / Unconfirmed
GUEST, unregistred user!
这个问题不只是设计问题，而应放到整个软件开发流程来看，还要看你的分析阶段的output是什么
C
cmq2002soft
Unregistered / Unconfirmed
GUEST, unregistred user!
数据表只是提供数据用的，如果不知道使用什么样的数据，如何设计
类设计是确定有哪些操作、使用什么样的数据、如何取得、如何保存、如何传递。
所以我认为应该先设计类，后设计表结构
类设计是确定有哪些操作、使用什么样的数据、如何取得、如何保存、如何传递。
所以我认为应该先设计类，后设计表结构
V
vickymade
Unregistered / Unconfirmed
GUEST, unregistred user!
类
T
taotao5156
Unregistered / Unconfirmed
GUEST, unregistred user!
先设计类，后设计物理的表结构
J
jiangxiao
Unregistered / Unconfirmed
GUEST, unregistred user!
我想应该是从类开始设计。类的设计，数据就已经包括了。
实际上可以说是一个总体的设计。然后细化。
但是我做不到，也不知道为什么。
实际上可以说是一个总体的设计。然后细化。
但是我做不到，也不知道为什么。
C
claudchen
Unregistered / Unconfirmed
GUEST, unregistred user!
我并不认为这两者有什么冲突。
1 首先，就数据库设计而言，E-R模型的建立是最先的。但是E-R模型只是逻辑建模，
并不对应实际的物理表结构。E-R模型完全可以用UML的静态类图表示，实际上E-R模型也
是一种类之间的关系，我认为他们是一回事，完全可以用一个静态类图来描述类关系和E-R模型，然后分别实现成程序和物理库结构。
1 首先，就数据库设计而言，E-R模型的建立是最先的。但是E-R模型只是逻辑建模，
并不对应实际的物理表结构。E-R模型完全可以用UML的静态类图表示，实际上E-R模型也
是一种类之间的关系，我认为他们是一回事，完全可以用一个静态类图来描述类关系和E-R模型，然后分别实现成程序和物理库结构。
Y
yyanghhong
Unregistered / Unconfirmed
GUEST, unregistred user!
类设计和表设计还是有差别的, 他们在关联这点上有相似之处, 但类设计强调对象封装和继承, 表设计强调数据访问的高效.
打一个最简单的例子, 比如类成员可以由很多对象组成, 但我们不一定要把类中所有对象放到不同表中去, 如果这样就会造成太多的表关联, 影响查询速度.
打一个最简单的例子, 比如类成员可以由很多对象组成, 但我们不一定要把类中所有对象放到不同表中去, 如果这样就会造成太多的表关联, 影响查询速度.
E
EdwinYeah
Unregistered / Unconfirmed
GUEST, unregistred user!
使用bold 等有o/r mapping功能的framework,你就可以只设计类，数据库结构自动生成：）
G
gamethelife
Unregistered / Unconfirmed
GUEST, unregistred user!
数据表只是数据存储的一种方式，用OO的观点来看，也可以认为这是数据存储的一种封装（行和列）。所以我的观点是先设计类，在由类映射到表。 但在实际开发中，往往要受项目组其他开发成员观点的影响而不得不先设计表。[
]
]
P
pyzfl
Unregistered / Unconfirmed
GUEST, unregistred user!
个人认为，用类来模拟现实，是一个误区。
在很多书上举例说明OOP时，都是以“人，男人、女人，大男人、小男人、大女人、小女人”等现实情况来类比。
但在程序设计时，如果真的模拟现实来建立“部门，仓库、办公室、一车间、业务部……”等类的话，个人认为是一种吃力不讨好的事，因为现实是很复杂多变的，可以用OOP思想来分析，但并不绝对符合OOP，假如真符合的话，也是一张弥天大网。
所以，在程序开发时，可用OOP分析业务逻辑，然后确实数据结构(能放到后面吗？)，再用OOP方式建立程序单元，进行开发。
程序开发中，一定要清醒，程序就是程序，OOP封装的，也是程序对象，不可能封装真实世界。
个人看法，仅供娱乐！
在很多书上举例说明OOP时，都是以“人，男人、女人，大男人、小男人、大女人、小女人”等现实情况来类比。
但在程序设计时，如果真的模拟现实来建立“部门，仓库、办公室、一车间、业务部……”等类的话，个人认为是一种吃力不讨好的事，因为现实是很复杂多变的，可以用OOP思想来分析，但并不绝对符合OOP，假如真符合的话，也是一张弥天大网。
所以，在程序开发时，可用OOP分析业务逻辑，然后确实数据结构(能放到后面吗？)，再用OOP方式建立程序单元，进行开发。
程序开发中，一定要清醒，程序就是程序，OOP封装的，也是程序对象，不可能封装真实世界。
个人看法，仅供娱乐！
D
DelphiWW
Unregistered / Unconfirmed
GUEST, unregistred user!
交互设计