你们做项目一上来就是设计数据库吗？
没做过大型的项目，我们一般一上来分析一下需求后，就开始设计数据库了，这个我感觉不合理吧。

请问下，你们一般是怎么做的？整个流程是怎样的？

------解决方案--------------------
做好业务需求很重要，时间也很长
再建立相关模型

------解决方案--------------------
没接触过那么那么大型的项目。
悲剧啊
------解决方案--------------------
这个没什么不合理的。

在面向对象没出来之前，都是先设计数据库的，难道都不合理？

面向对象出来了，就不能先设计数据库了？太霸道了吧。


建立相关模型是一种方法。

建立相关数据库是另一种方法。


看熟悉哪一种了。



业务需求确实很重要，但是也确实很难，很难弄明白客户到底想要什么。



步骤：

1、签合同（略过）

2、调用、需求分析

3、设计

4、文档（各种文档）

5、实现原型，与客户确认。

6、编码

7、内部测试

8、客户测试

9、如果客户有修改意见，酌情。


------解决方案--------------------
先是业务需求，不然做了也白做。跟着客户转。
------解决方案--------------------
我觉得先定数据库好.它是根基.
因为数据库/表/字段对逻辑层以及数据层的影响很大,数据库结构一变化,往往会牵一发而动全身

当然,定数据库时,往往会考虑功能/页面/性能/安全等各方面.

------解决方案--------------------
根据业务需求，数据库建模
------解决方案--------------------
这些大虾们都是回答问题也是连锁反应的？
------解决方案--------------------
先分析基本流程，然后构建原始数据库；再画流程图，画这个一定要花大量时间！ 之后才开始写程序。。。。
------解决方案--------------------
需求明确之后，设计数据库。
------解决方案--------------------
我们也这样，上来就先PD，然后业务层，模型层生成，最害怕的就是变需求！！ 我可以很负责任地告诉你说，这么做很不正确，但没办法我们是在中国！10个人能写出100种代码来，日后的维护及需求的变更是非常让人头痛的！
------解决方案--------------------
需求分析要很长时间，之后是建立数据库模型，当然，随着项目的深入数据库会有所变动，不过这是难免的！~
------解决方案--------------------
非也，我们并不建议一上手就开始做数据库

因为从数据库开始都是一些细节上的事情了，而一开始就做数据库容易过度细节化

实际真正的大型项目是不太可能像用户注册页那样一眼就可以看到细节的，所以大型项目通常使用原型标靶，先OO去掉所有修饰，只保留基本关系，然后直接用OO出的对象建立原型标靶系统（看不见没关系，看不见就做标靶试着开两枪，看看离靶子有多远，准星是否调好了）

注：做原型标靶的时候，实际上根本就用不着数据库。为了快速逼近目标，只需要基础模型+单元测试就足够了