sql递归算法

1. 菜鸟 Sql语句求解 最好把每一句都解释 一下 不胜感激、、

指定数据库
USE [Student]
GO
以下为系统自动生成的，一般没什么用，除非你改变了系统的环境
/****** Object: Table [dbo].[C] Script Date: 04/19/2011 21:25:17 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

建立数据表
CREATE TABLE [dbo].[C](
指定字段名称，类型，长度，是否允许为空
[Cno] [nchar](10) NOT NULL,
[Cname] [nchar](20) NULL,
[Credit] [float] NULL,
[Property] [nchar](14) NULL,
设置主键
CONSTRAINT [PK_C] PRIMARY KEY CLUSTERED
(
[Cno] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
/****** Object: Check [CK_C] Script Date: 04/19/2011 21:25:17 ******/
增加检查CK_C，并且作用于刚才新建的表
ALTER TABLE [dbo].[C] WITH CHECK ADD CONSTRAINT [CK_C] CHECK (([Credit]>(0)))
GO
ALTER TABLE [dbo].[C] CHECK CONSTRAINT [CK_C]
GO

靠记忆写的，你对应查一下帮助就明白了

2. sql 怎么递归查询的方法：

1．创建测试表，createtabletest＿connect（idnumber，p＿idnumber）；

3. 急需SQL server 2005的介绍

前言

SQL Server 2000从上市到现在已经整整五个年头。现在望眼欲穿的SQL Server 2005 终于发布了。五年磨一剑，SQLServer 2005 将是微软具有里程碑性质的企业级数据库产品。本文从用户关心的技术要点出发比较和讨论SQL Server 2005 相对它的前版本SQL Server 2000所做的重大改进或新增功能，介绍了SQL Server 2005 中最值得你为之升级的10 个理由。无论你是想了解或学习SQL Server 2005，还是正在评估或考虑升级到SQL Server 2005，本文都将对您有很好的参考作用。

升级理由一：数据分区
只有到了2005 版本SQL Server才拥有了真正的表和索引数据分区技术。这个技术一下子使SQL Server数据库从“青壮年”成长为成熟的企业级数据库产品，是一个里程碑性质的标志。数据分区技术极大加强了表的可伸缩性和可管理性，使得 SQLServer 处理海量数据的能力有了质的飞跃，是我认为最值得升级的一个理由。

数据库随着硬件和业务的发展变得越来越大。五年前大多数数据库还不过是十几个GB大小，很少超过TB级别的。现在几百个GB大小的数据库系统随处可见。如果没有数据分区技术而想对大数据库进行高效管理是很困难的。SQL Server 2005以前版本的一个问题是随着时间的推移数据库越来越大，备份需要的空间越来越多，如何处理数据库中的历史数据是很棘手的事情。有些客户可能会使用 DELETE语句定期定量删除大表中的历史记录，如在每个周末备份数据库后删除一个星期以前的所有数据。但是如果表有上千万行十几个GB 大小，那么使用DELETE语句删除数据库中上万行或高达20%数据的话，其性能很差。如果是在7 × 24小时运行的联机系统做这样的数据维护操作那么还会引起比较严重的阻塞问题。另外有些客户针对这个问题直接在方案设计上下功夫，比如按照年份月份星期设计表，然后定期把一些过时的历史数据表（注意是“表”）备份并DROP掉，使得数据库大小以及系统性能都能保持相对稳定。但是这种方法有一个弊端，即应用程序必须做相应的配合根据不同的时间访问对应的表，增加了数据库管理以及数据库访问逻辑的复杂性。

大表还容易带来性能问题。你也许会想到SQL Server 2000中的本地分区视图或分布式分区视图技术。是的，SQL Server2000 中的确已经有分区视图的概念，从SQL Server 7.0开始就有了。可惜分区视图的一个令人讨厌的地方是其管理、设计和开发比较困难，特别是分布式分区视图。如如何更新分布式视图就是个难题。所以尽管一个设计良好的分区视图系统会有很不错的性能改善，却因为繁琐的配置，管理和开发使得其没有在实际中得到充分应用。

