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

------解决方案--------------------
能使用存储过程的就使用存储过程，这个对于后期开发，纠错，优化都更方便。
就是视图，也建议使用存储过程调用。
直接调用的select语句尽量避免。别因为图一时的方便而偷懒。

存储过程占用的空间基本可以忽略不计，但是效率的提升还是很明显的，安全性更是毋庸置疑。
------解决方案--------------------
安全性的话，可以通过架构来控制，比如进销存的，就用SD.XXX表，财务的就用FI.xxx表。把账号限制到架构。存储过程是不可避免的了，视图的话从安全性来说可以使用，但是从性能上考虑视图还是要考虑，因为货号很多的时候，视图往往性能存在问题。
我也是做ERP的，如果可以，尽量多用存储过程，少用签入到应用程序语言的sql语句，特别是拼接SQL，容易导致SQL注入等问题。且效率低。游标尽可能不用。
大学很多书都有教你做一个简单的进销存系统，而ERP系统只是在这之上的一个扩展。
------解决方案--------------------
对于用户体验，其实很简答，去那些大网站，特别是电子商务网站，逛一段时间，基本上某个功能要做成什么样就行拉。
------解决方案--------------------
明确地说，当你没真正做过系统之前，很难去关注到什么规范。。
如果没有带路者，就摸着石头过河吧。。。这是现实

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