Chinaunix

标题: [转贴]已经过了两年了，不知道结论还正确吗？ [打印本页]

作者: 夜猫子 时间: 2003-01-29 10:44
标题: [转贴]已经过了两年了，不知道结论还正确吗？
转贴自http://www.linuxforum.net/forum/showflat.php?Cat=&Board=db&Number=379325&page=0&view=collapsed&sb=5&o=31&fpart=

在网络上看过很多关于mysql和postgresql的争论，这篇比较有意思，不过看到最后也就得到了每次这种讨论的最后结论，都是一样的，这种结论也许就是真实的。有一些具体事例搀杂其中，注意这是两年前的帖子，如果有兴趣的话，不妨按照他的测试方法使用现在最新的版本再测试一下，那些老版本里的8k限制现在已经在新版本里没有了。

**************************************************
MySQL和PostgreSQL的比较

2001/01/20 13:34 　

我使用哪个数据库：PostgreSQL 或 MySQL?

这个老生常谈的问题已经困惑了开发者至少两年了。我全面地接触了这两个数据库系统（MYSQL有一年，而Postgres有二年了），而且对MySQL网站提出的关于两者之间的差异非常好奇。

1999年9月，当我们正开始对SoureForge架设基础的时候，我对这两个数据库作了性能测试。当时，尽管我已经习惯于使用Postgres完成所有工作，但两者的性能差异是如此之明显以至与我们不得不采用MySQL。其他的惯用MySQL的开发者也拥护这个决定。

在当时，这个性能测试要胜于平时任何人为的测试。我想看看这两个数据库在网站某一具体的网页上应用的情况。所提及的这个网页是SourForge讨论区。它包括3个表的简单相关结合。每个表有20-30,000行数据。以及递归的实现和嵌套的信息，所以数据库在此页上的应用确实是一个瓶颈。

开始实行，我从库中卸下了真实的数据。编辑了SQL表，并且将其导入MySQL 3.22.30和PostgreSQL7.0.2，运行在拥有1G RAM 的VA Linux quad-xeon 4100 server上的Red Hat Linux 6.2上。

使我陷入的第一个问题是，在Postgres中，有一个不可思议的问题：每行数据最多只能有8K。在信息公告板上，你时常会超过每行8K的限制。所以Postgres在导入数据时阻塞。为了能继续使用，我只得将数据的"body"抛弃，并且重新导入数据。Postgres 开发小组已经意识到了这个限制，并且在7.1的版本中修改了，而且他们告诉你，你可通过重新编译Postgres使得它支持32K/每行，尽管这样做会使整个系统的性能受到影响。

在这一点上，我又陷入了Postgres另一个小问题上，它的"serial"数据类型（等价于MYSQL的auto_increment)会造成一个"sequence"：当它的双亲表被抛弃时，它本身不被抛弃。因此，当你想重新创建这个表时，会引起一个名字冲突。有许多新的用户被这个问题所困惑，所以这些问题使Postgres在测试中失去一些优势。相反，MySQL聪明到它可以在你导入数据的时候对auto_increment进行自动增量，然而Postgres的sequence 不可以在你导入数据时重置，从而引起新插入操作的失败。

方法

为了尽可能地真实，我从网站上选择了实际的网页，并且使它轻巧地交叉于MySQL和Postgres之间。这基本上意味着所有mysql_query()调用将被pg_exec()替换。这个页包括许多选取与连接操作，与典型的网站做的差不多。

一旦这个测试页运行和调试，我便使用"AB"，就是"Apache Benchmarking"应用集，从我的工作站通过我的100M局域网到达quad-xeon服务器。为了在负载的数量上得到一个概念，我使用AB进行各种并发连接的测试，从10-120,当离开了这些页后，这个数稳定在了1000上。

为了更加地接近实际应用，我在脚本中安置了一个随机数生成器，它插入页面的10%的数据到数据库中。在PHPBuilder中所有讨论区页面有10%是作为发送新信息的。

进一步地，就以上所说，我都使用从现成的数据中提取的数据，你得不出比此更真实的情况了。

我觉得测试结果中最有意思的事情是观察没有出错情况下已经装入运行的Postgres能负载多少。实际上，Postgres在没有错误的情况下负载好像要比MySQL高3倍。MySQL在负有40-50个并发连接时开始失常，而在没有其它影响的情况下，Postgres能使120个并发连接运行自如。我的猜测是：如果有足够的内存与够快的CPU，Postgres能够正常负载的远远不止120个并发连接。

表面上看，这显然是Postgres的一个巨大的胜利，但是如果你仔细观察一下更多细节的测试结果，可以发现Postgres生成每页的时间要长2-3倍，所以它需要扩展负载至少2-3倍则刚好能与MySQL打成平手。所以按照不出错误的情况下，两者并发生成尽可能多的页，则他们之间几乎没有什么差别。按照某一时刻生成一页的情况看，MySQL确实快2-3倍。