现在，SQL Server 2005 引入了真正的数据水平分区技术，上面讨论的数据库增长问题和性能问题就迎刃而解。这个进步绝对不是一小步。数据库的大小不再是个问题。你可以根据字段值的范围将表和索引划分为多个分区从而可以轻松管理一个几个TB大小的数据库系统。无论数据如何增长，你都可以使用分区技术使得数据库大小保持相对稳定。其中特别值得称赞的地方是SQL Server 2005 中分区的管理和使用非常简单。分区的删除，添加，拆分、合并和移动，以及分区的数据装载等管理都非常容易。你可以对单独的分区进行维护而不是整个表。如果你需要大量装载数据，那么你可以先把数据并行的装入到一个新分区当中，建立索引，然后把该分区合并到当前分区中来。这个动作需要的时间极短。如果你需要删除历史数据，假设你已经设计好了历史数据分区，那么你仅仅需要把该分区移除即可，几乎可以一瞬间完成。分区也使得大型表的并发访问性能得到改善，特别是有多个CPU的数据库系统。那些需要交叉访问大量数据的查询将从分区技术中获益不少。

升级理由二：可编程性
CLR 集成

SQL Server 2005的可编程性是值得升级的第二个重要理由。从来没有哪一个版本能像SQL Server 2005 这样带来这么多编程方面的变革。说老实话，在我知道的瞬间我是惊呆了。有些变化是革命性的。如CLR（Common Language Runtime,公共语言运行时）集成。就先说说CLR集成。CLR集成是指你可以使用任何一种.NET 语言编写SQL Server 2005 的存储过程，触发器，函数，自定义类型，甚至是自定义的聚合函数。估计不少数据库软件开发商会为这个功能欢呼雀跃。想想以前的扩展存储过程，编程非常不容易。代码中一不小心就会引起内存泄漏。而且由于扩展存储过程运行在SQL Server 的进程空间中，不好的代码容易引起访问违规（Access Violation）导致SQLServer 异常。

现在有了CLR 集成，你可以轻松利用.NET语言的优势如其面向对象的封装、继承和多态特性，编写出那些需要对数据进行复杂数值计算或逻辑的代码，如字符串处理，数据加密算法，XML数据操作等等。由于CLR代码宿于SQL Server进程，你可以非常容易访问数据库中的数据。有了CLR，你不再局限于T-SQL，你现在立即拥有了.NET 框架类库提供的各种各样的类和例程，以及.NET语言提供的一致的编程模型，如错误处理。展现在你面前的是一个可以无限扩展的编程空间。你现在需要的仅仅是考虑什么时候使用T-SQL 语言，什么时候使用CLR。我猜测那些SQL Server软件开发商几乎会立即升级到SQLServer 2005 享受数据库编程的便捷。

T-SQL 语言增强
SQL Server 2005 中的T-SQL语言有了非常大的改进。其中笔者最为称道的是现在可以使用和C++或C#类似的TRYCATCH结构对T-SQL 进行错误处理了，大大简化了T-SQL错误处理编程。SQL Server 2005以前的版本通过设置@@error变量表示最后的T-SQL 语句执行成功与否。为避免@@error变量被新执行的语句重置，你必须为每一条可能出错的TSQL语句后面立即检查或保存@@error变量的值，并使用相应的G O T O 语句进行跳转，使得代码变得复杂难读。现在SQLServer 2005 有了TRY-CATCH结构你只需要把相关的一组语句放在TRY块里面即可。如果TRY块里面任何语句发生错误，就会执行相应的CATCH 块。你甚至可以使用嵌套的TRYCATCH来实现复杂错误处理流程。估计很多T-SQL语言使用者可能就为了这个TRY-CATCH 结构而迫不及待地升级到SQL Server 2005。

