第一次具体做ERP项目,希望做得规范些。请教个问题:
我个人认为,从安全角度考虑,客户端的数据层的SQL语句应该首选存储过程,其次视图,最后才是直接写select a,b,.... from table这样的语句,直接的select语句再方便、简单,但只能在前项选择不适用的情况下才能选择。这样虽然会造数据库端多出很多存储过程与视图,造成相当的冗余,导致占用的存储空间增大,但无论如何安全第一。
不知这个观点是否规范?
希望做过商业数据库应用系统的高手指点一二。

解决方案 »

  1.   

    能使用存储过程的就使用存储过程,这个对于后期开发,纠错,优化都更方便。
    就是视图,也建议使用存储过程调用。
    直接调用的select语句尽量避免。别因为图一时的方便而偷懒。存储过程占用的空间基本可以忽略不计,但是效率的提升还是很明显的,安全性更是毋庸置疑。
      

  2.   

    安全性的话,可以通过架构来控制,比如进销存的,就用SD.XXX表,财务的就用FI.xxx表。把账号限制到架构。存储过程是不可避免的了,视图的话从安全性来说可以使用,但是从性能上考虑视图还是要考虑,因为货号很多的时候,视图往往性能存在问题。
    我也是做ERP的,如果可以,尽量多用存储过程,少用签入到应用程序语言的sql语句,特别是拼接SQL,容易导致SQL注入等问题。且效率低。游标尽可能不用。
    大学很多书都有教你做一个简单的进销存系统,而ERP系统只是在这之上的一个扩展。
      

  3.   

    之前都用.net做小的数据库应用程序。其中的SqlDataAdapter这个控件有个非常方便的功能,就是可以通过下面的代码很方便的提交浏览过程中修改的数据项     SqlDataAdapter sda ....
            public DataTable 获取数据表(String p_str命令文本)
            {
                sda.SelectCommand  = new SqlCommand(p_str命令文本,this.sqlConn);
                
                DataSet ds = new DataSet();
                sda.Fill(ds);
    //返回的数据表传给DataGridView
                return ds.Tables[0];
            }
            public void 保存数据(DataTable argDt)
            {
    //这段可以将通过DataGridView控件边浏览边修改数据项提交到服务器。很方便
                SqlCommandBuilder scb = new SqlCommandBuilder(sda);
                sda.Update(argDt);
                return;
            }可SqlDataAdapter.SelectCommand只有在用select * from table 或select * from view的情况下才能调用这一功能。
    我个人觉得边浏览查询记录并可边修改数据是种比较好的用户体验。
    不知大侠们是如何平衡用户体验方面的需求与数据库设计规范方面的要求的?
      

  4.   

    我是做ERP的,C/S架构,数据功能基本上是靠存储过程、触发器、函数实现。用户界面就多种多样了。
    我认为
    空间问题
    存储过程占空间这个说法我不赞同。视图更加没有占空间这种说法了,考虑空间问题,应该从范式出发规范数据表的结构,在数据冗余、查询性能、数据管理方面做权衡
    做好数据一致性的维护,该建主键约束、外键约束的,不该空的,一个都不能少。
    安全问题
    数据库的连接要通过独立模块进行,保证数据出口管理唯一,加密处理。少用动态语句。合理分配权限。