免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 夜猫子

[转贴]已经过了两年了,不知道结论还正确吗? [复制链接]

论坛徽章:
0
发表于 2003-04-01 21:09 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

回楼上。。
你是程序员吗?还是DBA?
不知你对数据库认识有多少。如果你真的用过Informix,你就不会再用MYSQL了。
有些环境MYSQL是不行。你是不是只做一些B/S,web页一类的开发。。

不知你接触过。银行,超市,证券,数据统计,大量数据分析。。。没。
如果你不想花¥¥¥买商业数据。PostgreSQL是最好的选译。。

还有你不要听信网上的对PostgreSQL与MYSQL的评论。。它们一般是做个程序来循环,读,写数据库。而不是对数据库事处比较。如果这样比下去。
任何数据都会失给MYSQL。Oracle是最慢的。

如果比事务处理能力。Oracle,PostgreSQL,SQL Server,SyBase....它们都可以在一个过程中执行一批SQL指令。而不是MYSQL那样。每次执行一条SQL并而每次都要与数据连接一次,关闭一次。

论坛徽章:
0
发表于 2003-04-01 21:55 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

呀!才发现。都到第二页了。我发完没看到结果。就以为没发出去。
所以发了很多重负的。。不家原量。。

不用触发器的生产系统,或者你的系统太小,或者你的构架不好。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

得了吧,少吹了。不是系统太小,而是系统太大,我用4台PC SERVER支持600万用户的系统,谁敢乱用触发器。要上的新系统倒是两台690,不过数据库容量20T,而且不是DSS,OLTP和批处理混和,你用触发器看看。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

20T,不用OLTP,不用DSS,确实是“你的构架不好”
这么大的系统为什么不用集群,和HA?????

对大家不要为了触发器,VIEW吵了。 我在上文提到触发器是因为在PostgreSQL里。它可以触发一个过程。PGSQL里触发器不像Oracle可以单独用。
我是想让大家尽量在数据库中处理,反回结果集。而不是在程序读出后再在程序中处理。不要把数据当成只能读记录的表。一些高级应用,多用一些。

楼上的朋友20T的数据库我想能不能给大家介绍一下管理经验,你不用触发器,不用VIEW,不用游标,不用序例。。。。。
你只用select ,insert,update,delete......你是如何管理的。。。。
不用游标。你每次select 都要检索20T的数据。。是如何做到的。。
记得我有一次去客户那,好奇想看看从没见过那么大的数据量,select * from tabe where date = 某年,计时,天那足足有两三个小时才处理完。

论坛徽章:
5
荣誉会员
日期:2011-11-23 16:44:17CU大牛徽章
日期:2013-09-18 15:15:15CU大牛徽章
日期:2013-09-18 15:15:45未羊
日期:2014-02-25 14:37:19射手座
日期:2014-12-26 22:55:37
发表于 2003-04-01 22:52 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

[quote]原帖由 "netkiller" 发表:
呀!才发现。都到第二页了。我发完没看到结果。就以为没发出去。
所以发了很多重负的。。不家原量。。
不用触发器的生产系统,或者你的系统太小,或者你的构架不好。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

论坛徽章:
5
荣誉会员
日期:2011-11-23 16:44:17CU大牛徽章
日期:2013-09-18 15:15:15CU大牛徽章
日期:2013-09-18 15:15:45未羊
日期:2014-02-25 14:37:19射手座
日期:2014-12-26 22:55:37
发表于 2003-04-01 22:54 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

[quote]原帖由 "netkiller" 发表:
回楼上。。
你是程序员吗?还是DBA?
不知你对数据库认识有多少。如果你真的用过Informix,你就不会再用MYSQL了。
有些环境MYSQL是不行。你是不是只做一些B/S,web页一类的开发。。
不知你接触过。银行,超市

论坛徽章:
0
发表于 2003-04-02 01:14 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

回楼上。to wolfop

呀!才发现。都到第二页了。我发完没看到结果。就以为没发出去。
所以发了很多重负的。。不家原量。。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

些贴之前:我看到的是你第一页最后一贴。没看到你后来的贴。。。。回贴与是回的第一页最后一贴。
“说实在,MYSQL已经支持外件了,至于触发器,我们再生产系统中的INFORMIX都不用这个东西。”
所以我的回复时我没看到结果。就很了很多次。也改了很多次。所以每行里都有
“回楼上。。
因为你是程序员,不是DBA。。


另请,在公共场所注意形像,言语。

另外你是否知道库的大小和表的大小的区别?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
不mount数据,能操作表吗?


