软件开发方式的困惑!

先把数据库设计好，
再编码，
在查找数据库的时候不要用SELECT * FROM TABLE,最好使用SELECT COL1,COL2,COL3 FROM TABLE 的方式，这样当数据库中有新添加的字段的时候程序不会出错。

解决方案 »

  1.   

    在查找数据库的时候不要用SELECT * FROM TABLE,最好使用SELECT COL1,COL2,COL3 FROM TABLE 的方式，这样当数据库中有新添加的字段的时候程序不会出错。晕~
    为什么不用rose了，在建立一个共公环境不就行了吗。大家都可以看的到别人的数据库建模和一些接口方法。
      

  2.   

    看了以上同仁的观点,我有一些意见, 我认为越好的设计应该越不用考虑数据库结构, 不论数据库结构如何变化,甚至发布了之后,或允许用户有一定自设定能力,系统都能适应就最好,这样的系统才具有灵活性和扩展性. 要不然,你将数据库结构当做根基的话, 日后势必要动到根基,原因有很多,例如客户(行业,管理)要求等等,除了某些特殊的\个性的业务逻辑要考虑用户数据库结构之外,都可以做得很通用.我就是这样做的, 代码行虽不多(重用效率很高),但功能却不弱.
    例如速查和搜索只用了不到一千行代码,就实现了在每一个表单中多表,多字段的组合查询.
    据编号回朔或反查的功能就用了更少的代码.以下全部是动态实现的:
    菜单加载和调用,数据加载,权限设置,设置关系,约束,计算列的表达式,默认,控件绑定,DataGrid的多种列样式,甚至数据流转.
    所以代码中几乎看不到Select XXX from, 看不到显式设置关系,约束,计算列,查询和更新语句和条件及参数等一大堆啰嗦的代码,
      

  3.   

    不管你怎么搞!数据库的结构都要先定下来!!!!!alias88() 说的和上面的人说的不是一回事!
      

  4.   

    代码中没有SQL语句,还要事先定数据库结构么,我只在项目(或者只此特定项目吧)开发后期才需要知道数据结构关系. 我现在正在弄数据流, 应该就是楼上所说的模块之间的数据联系吧,在此之前各模块是完全独立的. 具体一点现在在弄取单功能, 考虑得很简单: 事先定好各个上游表字段与下游表字段的对应关系即可统一做取单功能.  或许你们的项目更复杂,或许团队合作要考虑的东西更多,我的某些做法可能行不通,因为我是单干的(学历太低进不了大公司啊,初中没毕业你相信不:D)  不敢说什么模式,也不知道是什么模式(谁知道的话告诉我一下),只知道抽象归类统一处理,最基本的面象对象概念.   总的说来就是必需用元数据,现在的做法是将SQL语句等东东都放在另一库中,这样的话在某些方面甚至可以在实施期间或更以后的使用期来维护元数据满足客户一定的变更需求.  只有不能用元数据描述的东西才需要特别的处理. ;D , 刚总结出这句话,简直觉得很是经典 :Q   兄弟我没同学没同事可以交流,孤陋寡闻不要笑我, 你们都是怎么做的呢?