另外一个有趣的事情是：在以上叙述的"10%插入运算"的测试中，MySQL在分解运算方面快一些。研究表明，当插入运算操作发生时，MySQL锁定整个表，而Postgres有一个美妙的"better than row-level locking"的机制。这个不同很快引起了MySQL并发连接的堆积，从而导致崩溃。同样的，如果你正在从数据库中进行大量的选中操作，而另外的进程正在对表进行插入操作。Postgres可以完全地不受干扰，而MySQL会堆积连接直到像纸牌做的房子一样崩溃。

你会发现在PHP中的稳定的连接并不有助于MySQL多少，相反却明显地有助于Postgres。实际上，其于稳定的连接的Postgres测试要快30%。这就告诉我们，Postgres在开放性连接与确认进程上需要占用大量的系统开销。其中有一些是Linux的错误和它的和僵硬的进程安排。尽管如此，MySQL并不再乎你如何看待它。

MySQL

MySQL的优缺点已经为许多人所知道：它是一个快速的、轻量级的数据库，但是基本上可以为大多数的网站服务得很好。

无论如何，如果你计划在一个高流量的站点（说明，每天生成多于500,000页）上，那么忘了MySQL吧。因为它往往会崩溃或者在装入运行后死机。任何曾经访问过Slashdot的人都可以证明它的弱点。（mod_perl and MySQL) 话说回来，MySQL证明了可使极大多数网站的页生成速度最高在每秒15页。如果你经常地运行在每秒15页之上，那么你将会非常高兴地支付更大的服务器或者Oracle license的费用。

优势

明显地，MySQL胜过Postgres的优势就在于性能。而且在它的发行版中，还具有一些强有力的管理工具。（其中一些工具允许你察看进程并且可以在程度运行时进行动态调试。）比如热备份，文件毁坏恢复工具等。