你用过多大的系统
^^^^^^^^^^^^^^^^^^
做过商场,各种报表,图表(直方图,饼图,折线图)都是B/S结构,客户的需求。
数据多少T我不知,数据从1990--2002年,每日都有几千到几万条记录都可以查到 (其中一部分早期数据是FOXPRO导到ORACLE中的用于分析)
那时我拿到了它们的所有数据库资料。看了人家写的过程,触发器,视图……………………自叹不如。

他们的系统全是SUN的。管理是telnet登录后运行一个程序实现的。很多操作如(计算,分析,汇总等等。。。)都是在数据库中完成,通过PL/SQL。大量的使用过程,视图,触发器。select 操作都是通过视图进行。。。。

我在工作中发现。连接池如果使用不当。ORACLE常常用尽内存。我对连接池优化一下,但不管是如何优化,数据并发是一定的。比如1000就是1000,在优化也不可能超过1000,
所以我的经验就是能在数据中完成的工作不在应用程序中完成,程序多连接一次数据,1000-1,就会有一个用户连不上。我于是将要多次连接取值的操作,合并,写成一个数据库过程。


我的经验:
我现在,用pgsql 做项目。。
目前是
Form ==>; jsp ==>; javaBean ==>; jdbc(pgsql or class12.zip) ==>;
如果是select 用view来做,并格式化如to_char()。
如果是删除记录并涉及外键。就用触发器去删除外键的表。。 如果用程序完成。要执行多条SQL
如果是大量查找分析就用select func() 过程来做。然后反回结果集。
如果是一些特定的操作,一条SQL无法完成,也用过程例:adduser(varchar,varchar),deluser(integer id).......ext
目前还没用到游标。。

总之用最少的连接做大量的处理。尽量在数中完成操作。能用数据库的不用程序做。。。。。。。