除了传统的DML（INSERT/UPDATE/DELETE）触发器，SQL Server 2005 现在也可以对DDL 语言（CREATE、ALTER或DROP 开头的语句）创建触发器了。这对于那些需要对DDL语言执行管理任务如审核以及规范数据库操作的用户特别有用。以前很多客户问我如何跟踪或避免表的删除操作，现在终于有了答案。你可以简单建立一个针对DROP 语句的触发器然后在触发器里面ROLLBACK 事务就可以回滚DROP 动作了。

SQL Server 2005 T-SQL 中还有一个很酷的OUTPUT 子句。现在你不费吹灰之力就可以获得INSERT 、UPDATE 或DELETE语句所影响的每行的信息。对于在INSERT或UPDATE操作之后需要检索标识列或计算列的值的场合OUTPUT子句非常有用。如获得数据INSERT 后该行的Identity的值，产生一些唯一流水号，验证刚刚插入的数据等等。一个有趣的例子是Identity值的取得。在SQL Server 2000 中你可以在INSERT 语句后立即调用IDENT_CURRENT()或SCOPE_IDENTITY()函数来得到INSERT 语句的Identity。现在你仅仅需要在INSERT 语句中指定output子句就直接得到刚刚插入的Identity值，实在太简单了，不是吗？

SQL Server 2005 中T-SQL 语言新增或加强的功能还有很多。如SQL Server 2005 新增加了一类排名函数RANK/DENSE_RANK/NTILE/ROW_NUMBER，轻松解决了开发者要求返回数据行中提供行号等排序功能。新增的 P I V O T 和UNPIVOT运算符使得对结果集进行行和列的旋转变换十分简单。公用表表达式(CTE)解决了T-SQL语言的递归查询问题，而使用 OPENROWSET 语句现在可以直接从文件里面执行大容量操作了。我觉得每一个改进都是那么有针对性，以至于使我相信这些T-SQL增强必定是SQL Server开发小组真正聆听数据库开发者心声的结果。

升级理由三：安全
SQL Server 2005 的安全功能是我认为值得升级的第三个理由。SQL Server 2005 的安全达到了前所未有的强大水平，有着比以前版本更清晰的安全模型即主体，安全对象和权限。在SQLServer 2000 中是用服务器级权限、数据库角色和数据用户权限的混合方式管理权限。而SQL Server 2005 统一使用GRANT语句管理主体对安全对象的权限，简化了安全管理。其中我认为最大的改进是用户和架构（schema）分离。在SQL Server 2000中如果用户不是DBO 且拥有对象，那么移除该用户将是很麻烦的事情。你需要首先使用sp_changeobjectowner改变该用户拥有的对象所有权，然后把所有引用该对象的代码做相应的修改。而在SQL Server 2005 中就不需要这样麻烦了，因为现在用户不再拥有对象。拥有对象的是schema 而不是用户。数据库中的所有对象都属于某个schema。对象的完整名字是server.database.schema.object，符合SQL- 99 标准，而不是以前的server.database.user.object 方式。删除用户仅需要改变schema的owner就可以了。不需要修改任何已存在的数据库访问代码，真的很方便。用户和架构分离还有一个好处就是对象的权限管理变得简单。你可以把某些对象集中于某个架构里面，然后对该架构设置权限，那么架构里面的所有对象就自动继承了同样的权限。

如果你需要保护数据库中的敏感数据，那么SQL Server2005 中的数据加密功能绝对值得考虑。以前不止一次有客户问我如何加密数据库中的某些数据，是否可以使用一些内部不公开的函数如PWDENCRYPT加密数据。我的回答是使用Windows的EFS（加密文件系统）功能加密数据库文件或在应用程序层对数据加密后再存储。现在用户期盼已久的数据加密功能终于在 SQL Server 2005 中得到实现，那些有机密数据需要保护的用户值得高兴了。SQL Server 2005不是简单的提供一些加密函数，而是把市场上已经成熟的数据安全技术引进到数据库中，有一个清晰的加密层次结构。SQL Server 2005 支持证书（certificate），非对称密钥和对称密钥算法，一是防止敏感数据被泄漏，二是防止数据被篡改。对称密钥支持RC4，RC2， TripleDES 和AES算法，而非对称密钥使用RSA 算法。证书其实就是非对称密钥中公钥的容器。密钥管理是安全中比较弱的部分。SQL Server 2005 每一层都使用证书、非对称密钥和对称密钥的组合对它下面的一层进行加密，提高了密钥安全性。出于性能考虑，一般不用加密强度大的非对称密钥或证书直接加密数据，而是使用对称密钥加密数据获得较快的性能，然后使用证书或非对称密钥加密对称密钥。