我也非常热衷于MySQL的命令行工具。你可以使用描述和察看命令来观察数据库与表的结构。而Postgres的命令则明显地少(/d可以显示一张示范表）局限性

从数据库行家听说的第一件事就是MySQL缺乏transactions,rollbacks, 和subselects的功能。如果你计划
使用MySQL写一个关于银行、会计的应用程序，或者计划维护一些随时需要线性递增的不同类的计数器，你将缺乏transactions功能。在现有的发布版本的MySQL下，请不要有任何的这些想法。（请注意，MySQL的测试版3.23.x系列现在已经支持transactions了）。

在非常必要的情况下，MySQL的局限性可以通过一部分开发者的努力得到克服。在MySQL中你失去的主要功能是subselect语句，而这正是其它的所有数据库都具有的。换而言之，这个失去的功能是一个痛苦，但是它可以被克服。

稳定性

MySQL在长期使用的稳定性上失了分。比如，MySQL在运行了30-60天左右的时间后，没有理由地就放弃了随机ghost。许多开发者使用"statically"来编译MySQL就是为了这个原因，而且这个方法帮助了许多人。这个问题也可以通过设置一个好的调度程序让MySQL每月被杀死并重起一次来克服。这并不是一个完全可取的方法，但至少也是一个办法。

MySQL在守护进程的健壮性上也失了分，但这个缺点被MySQL从来不会出现不可靠的数据文件而弥补。最后
一件让人担心的事就是你重要的数据文件会不期地出错，而MySQL却很好地解决了这一点。在一整年的运行MySQL之后，这从未见过数据文件或索引文件轻易地出错。而在同样的时间内，我已经为一些Postgres数据库做了2-3次的恢复了。（记住，备份永远是你最好的朋友，这点可以从PHPBUILDER数据的崩溃看出）

PostgresSQL

Postgres的测试结果可能会使许多人感到惊奇，尽管Postgres在一些网站开发者中声誉并不怎么好（最初的Postgres的发布版本中除了对落后的性能以外，而对其他部分大肆散布谣言）。但根据我的经验和测试，这些不良声誉并不完全有理由。实际上，PostgresSQL可以承受3倍于MySQL的负载而且没有任何错误，当然在相同的硬件和系统环境下。

Postgres一般运行在 10页/每秒的速度之上，足够为 400,000页/每日的流量服务，假定一个规则的流量曲线峰值2倍于最小值。这是一个可怕的数量，它远远地超过了大多数人要在他们的网站上看到的数量。此外，网站的大多数页没有这次测试中的那么复杂。正如MySQL的情况一样，如果你可以超过这个最高限度，你将会非常乐意地花钱添置硬件。由于Postgres的结构，如果你增加处理器和内存，那么它的性能可以继续增长。

优势

Postgres有一些非常高级的功能。而其中的大多数功能我并不使用，它们被真正的数据库高手所采用。许多开发者不利用这些功能，从而无法实现他们的想法。

例如，如果你正需要做多次的更新/插入/删除操作，你可以利用transaction。比如，你要在你的用户列表中插入一个新的用户，同时在另一个表中，要插入一行，而且也要更新别处的一个标志。假如这样，如果第一次插入成功，而第二次失败，你怎么办？在Postgres中，你可以回退全部操作，而观察出错的缘由。

而在MySQL中，出错时你会非常紧张，除非你安排了一些逻辑可以控制这个局面。在实际应用中，第一个问题不会出错，除非你是一个糟糕的程序员。而如果第二个问题出错，那么这个结果并不非常严重。（除非这是一个不允许出错的而冒险的程序，比如会计、银行业、评论界的应用程序。）

无论如何，在Postgres7.0+中现在已经支持了外部关键字，那就意味着当你插入一行，数据库会做一些公正而合理的校验检察。同样，如果你要删除当前表一行，而有另一个表依赖于当前表，数据库则不会让你操作。我喜欢这个想法并且能预见如何利用这个功能重写整个网站。

Triggers 和Views是能够在Postgres中，而不是在MySQL中使用的有趣而有用的工具。尽管我都没有使用过，但我可以想象如果我重新设计SourceForge时将如何地频繁利用views。

局限性

Postgres的主要局限性并不是它的性能（因为大多数网站将永远不会陷入这个问题）。但是由于编码硬化的限制，像每行8k的限制（日期会回到以前的时期）。当我使用Postgres设计Geocrawler.com，我不得不将大的e-mail分成每8k一块以绕过这个僵硬的限制。在默认情况下，Postgres被编译成只支持32个连接，这是不足以用来作高流量网站应用的，特别是考虑到Postgres生成每页的速度要比MySQL慢。

另一个限制可警惕许多PHP的用户：Postgres没有与MySQL的mysql_insertid()等价的函数调用。如果在MySQL的数据库中插入一行数据，MySQL将返回这行主关键字的ID。而在Postgres中完成这样一个操作需要绕许多圈子，这是一件非常头痛的事，而且如果用的多可能会降低效率。

稳定性

Postgres在长时间运行的情况下运行流畅而不出错。我的Postgres 6.5.3装在又老又累的PowerMac 8500上，无错运行已经有90天了；而且每天生成50-100,000页。当Postgres装入运行，不会退出，而在压力下不需要ghost。

Postgres有一个问题是当你确实发生问题时，一般它就真坏了。在一些旧的Postgres6.4.x中，我还发现了更加严重的问题：许多重复而相同的数值被插入到同一个主关键字中（这是不允许在任何情况下出现的） Postgres还有另一问题就是会出现令人紧张的不完整的索引和表，你不能略过或摆脱它。我在Postgres7中没有再发现过它，但我没有对其全面使用，所以无法知道更多。

结论

这次测试几乎证实了我所知道的：两个数据库系统都可以为大多数网站非常好地服务。它们与桌面数据库，像FileMaker和MS Access相比，非常明显地快。Postgres 和 MySQL都是自由而免费的，而且有积极的开发团体所支持。

如果要在两者间选择一个，你首先需要明白你面临的限制并且知道你是否需要Postgres的transaction的支持或者MySQL的large-text-area支持。你可能都要，这种情况下，你只有等到将来的某一天，两者推出新的稳定发布版。

需要提出的一件非常有趣的事是：这两个数据库似乎会在某处重合，就是当MySQL具有transaction的支持并且慢慢加入一些新的功能如：subselect，而Postgres在执行性能和稳定性上有所改进时。

最后，作为数据库高手选择，Postgres应当非常灵活。外部关键字，views,subselects,和transactions都非常地棒--如果你需要并且应用它们。如果你不需要或不使用这些功能，你最好使用MySQL，而利用它优越的性能。

作者: JohnBull 时间: 2003-01-30 23:39
标题: [转贴]已经过了两年了，不知道结论还正确吗？
“外部关键字”我估计是（Foreign key），应该翻译成“外键约束”。
PostgreSQL并没有按SQL标准实现外建约束，而是通过其特有的规则系统来实现的。

作者: ecloud 时间: 2003-02-08 01:06
标题: [转贴]已经过了两年了，不知道结论还正确吗？
7.2以后好像支持外键了？

作者: redfox 时间: 2003-02-09 21:06
标题: [转贴]已经过了两年了，不知道结论还正确吗？
一句老话：尺有所短，寸有所长~

作者: shixl 时间: 2003-03-04 16:58
标题: [转贴]已经过了两年了，不知道结论还正确吗？
当创建一个引用关系时候，会在引用表上自动创建一个触发器，当向这个引用表插入修改数据时候，由这个触发器去查询被引用表。以此来知道是否违反了约束。

/*-------------------------------------------------------------------------
*
* trigger.c
*       PostgreSQL TRIGGERs support code.
*
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
*       $Header: /cvsroot/pgsql-server/src/backend/commands/trigger.c,v 1.136 2002/10/21 19:55:49 tgl Exp $
*
*-------------------------------------------------------------------------
*/
#include "postgres.h"

#include "access/genam.h"
#include "access/heapam.h"
#include "catalog/catalog.h"
#include "catalog/catname.h"
#include "catalog/dependency.h"
#include "catalog/indexing.h"
#include "catalog/namespace.h"
#include "catalog/pg_language.h"
#include "catalog/pg_proc.h"
#include "catalog/pg_trigger.h"
#include "catalog/pg_type.h"
#include "commands/defrem.h"
#include "commands/trigger.h"
#include "executor/executor.h"
#include "miscadmin.h"
#include "nodes/makefuncs.h"
#include "parser/parse_func.h"
#include "utils/acl.h"
#include "utils/builtins.h"
#include "utils/fmgroids.h"
#include "utils/inval.h"
#include "utils/lsyscache.h"
#include "utils/syscache.h"

static void InsertTrigger(TriggerDesc *trigdesc, Trigger *trigger, int indx);
static HeapTuple GetTupleForTrigger(EState *estate,
                                 ResultRelInfo *relinfo,
                                 ItemPointer tid,
                                 TupleTableSlot **newSlot);
static HeapTuple ExecCallTriggerFunc(TriggerData *trigdata,
                                    FmgrInfo *finfo,
                                    MemoryContext per_tuple_context);
static void DeferredTriggerSaveEvent(ResultRelInfo *relinfo, int event,
                                             HeapTuple oldtup, HeapTuple newtup);
static void DeferredTriggerExecute(DeferredTriggerEvent event, int itemno,
                                       Relation rel, TriggerDesc *trigdesc, FmgrInfo *finfo,
                                       MemoryContext per_tuple_context);

/*
* Create a trigger.  Returns the OID of the created trigger.
*
* forConstraint, if true, says that this trigger is being created to
* implement a constraint.    The caller will then be expected to make
* a pg_depend entry linking the trigger to that constraint (and thereby
* to the owning relation(s)).
*/

/* 创建触发器
第一个参数是语法树结构
第二个是是否是约束触发器
*/

Oid
CreateTrigger(CreateTrigStmt *stmt, bool forConstraint)
{
      int16          tgtype;
      int16          tgattr[FUNC_MAX_ARGS];
      Datum          values[Natts_pg_trigger];
      char          nulls[Natts_pg_trigger];
      Relation       rel;
      AclResult    aclresult;
      Relation       tgrel;
      SysScanDesc tgscan;
      ScanKeyData key;
      Relation       pgrel;
      HeapTuple    tuple;
      Oid                   fargtypes[FUNC_MAX_ARGS];
      Oid                   funcoid;
      Oid                   funcrettype;
      Oid                   trigoid;
      int                   found = 0;
      int                   i;
      char          constrtrigname[NAMEDATALEN];
      char    *trigname;
      char    *constrname;
      Oid                   constrrelid = InvalidOid;
      ObjectAddress myself,
                              referenced;

      rel = heap_openrv(stmt->;relation, AccessExclusiveLock);

      if (stmt->;constrrel != NULL)
            constrrelid = RangeVarGetRelid(stmt->;constrrel, false);

      /*判断是否一个约束触发器 */
      else if (stmt->;isconstraint)
      {
            /*
               * If this trigger is a constraint (and a foreign key one)
               * then we really need a constrrelid.  Since we don't have one,
               * we'll try to generate one from the argument information.
               *
               * This is really just a workaround for a long-ago pg_dump bug
               * that omitted the FROM clause in dumped CREATE CONSTRAINT TRIGGER
               * commands.  We don't want to bomb out completely here if we can't
               * determine the correct relation, because that would prevent loading
               * the dump file.  Instead, NOTICE here and ERROR in the trigger.
               */
            bool needconstrrelid = false;
            void *elem = NULL;

            /* 那么起一个特定规则的名字 */
            if (strncmp(strVal(llast(stmt->;funcname)), "RI_FKey_check_", 14) == 0)
            {
                     /* A trigger on FK table. */
                     needconstrrelid = true;
                     if (length(stmt->;args) >; RI_PK_RELNAME_ARGNO)
                              elem = nth(RI_PK_RELNAME_ARGNO, stmt->;args);
            }
            else if (strncmp(strVal(llast(stmt->;funcname)), "RI_FKey_",

== 0)
            {
                     /* A trigger on PK table. */
                     needconstrrelid = true;
                     if (length(stmt->;args) >; RI_FK_RELNAME_ARGNO)
                              elem = nth(RI_FK_RELNAME_ARGNO, stmt->;args);
            }
            if (elem != NULL)
            {
                     RangeVar *rel = makeRangeVar(NULL, strVal(elem));

                     constrrelid = RangeVarGetRelid(rel, true);
            }
            if (needconstrrelid && constrrelid == InvalidOid)
                     elog(NOTICE, "Unable to find table for constraint \"%s\"",
                              stmt->;trigname);
      }

      if (rel->;rd_rel->;relkind != RELKIND_RELATION)
            elog(ERROR, "CreateTrigger: relation \"%s\" is not a table",
                     stmt->;relation->;relname);

      if (!allowSystemTableMods && IsSystemRelation(rel))
            elog(ERROR, "CreateTrigger: can't create trigger for system relation %s",
                     stmt->;relation->;relname);

      /* permission checks */

      if (stmt->;isconstraint)
      {
            /* foreign key constraint trigger */
               /* 进行权限检查 */

            aclresult = pg_class_aclcheck(RelationGetRelid(rel), GetUserId(), ACL_REFERENCES);
            if (aclresult != ACLCHECK_OK)
                     aclcheck_error(aclresult, RelationGetRelationName(rel));
            if (constrrelid != InvalidOid)
            {
                     aclresult = pg_class_aclcheck(constrrelid, GetUserId(), ACL_REFERENCES);
                     if (aclresult != ACLCHECK_OK)
                              aclcheck_error(aclresult, get_rel_name(constrrelid));
            }
      }
      else
      {
            /* real trigger */
            aclresult = pg_class_aclcheck(RelationGetRelid(rel), GetUserId(), ACL_TRIGGER);
            if (aclresult != ACLCHECK_OK)
                     aclcheck_error(aclresult, RelationGetRelationName(rel));
      }

作者: netkiller 时间: 2003-03-08 14:13
标题: [转贴]已经过了两年了，不知道结论还正确吗？
这遍文章没意义。
PostgreSQL vs Mysql不是一个档次上的东西。比什么。。
如同Oracle 与 Mysql对比。。
PostgreSQL 是关系型数据库的鼻祖。是Infomix前身。它与Ms sql server,sybase，infomix 是一个档次。
mysql与access ,foxbase一个档次。。
为什么这么说。
mysql 与 foxbase的功能差不多。。只提供数据的读，存。如：视图，触发器，过程，序列。subselect 。外键。。。。它都不支持。
只支持select ,update,insert,drop,delete....... 这些功能Access都有。且Access还支持外键，视图。比 mysql功能多。

作者: 夜猫子 时间: 2003-03-08 15:02
标题: [转贴]已经过了两年了，不知道结论还正确吗？
虽然我很高兴听到有人这么说（窃喜），不过因为这两个东西的比较是很多初学者感兴趣的，所以干脆就收一篇放在这里。

作者: eapass 时间: 2003-03-11 02:47
标题: [转贴]已经过了两年了，不知道结论还正确吗？

原帖由 "netkiller" 发表：
这遍文章没意义。
PostgreSQL vs Mysql不是一个档次上的东西。比什么。。
如同Oracle 与 Mysql对比。。
PostgreSQL 是关系型数据库的鼻祖。是Infomix前身。它与Ms sql server,sybase，infomix 是一个档次。
mysq..........

谢谢,你的回复使我对PostgreSQL vs Mysql有点感觉了,谢谢.

作者: redfox 时间: 2003-03-13 00:46
标题: [转贴]已经过了两年了，不知道结论还正确吗？
这不是档次的问题，是定位的问题。

好比微软的word和记事本，word的功能很强，不过大多数情况我们还是在用记事本，why？简单的web应用，我去用视图，触发器，过程干吗？

要知道：当我们在获得了应用要求的功能后，速度和易用性才是第一位的。

PostgreSQL支持的太全了，我只会在复杂，并且同步性要求很高的的BS结构的项目里用它，或者只是在几个特定的模块中。

作者: 红袖添香 时间: 2003-03-18 08:13
标题: [转贴]已经过了两年了，不知道结论还正确吗？

原帖由 "redfox" 发表：
这不是档次的问题，是定位的问题。

好比微软的word和记事本，word的功能很强，不过大多数情况我们还是在用记事本，why？简单的web应用，我去用视图，触发器，过程干吗？

要知道：当我们在获得了应用要求的功?.........

很有道理的说~~

作者: netkiller 时间: 2003-03-18 22:39
标题: [转贴]已经过了两年了，不知道结论还正确吗？
楼上朋友。首先你真正用过事务处理的数据器吗？
你没用过，自然不知，外键，触发器，视图.....有多方便.

drop table taba;
create table taba(
id integer,
name varchar(50)
);
insert into taba values(1,'chen');
insert into taba values(2,'chen');
insert into taba values(3,'chen');
insert into taba values(4,'chen');
insert into taba values(5,'chen');
insert into taba values(6,'chen');
insert into taba values(7,'chen');
select * from taba;

drop table tabb;
create table tabb(
id integer,
name varchar(50)
);
insert into tabb values(1,'chen');
insert into tabb values(2,'chen');
insert into tabb values(3,'chen');
insert into tabb values(4,'chen');
insert into tabb values(5,'chen');
insert into tabb values(6,'chen');
insert into tabb values(7,'chen');
select * from tabb;

drop function delete_tab ();
CREATE FUNCTION delete_tab () RETURNS opaque AS '
--  DECLARE
  BEGIN
Delete from tabb where id = OLD.id;
RETURN NEW;
  END;
' LANGUAGE 'plpgsql';

drop TRIGGER delete_tri on taba;
CREATE TRIGGER delete_tri
   BEFORE Delete
   ON taba FOR EACH ROW
   EXECUTE PROCEDURE delete_tab ();

delete from taba where id = 2;
select * from tabb;

当表taba 中删除一条数据中。tabb中的数据同时被删除。
如果是MYSQL你得在程序中用两条SQL实现。
delete from taba where id = 2;
delete from tabb where id = 2;

view 可以省去你在读表时烦琐。
pgsql:select * from view where id =1
mysq:select  t1.id,t2.uid,t3.name,t4.pass,t5.email from t1,t2,t3,t4,t5 where t1.id=1 and t2.id=1 and

t3.id =1 and t4.id =1 and t5.id =1

过程，函数。
adduse(integer,integer)
begin
insert into user values($1,$2);
......
end;
exec adduser('user1','passwd');

事务
begin
step 1
step 2
...
step 10
commit;
如果任何一步出错。事务被取消，即。去银行取￥。
1插卡
2密码
4取多少￥￥￥
5在帐号里扣除￥
6出钱
7退卡
如果没有事务处理。5出错。你的￥没了。6没出来￥。7退卡。你再一看。卡里原5000￥现在成了2000￥。银行不诚认。你自己哭吧。
这种环境MySQL不行。

外键。没有外键参考。插入，删除的数据可能不一至。

不多说了。。自己想想吧。

作者: 红袖添香 时间: 2003-03-18 22:53
标题: [转贴]已经过了两年了，不知道结论还正确吗？
...

我想 redfox 老大说得很清楚了，对于简单网页应用，他不需要；对于复杂、并且同步性要求很高的的BS结构中会用到。

就象 ChinaUnix.net 偶而出现 phpBB: Critical Error 虽然很烦人，但不会象银行帐户问题那么严重。再极端一点，Oracle 很强，但是我需不需要用它来处理我的通讯录呢？Oh no, thanks! 我想一个 EXCEL 或是 Gnumeric 就能满足我的要求了。

我认为，他的说法很有道理 —— 不是档次问题而是定位问题。

作者: jxbbs 时间: 2003-03-19 00:04
提示: 作者被禁止或删除内容自动屏蔽

作者: redfox 时间: 2003-03-19 00:05
标题: [转贴]已经过了两年了，不知道结论还正确吗？
其实很多事情都是这样。
我们总是在寻找所谓“最好的”，倒还不如好好考虑一下什么才是“最合适的”。

作者: wolfop 时间: 2003-03-19 21:28
标题: [转贴]已经过了两年了，不知道结论还正确吗？
说实在，MYSQL已经支持外件了，至于触发器，我们再生产系统中的INFORMIX都不用这个东西。

作者: wangrujun 时间: 2003-04-01 09:09
标题: [转贴]已经过了两年了，不知道结论还正确吗？
[quote]原帖由 "wolfop"]说实在，MYSQL已经支持外件了，至于触发器，我们再生产系统中的INFORMIX都不用这个东西。[/quote 发表：

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

作者: netkiller 时间: 2003-04-01 12:00
标题: [转贴]已经过了两年了，不知道结论还正确吗？
回楼上。。
因为你是程序员，不是DBA。。
我认为你对数据的认识，比对FOXBASE认识多不了多少。。
目前国内的项目人员。都对数据库认识不足。这些项目人员，之前都是程序员。。。干到30岁做就项目经理。。
这些人，给它Oracle。他的用法与MySQL一样，外建VIEW全不用。
只用select,insert ,update OK了，就可以做项目了。CRM，ERP，OA，。。。。。。

我在深圳干了三年，换了不少公司。大到几百人，小到三五人。。都一样很少公司有专业的DBA。

作者: gadfly 时间: 2003-04-01 12:25
标题: [转贴]已经过了两年了，不知道结论还正确吗？

原帖由 "netkiller" 发表：

因为你是程序员，不是DBA。。
我认为你对数据的认识，比对FOXBASE认识多不了多少。。
目前国内的项目人员。都对数据库认识不足。这些项目人员，之前都是程序员。。。干到30岁做就项目经理。。
这些人，给它Oracle。他的用法与MySQL一样，外建VIEW全不用。
只用select,insert ,update OK了，就可以做项目了。CRM，ERP，OA，。。。。。。

我在深圳干了三年，换了不少公司。大到几百人，小到三五人。。都一样很少公司有专业的DBA。

同意你的观点，这也是国内项目开发流程不完善和不规范造成的，很多人都是身兼多职，虽然能锻炼能力，但是也造成角色的非专业化.

不过是否通过触发器还是通过应用来维护表数据间的逻辑关系，我觉得并不是绝对的,各有各的优缺点.

作者: wolfop 时间: 2003-04-01 17:09
标题: [转贴]已经过了两年了，不知道结论还正确吗？

原帖由 "wangrujun" 发表：

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

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

作者: wolfop 时间: 2003-04-01 17:17
标题: [转贴]已经过了两年了，不知道结论还正确吗？

原帖由 "netkiller" 发表：
回楼上。。
因为你是程序员，不是DBA。。
我认为你对数据的认识，比对FOXBASE认识多不了多少。。
目前国内的项目人员。都对数据库认识不足。这些项目人员，之前都是程序员。。。干到30岁做就项目经理。。
这些人..........

呵呵，只能说你刚道比只会用FOXBASE的人层次高一点。知道触发器，VIEW的方便性，接触过多大的系统，而且是资金有限的系统。用VIEW 用触发器如何，我知道的系统，两台满配置15K，触发器、VIEW都用，可是系统的数据量和业务量都比我们用4台PC Server的要少，怎么了，崩溃的频繁程度还有反应速度等指标都比我不用触发器的要慢。一个DBMS＋应用的设计，不是看是否用VIEW、是否用外键、是否用触发器衡量的，尤其对我这种甲方的人来说，我只关心系统的稳定性、反应时间和处理能力。
因此，不论黑猫白猫，抓道耗子就是好猫。

作者: netkiller 时间: 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并而每次都要与数据连接一次，关闭一次。

作者: netkiller 时间: 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 = 某年，计时，天那足足有两三个小时才处理完。

作者: wolfop 时间: 2003-04-01 22:52
标题: [转贴]已经过了两年了，不知道结论还正确吗？
[quote]原帖由 "netkiller" 发表：
呀！才发现。都到第二页了。我发完没看到结果。就以为没发出去。
所以发了很多重负的。。不家原量。。
不用触发器的生产系统，或者你的系统太小，或者你的构架不好。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

作者: wolfop 时间: 2003-04-01 22:54
标题: [转贴]已经过了两年了，不知道结论还正确吗？
[quote]原帖由 "netkiller" 发表：
回楼上。。
你是程序员吗？还是DBA？
不知你对数据库认识有多少。如果你真的用过Informix，你就不会再用MYSQL了。
有些环境MYSQL是不行。你是不是只做一些B/S，web页一类的开发。。
不知你接触过。银行，超市

作者: netkiller 时间: 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上找找。。看看谁第一，谁第二。。。
论据是不是来自造谣么？我不知。。测试方都是权威公司。搞的。。

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

作者: wangrujun 时间: 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的数量

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

作者: netkiller 时间: 2003-04-02 09:51
标题: [转贴]已经过了两年了，不知道结论还正确吗？
re: wangrujun
同意

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

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

作者: wolfop 时间: 2003-04-02 11:56
标题: [转贴]已经过了两年了，不知道结论还正确吗？
[quote]原帖由 "wangrujun" 发表：

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

作者: gadfly 时间: 2003-04-02 15:26
标题: [转贴]已经过了两年了，不知道结论还正确吗？

原帖由 "netkiller" 发表：

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

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

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

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

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

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

作者: netkiller 时间: 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端处理我不支持。。。

作者: gadfly 时间: 2003-04-02 18:01
标题: [转贴]已经过了两年了，不知道结论还正确吗？
这个在N tier中，分层和设计的思想都是相同的，与框架无关。

虽然这篇文章是以.net举例的，但是用在j2ee中是一样的。

N tier中，数据逻辑和业务逻辑当然是在服务端实现的。你这个client指针对
数据库而言吧?

我的感觉是业务和数据逻辑可能是多变的，如果太依赖于存储过程，并不利于组件的维护，尤其是对于支持多数据库的产品。

至于上面说的性能问题，我想这种情况也是存在的，这类耗CPU资源的本来可以通过应用服务器来解决，但是用存储过程却会占用有限的数据库服务器的资源。

作者: spirit 时间: 2005-05-09 22:57
标题: [转贴]已经过了两年了，不知道结论还正确吗？
一群sb

作者: ecloud 时间: 2005-07-06 15:08
标题: [转贴]已经过了两年了，不知道结论还正确吗？
在标准的J2EE体系中，所有的商业逻辑必须封装成EJB或者助手类，也可以把某个数据结构（数据库中的一张表或者一个视图）抽象成实体Bean，因此在这种严格的OO设计中，是要尽量避免在数据库中处理任何逻辑的

至于C/S结构的设计来说，在DBM中封装一些商业逻辑是有益的

作者: ecloud 时间: 2005-07-06 15:11
标题: [转贴]已经过了两年了，不知道结论还正确吗？
另外补充一下，在中国，DBA不要妄想从Programer那里拿到商业逻辑代码的维护权
因此，商业逻辑不可能封装在DBM里

作者: littleboywj 时间: 2005-07-08 23:45
标题: [转贴]已经过了两年了，不知道结论还正确吗？
[quote]原帖由 "spirit"]一群sb[/quote 发表：

那不知你是个什么DX??!!!!!

作者: dragon76 时间: 2005-07-14 10:46
标题: [转贴]已经过了两年了，不知道结论还正确吗？
[quote]原帖由 "spirit"]一群sb[/quote 发表：

像你这样的DX,都不配叫人,还是有多远的滚多远的好

作者: snowpy 时间: 2005-07-16 12:51
标题: [转贴]已经过了两年了，不知道结论还正确吗？
真的是无知者无畏, 事务处理和外健/触发器之类的有什么联系?
你先把什么是ROLLBACK和ROLLFORWARD搞懂再说吧

原帖由 "netkiller" 发表：
楼上朋友。首先你真正用过事务处理的数据器吗？
你没用过，自然不知，外键，触发器，视图.....有多方便.

drop table taba;
create table taba(
id integer,
name varchar(50)
);
insert into taba values(1..........

作者: snowpy 时间: 2005-07-16 12:57
标题: [转贴]已经过了两年了，不知道结论还正确吗？
越说越离谱, 什么每次MYSQL操作要与数据库连接和关闭一次???你要是懂连接池和数据库接口是什么概念就不会说出这么SB的东西.
银行和金融不用MYSQL是有他们特殊的原因, 但是并不等于MYSQL就是垃圾,
两年前的MYSQL就已经有基于IMDB的版本了, 把MYSQL和ACCESS列为一类的人我还算是第一次见识, 居然还是版主...希望已经是两年后的你有所长进

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

不知你接触过。银行，超市?.........

作者: snowpy 时间: 2005-07-16 13:07
标题: [转贴]已经过了两年了，不知道结论还正确吗？
你真的要比较的话, 我出国前在国内某电信公司工作, 一般做的项目都有20/30台SUN E4500/10000的服务器, 计费跑ORACLE,某些小项目跑MYSQL, 每天单单北京节点就有1300万的计费记录生成插入ORACLE(我写的oci+pro*c程序+schema+trigger+plsql procedure)
现在在北美某大型IT公司工作, 现在做的项目200台SUN服务器和几十台POSTGRESQL.
多年UNIX C++分布式系统开发经验, ORACLE 9I DBA管理员证书.

就我的经验觉得你实在不适合做版主的职位. POSTGRE确实不错, 但是并没有像你说的比MYSQL强那么多的地步, 每种产品都有自己的定位和市场.
希望你以后不要再误导初学者.

原帖由 "netkiller" 发表：
回楼上。to wolfop

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

些贴之前：我看到的是你第一页最后一..........

作者: cellar 时间: 2005-07-19 09:32
标题: [转贴]已经过了两年了，不知道结论还正确吗？
汗，长见识啊......真是强中自有强中手啊，在CU谁也不要托大...我的签名档有我的联系方法，很想和各位学习一下有关应用分布的问题，请高人能指教一下，谢谢

作者: jsean 时间: 2005-08-06 22:24
标题: [转贴]已经过了两年了，不知道结论还正确吗？
靠！啥人都有。

作者: tmdxy 时间: 2005-11-07 03:00
除了一些特殊行业，和非常大型的应用，其他的，用什么数据库不是很重要（access这种例外）。
更关键的，是看你程序怎么写，数据库怎么设计。
我没做过你们说的那种大型开发，我的观点只代表我目前的认知度。

我以前用mysql和mssql，正在迁移到pgsql，没别的，图稳定和方便。
下周去机房换服务器操作系统，祝我顺利吧，呵呵

作者: n_nf 时间: 2005-12-31 13:11
我是来学习的。。。

作者: fistee 时间: 2006-06-09 14:33
标题: PostgreSQL和MySQL两者定位不同
两者定位不同
PostgreSQL是一个研究性的产品，而且到现在还是，所以里面的限制和规则比较多，比较严谨，研究性的功能比较多，很多新的数据库特性都是始于这个数据库，目前国内很多数据库核心研究和国产数据库都是以这个系统为基础的。
MySQL是一个开源的用于轻量级应用的系统。没有很多的使用经验。

[ 本帖最后由 fistee 于 2006-6-9 14:46 编辑 ]

作者: tong0245 时间: 2006-06-11 21:38

原帖由 fistee 于 2006-6-9 14:33 发表
两者定位不同
PostgreSQL是一个研究性的产品，而且到现在还是，所以里面的限制和规则比较多，比较严谨，研究性的功能比较多，很多新的数据库特性都是始于这个数据库，目前国内很多数据库核心研究和国产数据库都是 ...

你这个说的没有什么意义这个帖子够老了
另外我发现 netkiller关系关闭连接的那个部分太搞笑了不过这都是多年前的了哈哈。
snowpy好久不来了阿

作者: joint 时间: 2006-06-11 22:26
没啥可争议, 啥方法都可以, 只要服务器能跑的过来.

oracle也用过一阵, mssql也用过一阵, 目前用pgsql, 我们的规矩是不允许在procedure里面使用复杂逻辑, 也没用过啥触发器之类的, 要不就把服务器给整垮了, 商业逻辑封装在程序里, N--TIER的结构

[ 本帖最后由 joint 于 2006-6-11 22:27 编辑 ]

作者: wordlotus 时间: 2006-06-12 19:25
可以参考一下了

作者: tong0245 时间: 2006-06-14 16:24

原帖由 joint 于 2006-6-11 22:26 发表
没啥可争议, 啥方法都可以, 只要服务器能跑的过来.

oracle也用过一阵, mssql也用过一阵, 目前用pgsql, 我们的规矩是不允许在procedure里面使用复杂逻辑, 也没用过啥触发器之类的, 要不就把服务器给整垮了, 商业 ...

这个东西要看应用的类型和需要确定

作者: newbuding 时间: 2006-06-15 09:26

原帖由 joint 于 2006-6-11 22:26 发表
没啥可争议, 啥方法都可以, 只要服务器能跑的过来.

oracle也用过一阵, mssql也用过一阵, 目前用pgsql, 我们的规矩是不允许在procedure里面使用复杂逻辑, 也没用过啥触发器之类的, 要不就把服务器给整垮了, 商业 ...

触发器对数据库速度比较大么？

作者: joint 时间: 2006-06-15 09:49

原帖由 newbuding 于 2006-6-15 09:26 发表

触发器对数据库速度比较大么？

不知道, 没比较过, 我们原先做的数据流量很大, 所以不适合在服务器端做太多工作, 大部分存储过程只做4个基本操作

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)