什么时候MYSQL需要执行一条SQL语句就需要连接一次关闭一次了,你的论据来自造谣么?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
B/S下的开发。你可以去看
public getlist(){
   db.connect();
   try{
        rs = executeQxxy("select ...x.x.x..x.x";

        while(rs.next){
                rs.getString(xxxx);
                ...
        }
   catch(xxxxx e){
        e.xxx.x.x.x.();
    }       
   fainly{
       db.close();
   }
}
类似这个。。如果你不关。一会数据连接池就玩完。。。。




ORACLE是第一,而MYSQL是第二
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
你也可以到GOOGLE上找找。。看看谁第一,谁第二。。。
论据是不是来自造谣么?我不知。。测试方都是权威公司。搞的。。




最后:
谈谈你们做什么应用。。你的经验。。

论坛徽章:
0
发表于 2003-04-02 09:31 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

原帖由 "wolfop" 发表:

得了吧,少吹了。不是系统太小,而是系统太大,我用4台PC SERVER支持600万用户的系统,谁敢乱用触发器。要上的新系统倒是两台690,不过数据库容量20T,而且不是DSS,OLTP和批处理混和,你用触发器看看。


确实如您所说,触发器会影响效率,所以在触发器里面做什么工作是需要特别注意的。而且oracle的触发器功能非常强,如果不注意使用,确实会使用系统出问题。

主要问题是,在触发器里面做什么工作。触发器应该处理最密集应用的n%以内的代码。
代码最终还是要运行的,不同的就是在什么时间什么地点运行。分析、优化和决策,就是DBA的工作。您的说法,完全否定了触发器在大型数据库里面的应用,我认为未免偏颇。

而且您说,系统是在PC SERVER上跑。我的经验是oracle在64位的环境下才能有最大发挥

另外关于表的大小的问题。oracle既提供了一些对表的存储优化的功能,也提供对表的分割优化的功能。能管理20T的数据,您也是专业的DBA了。这些工作您一定也会做。不过您告诉我您是4个pc server,而不是告诉我您有磁盘数量、速度,内存容量、速度,这让我感到很不理解。另外如果对运算有要求,就应该告诉我您的PC server的OS以及CPU的数量

当然您对触发器的谨慎是有道理的,我支持谨慎使用触发器的观点。

论坛徽章:
0
发表于 2003-04-02 09:51 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

re: wangrujun   
同意

不过我工作中用的最多是过程,不管什么技术,只要合理使用就行。

再问一下wolfop 你用什么牌子的PC SERVER?用什么操作系统?
我以前用联想,RAID5。。。做ORACLE数据服务器,常常崩溃原因是联想的硬件太差。双CPU的服务器运行一段时间(几个月到半年)不是其中一块CPU不工作,就是1000内存数据成了256,要不就是RAID 模块上的硬盘掉盘。  解决方法,开机箱,按一按CPU。内存拔下来。在插上去,RAID rebuild.....
搞死人啊。。。。
你的PC是什么牌的。

论坛徽章:
5
荣誉会员
日期:2011-11-23 16:44:17CU大牛徽章
日期:2013-09-18 15:15:15CU大牛徽章
日期:2013-09-18 15:15:45未羊
日期:2014-02-25 14:37:19射手座
日期:2014-12-26 22:55:37
发表于 2003-04-02 11:56 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

[quote]原帖由 "wangrujun" 发表:

确实如您所说,触发器会影响效率,所以在触发器里面做什么工作是需要特别注意的。而且oracle的触发器功能非常强,如果不注意使用,确实会使用系统出问题。
主要问题是,在触发器里面做什么工作。触发器应该处

论坛徽章:
1
荣誉版主
日期:2011-11-23 16:44:17
发表于 2003-04-02 15:26 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

原帖由 "netkiller" 发表:

总之用最少的连接做大量的处理。尽量在数中完成操作。能用数据库的不用程序做。。。。。。。



不同意这种观点,虽然存储过程和触发器有种种好处,但是逻辑过程全部依赖于它实现,是有问题的:
1、如果逻辑全部在存储过程中实现,那么涉及广泛业务逻辑和处理的应用程序可能会给服务器带来过重负荷。这类处理包括数据传输、数据遍历、数据转换和大计算量操作。应把这类处理移到业务或数据逻辑层中,与数据库服务器相比,它们具有更好的可缩放性。

2. 不要把所有业务逻辑都放在存储过程中。如果必须修改业务逻辑,应用程序的维护和灵活性将成为问题。例如,支持多个 RDBMS 的 ISV 应用程序不应当分别为每个系统维护存储过程。

3.通常,存储过程的编写与维护是一项专门技能,并非所有开发人员都能够掌握。这会造成项目开发计划的瓶颈。

http://www.yesky.com/20021112/1639500_2.shtml

总之,大的系统中,并不能过多的依赖于存储过程来完成业务和数据逻辑层该做的事情

论坛徽章:
0
发表于 2003-04-02 16:08 |显示全部楼层

[转贴]已经过了两年了,不知道结论还正确吗?

我看了你的给的
http://www.yesky.com/20021112/1639500_2.shtml

配合使用数据访问逻辑组件与存储过程
  可以使用存储过程执行数据访问逻辑组件支持的许多数据访问任务。

  优点

1.存储过程通常可以改善性能,因为数据库能够优化存储过程使用的数据访问计划并为以后的重新使用缓存该计划。

2,可以在数据库内分别设置各个存储过程的安全保护。管理员可以授予客户端执行某个存储过程的权限,而不授予任何基础表访问权限。

3,存储过程可以简化维护,因为修改存储过程通常比修改所部署的组件中的硬编码 SQL 语句要容易。然而,随着在存储过程中实现的业务逻辑的增多,上述优势会逐渐减弱。
4,存储过程增大了从基础数据库架构进行抽象的程度。存储过程的客户端与存储过程的实现细节和基础架构是彼此分离的。
存储过程会降低网络流量。应用程序可以按批执行 SQL 语句而不必发出多个 SQL 请求。
5,尽管存储过程具有上述优点,但仍有某些情况不适合使用存储过程。

  缺点
1,如果逻辑全部在存储过程中实现,那么涉及广泛业务逻辑和处理的应用程序可能会给服务器带来过重负荷。这类处理包括数据传输、数据遍历、
数据转换和大计算量操作。应把这类处理移到业务过程或数据访问逻辑组件中,与数据库服务器相比,它们具有更好的可缩放性。

2,不要把所有业务逻辑都放在存储过程中。如果必须在 T - SQL 中修改业务逻辑,应用程序的维护和灵活性将成为问题。例如,支持多个 RDBMS 的 ISV 应用程序不应当分别为每个系统维护存储过程。

3,通常,存储过程的编写与维护是一项专门技能,并非所有开发人员都能够掌握。这会造成项目开发计划的瓶颈。

它是用ADO.net举例了。。。我没用过不好评论。
JavaBean EJB到是懂一些。
只要合里使用,应该没问题。太依赖程序也不好,如果是C/S结构,要改一动一下程序,就得编译。然后全公司都要装一遍。(只是个例子,现实中可能很少遇到)
如果用EJB技术 。数据访问逻辑组件部署在Application Server 上,这样做好些。如果数据访问逻辑组件全放在client端 处理我不支持。。。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP