我写的SQL语句大多在CODE里(后台的操作),有些的代码对数据库的操作是固定的!如果你不改变表结构你的SQL语句就不用改了!

解决方案 »

  1.   

    一般来讲,如果是做B/S的系统,由于要有大量的客户要访问数据库服务器,尽量把普通的增删查改语句放到前端,以减轻DB Server的负担,如果是C/S 的或是规模不大的系统,尽量写存储过程以提高效率,总之要看项目的具体情况
      

  2.   

    现在的问题是项目规模不小,但数据库的变化很大,不可能在作之前吧数据库所有的表和字段都确定,大虾们是不是有更好的方案呢?
    性能问题的确是很烦人的事情,把SQl语句放到前端,就像是放颗炸弹在自己旁边,想象一下
    要是我的项目测试版甚至是正式版发布给用户了,而因为是大规模的项目,用户使用集群技术分布数据和前段及中端数据,现在在用户的使用的过程中发现要增加或是修改功能,直接影响到数据库设计,你要是改数据库,你需要把三层的代码全编译再发布给用户,再大规模中就会应为需求变化而失控,
    所以小弟不同意 
    tittoplk(霜冷长河)的前半句论述。
    后半句:为什么C/S就可以尽量写存储过程以提高效率,而B/S不可以,据小弟所知道的,存储过程主要是移植数据和调试的问题大,不知道和B/S,C/S有什么关系。
    sy246(新手!多关照!) :
    数据库不变得情况恐怕只有小到自己玩玩的项目了。谢谢。
    zxkid():
    不错的想法,我听别人说过这样的想法。但不知道重编译问题是不是存在呢?
    要是我的资源文件中的名字不变,但内容变了是不是要整个项目、都要编译呢?
    请指教。
    2000lhzh(不懂就要问):
    现在很多都采用这样的方法。但没有解决根本性问题。
      

  3.   

    我觉得,如果是三层结构,你完全可以把访问数据库的语句放在COM里面呀。要作修改,也只修改COM里面的代码,而不需要改变客户端的语句。
      

  4.   

    To  hhgb():
    理论上是对的,但实际上是困难的;
    在规模较大的项目中,
    要是你把数据库中的所有信息,都封装在类似COM的组件中,会使组件的重用性很小,
    这样组件会很沉余,也很重,修改困难。
      

  5.   

    数据层里定义好各种sql操作前台只需要传递表名、列、值、条件等参数即可
      

  6.   

    To flyby(小维龙):
    这样很麻烦的,如果数据库变化,我必须去改前台,而且我还不知道要改多少地方啊,好多阿。
      

  7.   

    文档只适合很标准的东西,可惜的是软件开发本身就是很不标准,加上需求的多变性就更是了。
    实际上很难维护文档和实际项目进度的一致性,文档只要核心的就可以了。其他代码就可以代表一切了。
    至于SQL用文档记录就很难维护了,数据库在开发期间的变化是很大的,所以我才想要一种至少能在变化产生时知道变化的地方的方案。
    用SQL产生包是一种可能可以的方案。
    但还没有健全,但我个人很喜欢。