升级理由四：快照隔离
你还在为系统出现的阻塞（blocking）或死锁（deadlock）现象苦恼吗？快试试SQL Server 2005 中的快照隔离吧。通过行版本（row versioning）控制技术，SQL Server 2005 除了原来支持的四种事务隔离级别（脏读、提交读、可重复读、可串行读）外新增了一个快照（SNAPSHOT）隔离级别，有可能使阻塞或死锁成为历史。 SQL Server在TEMPDB中存放不同版本的数据行，select 语句读取这些不同版本的行，读操作不阻塞写数据，写操作也不阻塞读操作，这样那些由于读/ 写争用导致的大量死锁的系统将从中获得无穷益处。如果你的系统复杂难优化，那么升级到SQL Server 2005 试试快照隔离级别，也许会有意想不到的效果。

SQL Server 2005中的快照隔离可细分为两种即READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION。建议大家多使用前者，因为已提交读隔离可用于大多数现有应用程序，而不需要进行任何更改，其占用的TEMPDB空间也少。可以预见如果使用快照隔离级别，那么需要特别关注TEMPDB的大小和性能。你也许需要把TEMPDB放在有足够空间的单独磁盘上以提高性能。

考虑到快照隔离在避免阻塞和死锁方面的作用，我把它作为升级的第四个理由。

升级理由五：数据库镜像
对于那些要求高可用性的用户来说，数据库镜像也许是考虑升级的唯一理由。SQL Server 2005的前版本在高可用性方面提供了故障转移群集（Failover Cluster）和Log shipping方案。群集方案的一个好处是在一台机器发生问题时它可以提供极快的故障转移能力，在备份服务器上联机数据库，应用程序只需重新连接即可。群集方案的一个缺点是数据库放在共享盘上，有单点失效这个缺点，一旦共享盘失败将导致整个系统崩溃。所以群集方案一般都要结合严紧的备份方案一起使用。而 logshipping系统有一个时间上的延迟，且如果日志备份很大，传送速度也是个问题。SQL Server 2005引入的数据库镜像可作为故障转移群集或Log shipping 的替代或补充方案来提高数据库的高可用性。镜像的主要优点是它比前两者更容易管理，没有群集的单点失效缺点,也没有log shipping 的时间延迟。镜像服务器可以放在很远的地方，提高了作为备份服务器的高可用性。

数据库镜像需要两台或三台服务器。主服务器通过传送事务日志中的每个事务到镜像服务器来进行数据同步。每当数据库commit一个事务，该事务就会被同步到镜像服务器。如果事务安全设置为FULL，传送操作将为同步操作。同步操作可以确保将提交的事务提交给两个服务器，但可能会增加事务提交的时间。如果事务安全设置为OFF，操作将为异步操作。事务会在不等待镜像服务器的情况下提交，这将不影响主服务器事务的提交时间，但不能确保镜像也提交了该事务，所以在出现故障那一刻有可能有部分日志丢失。对于需要严格同步数据的镜像系统可以采取同步模式。而仅仅希望有个备份服务器又不影响性能的情况下可以使用异步模式（高性能模式）。无论那种模式，一旦主服务器出现问题，你可以手动实现故障转移或配置系统实现自动故障转移。

升级理由六：商务智能BI 增强
SQL Server 2005 对已经有或打算开发基于SQL Server 的商务智能方案的用户吸引力极大。SQL Server 2005中有关商务智能方面的增强很多，是升级的很好理由。首先是传统的DTS（Data Transformation Services）被新的IS（Integration Services）代替。SQL Server 2000 中的DTS用来在不同服务器之间转移数据，但对于复杂重复的工作流DTS倍感吃力。IS重新改写了DTS的数据流引擎，引入提取、转换和加载（ETL）数据的新编程体系，将数据流与控制流分开，开发能力大大加强，包部署、管理和性能方面也比DTS上了一个数量级。笔者看来，DTS终于从原来的小打小闹成长为成熟的IS 数据集成服务体系。

