怎样管理好ORACLE数据表

ORACLE数据库中 表是最基本的内容 可以说 表设计的好坏直接跟数据库的性能相关 所以 在设计表的时候 除了要遵循其固有的数据库准则之外 还需要看个人的数据库管理经验 下面我就把这些经验分享一下 或许对大家有所帮助 一 表该存放在哪里 我们都知道 在ORACLE数据库中 使利用空间这个概念来管理表对象的 在数据库创建的时候 数据库中已经建立了一些表空间 那么当我们新建立表的时候 这个新表的位置该放在什么地方呢这就好像吃饭时的坐的位置一样 是有讲究的 一般来说 我们在新建表的时候 至少要遵循如下建议 一是在数据库创建的时候 在数据库中已经有了一个SYSTEM的表空间 一般情况下 这个表空间中 只包含数据字典及Oracle系统对象 如果我们将我们的表建立在这个空间上的话 那是要降低数据库的性能的 所以 一般我们是不建议用户把表格建立在这个空间上 但是 若我们不只一个人维护数据库 如有八个人共同设计数据库系统时 如何才能保证其他用户不在SYSTEM表空间中建立数据库表格呢最好的办法就是通过权限控制 如我们可以给每个数据库设计人员指定一个默认的表空间 让他们只能在这个表空间中建立表格 如此的话 就能防止他们在SYSTEM表空间中建立自己的数据表格 从而对数据库的运行性能产生不良影响 所以 若给每个用户设置默认表空间的话 那么用户在建立具体的表时 不用具体指定表空间了 二是我们在为某个应用设计数据库的时候 最好先对表的空间进行规划 一般情况下 不要把数据表随意的分散到不同的表空间中去 如我们在为一个ERP系统设计数据库的时候 若把采购部门相关的表跟销售部门相关的表放到两个不同的表空间中去 这是不明智的做法 这么处理的话 会降低某些数据库管理和维护 *** 作的效率 如数据的备份与恢复 *** 作;而且 也无法集中管理属于某个特定应用的数据 所以 我们一般建议 在规划数据库表空间的时候 把相同应用的表放在同一个表空间中去 如果要区分不同部门或者不同模块的表的话 我们可以在表的命名上动脑子 如我们在设计ERP系统的数据库中 可以根据其应用模块的不同 在前面加上前缀来进行识别 如跟系统基本配置相关的表 我们可以用AD为前缀;而跟销售部门相关的表 我们可以加上SA前缀等等 如此的话 这些表具体是属于哪个模块的 就一清二楚了 完全没有必要为此设置不同的表空间 这是ORACLE数据库初学者经常会犯的错误 主要是对ORACLE表空间的定义不是很熟悉所导致的 二 对预计存储数量比较大的表时 要给与额外的重视 有些表非常的大 我们这边说的大 不一定是说结构复杂 而是指在这个表格中 预期会存储比较多的数据 为了提高对这个表格的处理效率 我们在事先要做出一定的安排 否则的话 后续对这些大表进行查询 插入等 *** 作的话 速度会很慢 所以 我们就有必要在数据库设计的时候 先预先估计一下表的数据存储量 把一些数据量大的表格 做一些额外的设置 如在ERP软件的数据库设置中 一般来说 产品数据与物料清单数据这两个表的数据量会比较大;而从长远看的话 销售订单 采购订单 生产订单 记账凭证等这种单据类相关的表格其数据量也会比较大 一年两年可能感觉不出来 但是 到十年后 这个纪录数量就会很庞大 而像ERP系统这种大型的信息化管理项目 用个几十年时很正常的事情 而且 为了记录的完整性 也不建议用户把以前的数据删除 所以 为这种应用进行数据库设计的时候 要充分考虑这些大表的性能问题 具体的来说 设计大表的时候 可以考虑遵循如下的建议 一是不要为大表设置存储的限制 在ORACLE数据库中 可以为每张表格设置存储配额限制 如此的话 表最大容量就不能超过这个限制 对于一些数据容量比较小的表格 这么设置时合理的 可以提高空间的利用率 但是 若数据量比较大的话 就不建议事先设置表的存储空间了 如ERP系统的销售订单表 其刚开始可能记录量很小 第一年预计只有 G的记录容量 但是 估计在十年后 这个记录容量就会达到 G了 在这种情况下 我们怎么来给其设置存储空间呢一开就设置 G空间 这也是不合理的 而且 设置存储空间 就意味着有可能产生存储碎片 从而影响到数据查询的效率 所以 在数据库表的设计过程中 若某些应用的表可能会有比较大的数据容量时 建议不要对其存储空间做出任何的限制 二是要为这大表分配足够的临时空间 如我们使用ERP系统时 要查询产品资料信息 我们都知道 产品信息的话 有些企业这个纪录数非常的庞大 而且在查询时 我们还会经常的进行排序 *** 作 如有时候会按照产品编码对查询出来的数据进行排序 当记录少的话 还好;但是 当记录多的话 这个排序动作 要求具有比较大的临时存储空间 所以 当某个表预计会有很大的记录数量的时候 我们就要给其分配足够多的临时空间 临时空间的存储参数设置取决于临时表空间的默认储存参数设置 我们可以更改这些参数 以达到我们对要求 若没有给大表分配足够多的临时空间的话 则排序的动作将会很慢 而且很可能不成功 三是要考虑将表与表的索引分离存放 大表所对应的索引通常也比较大 一般来说 索引的数量是随着表记录的数量增加而增加 两者是接近于一个正比例的关系 所以 通常表的记录容量大的时候 索引数量也会很庞大 针对这种情况 我们考虑突破我们上面讲的表空间的规则定义 而考虑把表和他的索引分别存储于不同的表空间中 甚至在条件允许的情况下 分别存储于不同的硬盘中 这么做的好处是什么呢最大的好处是让索引比较容易的获得所需要的连续的存储空间 从而提高输入输入的效率 通俗的说 就是可以提高数据的查询效率 如不这么处理的话 查询大容量的记录的话 数据库可能需要花费 秒;而如此设计的话 就可能把时间缩短为 秒 这是一个很明显的性能改善 三 如何给表命名 上面我在讲如何为表分配存储空间的时候 已经讲到过这方面的问题 下面 我就将对这个问题进行详细的描述 以帮助数据库管理员掌握一套好的数据库命名规则 首先 毋庸置疑的 在为标命名的时候 要遵循ORACLE数据库的基本命名规则 如不能以数字开头为表命名 如不能利用数据库的关键字为表命名 如表的名字不能重复等等 这些是最基本的要求 就不用我多费口舌了 除了要遵循这些基本的命名规则外 在实际工作中 为了数据库后续的维护等方面出发 我们还是要遵循一些额外的规则 这些规则跟ORACLE定义的规则不同 我们所讲的规则没有约束力 可以说 只是业界的一些共识而已 你若不怎么处理 ORACLE数据库也不会说你错误 只是后续维护的时候 会比较麻烦而已 一是在对数据库命名的时候 最好能跟体现表的分类关系 如最常见的 我们在设计数据库的时候 表都是按系统的具体模块来区分的 如根据前端系统要求的不同 数据库的表大致可以分为系统基本配置表 销售模块表 采购模块表 报表模块表等等 我们可以根据这些模块的不同 分别给与不同的前缀来区分 这么做的好处是很明显的 如一看到表最大名字 就可以知道这个表是属于哪个应用的 哪个模块的 这无疑可以提高数据库设计与前台软件开发的效率 同时 数据库中默认的排序规则是按名字来排序的 所以 为表格设置类别前缀的话 可以把同一类的表格排在一起 方便我们察看 二是对表格命名的时候 要考虑可读性 而不能随便阿狗阿猫的乱取名字 最常见的是 那些刚学数据库的人 在表命名的时候 如要建几张测试表 就会随便命名如TEST TEST 之类的 虽然这只是测试 但是 也不符合我们的命名过则 要做测试的话 那就以TEST开头 然后后面加上具体要测试的内容 如此的话 我们才可以通过表的名字知道该表具体的用途 而不用打开表去看里面具体的结构或者注释才能知道我们需要的信息 所以 在设计表的名字的时候 还要关注一下其的可读性 lishixinzhi/Article/program/Oracle/201311/18317

