数据库访问层全用存储过程好不好？

[crystalgirl_200]

今天领导让我看个数据库，看看哪里有问题，好不好
结果我一看，天啊，数据库里没有一个视图，却有上千个存储过程，我估计数据库访问层都封在存储过程里了
其中绝大部分都是一句sql，这样做好吗？完全把sql封在数据库里，一个库里有上千个存储过程，这样是不是反而慢了
asp.net的网站，标准的三层架构--表现层，逻辑层，数据访问层，有大概100多个表，这个情况
大家帮我分析下这种架构好吗

[changweishao]

1000多个存储过程，其中绝大部分都是一句sql，这样有些不太好吧！
1，维护起来是个问题；
2，全部的操作都放在服务器端操作，对服务器的压力蛮大的。

[nzperfect]

正常，我们的系统没有视图，全部是存储过程，上W。
你要是orm思想开发，肯定不行了。

各有好处吧
开发重要的是规范，只要规范，就可以。

[nzperfect]

[Quote=引用 3 楼 wgzaaa 的回复:]
视图我是不用，都用存储过程我看也是有病，管理就是麻烦事，不打开都不知道啥意思，数据库文件也会增大，虽然不知道影响有多大，至少感觉是在脱裤子放屁。
[/Quote]

无语。。。

[nzperfect]

[Quote=引用 9 楼 lff642 的回复:]
存储过程,触发器.我一般都使用存储过程来代替触发器的功能,所以我建议使用存储过程.

外键我一般都不用,一般都是程序上控制那些数据用户一定要输入.那个不能为空....
[/Quote]

agree。

[-晴天]

[Quote=引用 10 楼 changweishao 的回复:]
1000多个存储过程，其中绝大部分都是一句sql，这样有些不太好吧！
1，维护起来是个问题；
2，全部的操作都放在服务器端操作，对服务器的压力蛮大的。
[/Quote]

从客户端向服务器请求数据,不还是服务器端的事情?!

[晓风残月0110]

首选支持都是proc
都使用proc可能会慢些(程序速度也不是在使用几个proc上提升的)，
但是在后期维护上有绝对的优势(这很重要)

－－其中绝大部分都是一句sql
尽量写通用的proc,便于开发，并形成规范

[晓风残月0110]

帮你up

[晓风残月0110]

帮你up

[crystalgirl_200]

这个库越来越奇怪，索引少得可怜，一个已经有上百万条数据的表没有索引

[duanzhi1984]

那不是很慢吗？
看来你要优化下你的数据库了

[ITMiner]

封装存储过程主要还是更安全

[hery2002]

今天领导让我看个数据库，看看哪里有问题，好不好
结果我一看，天啊，数据库里没有一个视图，却有上千个存储过程，我估计数据库访问层都封在存储过程里了

-- 如果不考虑数据库移植等问题,和ORM等设计的话,存储过程还是值得推荐的,很多国外的大系统都会使用相当数量的存储过程来替代业务逻辑层的复杂计算,
类似的Oracle里面很多包也是一个原理,通常存储过程可以直接调用和数据库相关的一些系统存储过程来实现一些业务上的加密或者逻辑控制等等,效率也会
有很大的提高.

其中绝大部分都是一句sql，这样做好吗？

-- 这个就要看需要,如果都是一些简单的SQL,写在存储过程里面是预编译,比你写成嵌入式SQL要稍微好一些,而且维护起来,如果只是数据表结构的改动,只需要维护相应的sp即可,维护工作相对较小,

完全把sql封在数据库里，一个库里有上千个存储过程，这样是不是反而慢了

-- 存储过程的多少不会影响数据库的性能的.初次建库除外,初次建库是存储过程的预编译会占用一定的时间.

asp.net的网站，标准的三层架构--表现层，逻辑层，数据访问层，有大概100多个表，这个情况
大家帮我分析下这种架构好吗

-- 还凑合吧,

PS:
如果一个库里面没有主键或者很少的索引外键之类的,
对数据库的增删改查有影响,
能够建的,尽量建好.

[lff642]

学习.

[zero8500]

关注 学习

[Andy-W]

进来关注，学习

[Lacsky]

可是使用存储过程和使用ORM技术如:NHibernate哪一个更好呢?怎么选择呢?

[crystalgirl_200]

在这个库里只有两个db_owner的用户，这样做不对吧，是不是应该把权限单独给出来？？

[wangjingxin1981]

个人认为影响不大

[utpcb]

今天领导让我看个数据库，看看哪里有问题，好不好
结果我一看，天啊，数据库里没有一个视图，却有上千个存储过程，我估计数据库访问层都封在存储过程里了

-- 如果不考虑数据库移植等问题,和ORM等设计的话,存储过程还是值得推荐的,很多国外的大系统都会使用相当数量的存储过程来替代业务逻辑层的复杂计算,
类似的Oracle里面很多包也是一个原理,通常存储过程可以直接调用和数据库相关的一些系统存储过程来实现一些业务上的加密或者逻辑控制等等,效率也会
有很大的提高.

其中绝大部分都是一句sql，这样做好吗？

-- 这个就要看需要,如果都是一些简单的SQL,写在存储过程里面是预编译,比你写成嵌入式SQL要稍微好一些,而且维护起来,如果只是数据表结构的改动,只需要维护相应的sp即可,维护工作相对较小,

完全把sql封在数据库里，一个库里有上千个存储过程，这样是不是反而慢了

-- 存储过程的多少不会影响数据库的性能的.初次建库除外,初次建库是存储过程的预编译会占用一定的时间.

asp.net的网站，标准的三层架构--表现层，逻辑层，数据访问层，有大概100多个表，这个情况
大家帮我分析下这种架构好吗

-- 还凑合吧,

PS:
如果一个库里面没有主键或者很少的索引外键之类的,
对数据库的增删改查有影响,
能够建的,尽量建好.

苦行僧说的很好就这些！


--在这个库里只有两个db_owner的用户，这样做不对吧，是不是应该把权限单独给出来？？
这个要看你的应用程序使用者的对象了

[coldfusion2]

很正常

１存储过程的好处多不胜举，使用存储过程本身肯定是无可厚非的。
２关于一条select也一个存储过程，个人觉得很正常，存储过程的意义本身就不是为了简化sql，而是将数据层与逻辑层彻底分离。
３关于是否方便管理，这就看存储过程写的是否规范，命名是否有规律，相关开发文档是否齐全了，如果书写规范不好，即使写在代码里，同样也不方便管理。