分析服务（Analysis Services）在SQL Server 2005 中也有很多改进。原来没有profiler想跟踪分析服务里面的语句非常痛苦。现在2005 终于支持profiler了。Profiler对性能调优和排查错误将非常有用。分析服务2005 真正具备了实时分析能力，新增加了四种数据挖掘算法，也支持.NET语言进行开发（如存储过程等）。至于报表服务，2005 版本中添加了报表生成器和模型设计器这两个新工具，支持报表拖拉设计。2005 的报表改进如新的打印功能、多值参数等。设计过报表的人员会深深知道多值参数的妙处。
另外，无论是IS、报表服务等都可以在类似Visual Studio的环境中开发，任务完成不过鼠标拖拉之间，非常容易上手。

升级理由七：全文搜索增强
相对前版本SQL Server 2005中性能提升最多的部分当数全文检索。SQL Server 2000 中的全文本检索和SQL Server 7.0中的差别不大，处于能用的水平。在SQL Server 2000中使用全文检索一个最大的痛苦是建立全文索引的性能不好，需要的时间太长，特别是在表很大的情况下。一个几千万行数据的表也许需要数个小时到数天时间才能完成全文索引的建立。SQL Server 2005全文检索在开发的时候就集中于三点：性能，集成，和可扩展性。据开发小组人员的简单测试，原来在SQL Server 2000中建立全文索引需要14天的表，现在只需要几个小时！几乎有上百倍的性能提升，只能用“惊异”来形容。其相关的全文检索语句也有30％～50％甚至更高的性能提高。性能方面的提高得益于全新设计的全文检索引擎。其中关键的一点设计是全文检索引擎现在使用共享内存和SQL Server 进行数据大规模并发交互，而不是原来基于逐行的方式，使得性能上了好几个数量级。

除了性能，SQL Server 2005 中的全文索引的集成性也大大加强。在SQL Server 2000 中很难对全文检索进行备份。一旦有数据库恢复或移动，你得重新重建索引。对于几百个GB的数据库，重建索引几乎是不能接受的恶梦。现在终于可以和数据库一起备份和恢复全文索引了。你不再需要在恢复数据库后重建全文索引了！恶梦终于成为历史。除了可以备份外，你也可以方便的改变全文索引的磁盘位置。你甚至可以在一个热备机器上把全文索引建立好，然后 这个索引到生产服务器上使用。

升级理由八：可用性功能增强
索引联机操作。除了数据库镜像，SQL Server 2005 中可用性还有很多其他提高。索引现在可以使用ONLINE关键字进行在线建立或重建或删除了。它的技术要点是在内存里面动态生成索引的另一个副本从而不影响原来查询的进行。一旦索引副本完成操作即替代原来索引成为当前索引。我认为索引联机操作的意义是很大的，因为很多数据库系统都有定期调整或维护索引方面的需求。有了2005 你无需担心业务的正常运行而大胆的对索引进行维护或修改。

页校验和。SQL Server 2005中的数据库页引入校验和增强了数据的可靠性。除了原来SQL Server 2000 中已有的TORN_PAGE_DETECTION 外，SQL Server 2005 新增实现了页的检验和（CHECKSUM）。你使用ALTER DATABASE语句的SET PAGE_VERIFY子句即可指定。它的原理是向磁盘中写入8K数据页面时，SQL Server计算整个8K页面内容的校验和并将该值存储在页头中。再次从磁盘中读取页时，SQL Server动态计算读取到的页面内容的校验和，并与存储在页头中的校验和值进行比较。如果不相等则意味着页面有物理损坏，需要检查IO硬件。另外设置检验和的另一个好处是还可以在备份和还原操作过程中使用RESTORE VERIFYONLY语句验证每一数据页的完整性从而确认备份文件没有物理损坏。