SQL Server本身就是一个完善的数据库，提供可视化编程，后台完成所有拖放处理 *** 作，不管有没有数据都可以使用，不需要编译。

一个比较合理的数据库设计应该考虑数据的交互性和挖掘能力、处理效率以及日志记录。

建立数据表，注意以下几点：

表建立的时候要有主键和索引，表与表之间要能使用主键相联系，举例说在A表里我做完一次记录要生成一个单号，B表里面是依据单号来做下一个流程，而不是依据记录的每一条数据

取名尽量使用英文+下划线，SQL Server里对汉字需要转码，影响工作效率，按照他的默认编码方式 *** 作有助于提高数据处理速度

建立数据表的列数不要太多，用编码规则来建立逻辑

注意字段存储空间，限制字段长度，少用注释和image

存储过程尽量简洁实用

建立视图，为了别的客户端使用，尽量建立视图，做好完整的数据分析，别的接口程序或者客户端直接就可以拿去使用。做视图注意几点：

多个表 *** 作写在一个视图里，不要嵌套太多视图

连接查询要适当的筛选

跨服务器 *** 作视图，要建立服务器链接表，尽量使用内网链接，把服务器链接表做成查询视图，放在本地服务器数据库里，这样就等同本地 *** 作

视图之间保留连接字段作为主要索引