在线还原。在数据库的某一部分未恢复前，用户无法对该部分进行访问，但可以访问所有其他数据。SQL Server 2000中如果数据库在还原或recovery当中，用户不能访问数据库。这样如果数据库很大需要rollback或rollforward的事务很多的话，recovery的时间会出奇的长。SQL Server 2005 的在线还原功能使得数据库在很短的时间内变得可用。

升级理由九：复制增强
SQL Server 2000 中的复制功能已经很好。我这里把复制作为升级的一个理由因为SQL Server 2005在原来的基础上又增添了不少的功能。如peer-to-peer对等复制，可以在参与者之间相互进行复制，这样你可以采用对等复制在复制参与者之间建立某种程度的负载平衡。合并复制现在支持通过HTTPS进行数据同步，可以方便建立基于INTERNET 的复制。发布表现在可以使用标准的T-SQL语句如Alter Table等进行结构修改然后被复制而不是仅仅局限于使用sp_repladdcolumn和sp_repldropcolumn存储过程。在SQL Server 2000 中，仅支持向其他数据库（如DB2或Oracle）发布数据，而在SQL Server 2005 中，可将Oracle 数据库直接复制到SQL Server。可以从备份中初始化事务性订阅而不是仅仅局限于从快照对复制进行初始化，等等……

升级理由十：异步处理能力
SQL Server 2005 通过引入全新的Service Broker 提供了革命性的异步处理能力。Service Broker提供了一个功能强大的异步编程模型。它为数据库应用程序增加了可靠、可扩展、分布式异步功能异步编程，允许程序仅仅在资源可用时才去执行占用大量资源的任务，以此来缩短响应时间，提高吞吐量。在我看来，Broker的最大好处一是异步执行能力，提高了可伸缩性，二是可靠执行，三是集成于数据库中，备份数据库就备份了broker 的消息队列。SQL Server 2005 中的查询通知就是基于Service Broker的应用。你可以使用查询通知功能来发送一个命令到SQL Server请求在查询结果发生变化时接收SQL Server的通知。这样就可以只有在程序以前检索的结果发生变化时，才需要重新查询数据库。一个可以预见的应用是在使用缓存的Web 站点中。Web站点首先发送语句到数据库服务器，获得数据，缓存到本地，然后只有在收到查询通知的时候才清理缓存，重新查询数据。这个机制避免了重复轮询 SQL Server，大大减轻了服务器的负载，也提高了Web 站点的伸缩性。

因为SQL Server 2005 的Service Broker带来了数据库编程异步处理能力的革命，我把它作为升级的第十个理由。

去网上找找吧，这类的介绍很好找的

4. java.sql.SQLException: ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01003: 语句未进行语法分析

ORA-00604： 递归某个SQL 层时出现错误
- initSID.ora中，参数DC_FREE_EXTENTS或ROW_CACHE_ENQUEUES太低。可以根据操作系统和数据库的情况，适当增加这两个参数的值，宕下并重新启动ORACLE.
- 运行超出空间（伴随ORA-1547错误）。这时，要对表空间添加新文件，即增加表空间的大小。
- 达到了MAX_EXTENTS（伴随ORA-1556错误）。如果这样，就要修改表，允许更多的扩展。请从技术手册中查找MAX_EXTENTS的最大值。如果已经达到了最大值，必须用compress extents选项，把表卸出（export），再导入（import）数据库中。

5. oracle中使用sql递归算出1加到100的值

declare
iint;
kint;
begin
i:=1;
k:=0;
whilei<=100loop
k:=k+i;
i:=i+1;
endloop;
dbms_output.put_line(k);
end;

上边是用while循环，下边这个用for循环

declare
kint;
begin
k:=0;
foriin1..100loop
k:=k+i;
endloop;
dbms_output.put_line(k);
end;

6. Java项目启动：ORA-00604: 递归 SQL 级别 3 出现错误