建立计划作业，有计划地进行数据同步更新和备份标识工作，注意事项：

备份数据尽量放数据库里同步复制

计划任务避开工作高峰期

建立存储过程，记录 *** 作日志，把日志以数据表的形式存储，注意事项：

存储过程对本表 *** 作，不要交互太多表

精简参数数量，注意参数存储空间

对记录修改删除、更新标记的时候尽量使用时间来索引

建立关系图，给表与表之间建立直接关系，整理整体挖掘数据性能。

建立计划更新任务，优化数据库整体性能。

可以通过在数据库中设置外键约束来实现级联更新相关字段，具体步骤如下：

1 在两个表中分别创建外键字段，并且设置外键约束；

2 在外键约束中设置级联更新，即当主表中的数据发生更新时，从表中相关字段也会自动更新；

3 保存设置，完成级联更新设置。

其实索引的好坏还和你的查询语句有关系,就是where后边的列有关如果两者协调不好的话,同样应用索引也得不到什么好处下边的文章希望对你有益:

索引的设计

A:尽量避免表扫描检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。下面的两个条件可以提高索引的优化查询性能！第一：在表中的column1列上有一个单索引第二：在表中有多索引，但是column1是第一个索引的列避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能例如：下面的例子用了pubs数据库。

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'按下面几个列上建立的索引将会是对优化器有用的索引

au_lname

au_lname, au_fname而在下面几个列上建立的索引将不会对优化器起到好的作用

au_address

au_fname, au_lname考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的

histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。有用的索引会提高select语句的性能，包括insert,uodate,delete。但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index

5000 Nonclustered index

20 Clustered index

3 No index

镞索引和非镞索引的选择

<1:>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读 *** 作，因此镞索引常常能加速这样的 *** 作。在至少有一个索引的表中，你应该有一个镞索引。在下面的几个情况下，你可以考虑用镞索引：例如：某列包括的不同值的个数是有限的（但是不是极少的）顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。例如：对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行 *** 作的列上。

select from sales where ord_date between Ƌ/1/93' and ƌ/1/93'例如：对查询时返回大量结果的列可以使用镞索引。

SELECT FROM phonebook WHERE last_name = 'Smith'

当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

<2:>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。在有很多不同值的列上可以考虑使用非镞索引例如：一个part_id列在一个part表中select from employee where emp_id = 'pcm9809f'查询语句中用order by子句的列上可以考虑使用镞索引

三、查询语句的设计

SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。例如下面的例子，select qty from sales where stor_id=7131是很有效的比下面这个无限制的查询select qty from sales避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。第一：在表中的column1列上有一个单索引第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。这时多索引是没有用的。

For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in

the pubs database,下面这个query语句利用了au_lname上的索引

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'

AND au_fname = 'Johnson'

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_fname = 'Johnson'

数据库表ID设置实现能自动增长的步骤如下(以TB_News表为例)：

步骤1：首先检查你的新闻表ID列的数据类型，要设置为自增列，需要该列的数据类型为int或者bigint等数值类型

步骤2：打开sqlserver management studio,右键点击你的新闻表，选择“设计”

步骤3：在第1步打开的表结构设置界面，点击你的列“ID”，在底下的列属性设置界面做如下设置:

进行完以上步骤，即可在该数据表中插入数据时，不用给ID列赋值，ID列的值会自动生成，并且该列的值会自动增长。

网上资料说权限设计 = 功能权限 + 数据权限，我认为还是很有道理的。之前项目中只涉及到功能权限，没有数据权限，原因是最开始设计时，数据已经绑定在特定的用户下了，而且涉及到的表数量很少，不需要单独考虑数据权限的问题。

权限管理，最细致的权限管理有 用户，用户组，角色，权限，功能。根据不同的需求适当选择，如 用户量过大，每个人都授权和麻烦，就引入用户组，对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系，需要引入中间表。

本系统设计如下：

数据量很小，功能也不复杂，所以只有用户，角色，权限（功能）及产生的中间表。

表中的数据都是提前填的，用户登陆，查ermroleuser表，获取角色，查ermrolefunction表，获取功能，再查ermfunction表，返回该用户的功能的中文，在页面上展示。

功能权限详细设计请参考，本项目也是受此启发：

>

以上就是关于怎样管理好ORACLE数据表全部的内容，包括:怎样管理好ORACLE数据表、如何构建一个完善的数据库,如何来处理表与表关系.、如何让将数据库所有的表关系设置级联更新相关字段等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！