JDBCExceptionReporter] ORA-00604: 递归 SQL 级别 3 出现错误
ORA-04031: 无法分配 4096 字节的共享内存 ("shared pool","select /*+ rule */ bucket_cn...","Typecheck heap","kgghteInit")
ORA-00604: 递归 SQL 级别 2 出现错误
ORA-04031: 无法分配 4096 字节的共享内存 ("shared pool","select /*+ rule */ bucket_cn...","Typecheck heap","kgghteInit")
11:31:45,625 INFO [STDOUT] 11:31:45,625 WARN [SettingsFactory] Could not obtain connection metadata
java.sql.SQLException: ORA-00604: 递归 SQL 级别 3 出现错误
ORA-04031: 无法分配 4096 字节的共享内存 ("shared pool","select /*+ rule */ bucket_cn...","Typecheck heap","kgghteInit")

你的这个字段是不是BLOB或CLOB类型，并且存了超过4K字节的内容啊？

还有建议你到SQL最好优化一下，我看你在其他强制索引，但你最好注意ORACLE的开销策略，SQL里ORACLE有自己的特殊算法，虽然程序里要求用索引，但ORACLE里不一定会用的，还有SQL最好不要一次关联太多表，不仅影响效率，还会影响系统的。

7. XML 和数据库之间的映射有什么作用

楼主 首先我们应该明白xml的作用：
XML的简单使其易于在任何应用程序中读写数据，这使XML成为数据交换的唯一公共语言，虽然不同的应用软件也支持其它的数据交换格式，但不久之后他们都将支持XML，那就意味着程序可以更容易的与Windows、Mac OS, Linux以及其他平台下产生的信息结合，然后可以很容易加载XML数据到程序中并分析他，并以XML格式输出结果。
————————————————————————
由上面我们可以得知，XML成为数据交换的唯一公共语言，异构系统 甚至 异构平台的信息交互 都要靠xml传输数据，举个例子：
.net 开发的系统 和 java开发的系统 如何进行数据交换，如何进行深度整合和互操作，考得就是webservice，而现在webservice数据格式一般都是采用xml的，因为xml是数据交换的事实上的工业标准了，通过它我们可以“穿透那个可亲又讨厌的防火墙”. 呵呵

数据一般都是从数据库中取出的吧，所以 研究xml与数据库数据的互相转化和映射关系，就显的非常重要了。

————————————————————————

XML在Web领域已经得到了广泛的应用，而XML数据库一直是个研究热点。各数据库厂商及研究机构纷纷投入对XML技术的研究及开发。大体上可以把XML数据库分为两类：原生XML数据库(Native XML Database)和使能XML数据库(Enable XML Database)。而XML数据一般可划分为粗粒度、中粒度及细粒度三种形式。以文档为中心的粗粒度形式，一般采用原生XML数据库，而以数据为中心的细粒度形式一般采用使能XML数据库。

XML数据是嵌套的树形结构，而关系数据库是简单、平面的二维表结构，结构的差异性，使得在存储XML数据时需要按一定的映射规则进行转换，并使能够恢复到原XML文件。

XML文件物理结构上由多种元素组成，本文的研究只考虑常用的ELEMENT、TEXT、ATTRIBUTE三种元素，采用三个表来保存XML数据。主要思想是把树结构中的中间节点(非属性和文本节点)放入mNode(Middle Node)表，叶子节点(属性和文本节点)放入eNode(End Node)表，另外一个是ePath表，用于保存从根节点到叶子节点的路径。当然保存多个XML时，我们会引入一个用于保存区分各个XML的表。详细说明如下：

1) Path(pathID, path)

该表主要保存从根结点到各个叶子结点的所有不同的路径，在查询时可满足类似于Xpat的查询。

pathID：各不同的路径标识符，在解析过程中产生。

path：实际路径名称。

2)mNode(nodeID, nodeName, parentID, order, pathID)

该表主要通过指定parentID来保存各节点间的父子关系，以保持原XML的树型结构。

nodeID：节点的唯一标识符，在解析过程中产生。

nodeName：节点的名称，即XML中的实际名称。

parentID：父节点的标识符，根节点置为-1。

order：兄弟节点的先后次序。

pathID：从根结点到本节点所走的路径。

3)eNode(nodeName, nodeValue, parentID, order, type)

该表主要保存属性及文本节点的值。

nodeName：属性名，如果是文本节点则取其父节点名。

nodeValue：属性文本值。

parentID：父节点的标识符。

order：兄弟节点的先后次序。

type：用于区分属性还是文本的标量。

4转换方法

从XML到SQL，一般都是采用递归算法，先根遍历XML树结构，而从SQL返回到XML时，一般采用队列生成XML节点。递归过程一般要消耗较多的时间和空间，在处理较大结构的XML时，性能上不是很理想。

本模型在XML和SQL中放入一个中间层，该层中主要有根据DTD或Schema生成的一系列Bean、一个操作SQL的模块、一个操作XML的模块，另外在此基础上还可以方便扩展给其他业务逻辑层调用的模块。结构如下图所示:

JavaBeans：这里所说的JavaBeans是根据XML 对应的DTD或Schema所产生的有级联关系的类。通过这些类逻辑上形成一棵XML树形结构，用于存放实际XML数据。对于如下的一部分DTD：

<! ELEMENT book (title, price, author+)>
<! ATTLIST book year CDATA>
<! ELEMENT title (#PCDATA)>
<! ELEMENT price (#PCDATA)>

我们可以设计一个BookItem类，它包括一个TitleTxt字段、一个PriceTxt字段、一个AuthorBean字段以及一个YearAttr字段，其中AuthorBean由多个AuthorItem组成，类似的，AuthorItem包含它下面的节点信息。在这个过程中，可以完成ePath表的信息建立。

根据前面的映射模型，对于BookItem类的title字段，设计如下形式的类结构：

Public Class BookItem(){
Private String titleTxt;
Public setTitleTxt(String title){}
Public getTitleTxt(){}
Public setTitleParentID(int parentID){}
Public getTitleParentID(){}
Public setTitleOrder(){int order}
Public getTitleOrder(){}
…
}

而对于AuthorBean类，类结构设计如下：

Public Class AuthorBean(){
Private Vector beanVector;
Public void add(AuthorItem authorItem){}
Public AuthorItem getByIndex(int index){}
Public int getSize(){}
…
}

从结构上容易看出，代码量非常大，但由于都是一些get()和set()方法，这些代码不用通过手工去撰写，而是根据DTD或Scheme的信息自动生成。在过程①及过程④中调用set()方法，在过程②及过程③中调用get()方法。

XML Operator：该模块可以支持DOM、SAX解析。根据层次信息依次解析每个节点，此过程中记录父子节点关系，并且记录一个节点中所有子节点的先后顺序，并设定到Bean中。

SQL Operator：该模块主要是把Bean中的信息写入数据库，以及从数据库中读取信息供重组XML。

楼主，希望我的给出信息和资料对你的问题的解决 有所帮助！：-）

8. sql递归建立公司结构的方法 下面有错误但是不知道错在哪里

ORA－00604：递归某个SQL层时出现错误－initSID．ora中，参数DC＿FREE＿EXTENTS或ROW＿CACHE＿ENQUEUES太低uycg可以根据操作系统和数据库的情况适当增加这两个参数的值628宕下并重新启动ORACLE．－运行超出空间（伴随ORA－1547错误）mq这时，要对表空间添加新文件，即增加表空间的大小ycg－达到了MAX＿EXTENTS（伴随ORA－1556错误）m如果这样，就要修改表，允许更多的扩展。请从技术手册中查找MAX＿EXTENTS的最大值。如果已经达到了最大值，必须用compressextents选项28把表卸出（export），再导入（import）数据库中。

9. Sql server 如何实现递归算法

可去了解一下SQL的CTE算法，实现递归

10. sql 2000 递归算法

select
categoryName

from
表名

where
categoryCode
like
'01%'

order
by
Clevel

具体你01的取值可以通过参数实现