操作对象 | 创建 | 删除 | 修改 |
---|---|---|---|
模式 | CREATE SCHEMA | DROP SCHEMA | |
表 | CREATE TABLE | DROP TABLE | ALTER TABLE |
视 图 | CREATE VIEW | DROP VIEW | |
索 引 | CREATE INDEX | DROP INDEX |
大家不一定要了解这个东西的准确定义是什么,但是一定要知道它是数据库的基础。
没有数据表,关键字、主键、索引等也就无从谈起。在数据库画板中可以显示数据库中的所有数据表,创建数据表,修改表的定义等。
数据表是数据库中一个非常重要的对象,是其他对象的基础。
在MySQL中创建一个schema好像就跟创建一个database是一样的效果,在SQL Server和Orcal数据库中好像又不一样。所以我们要理解一下schema和table的关系。
在sql server2000中,用户和架构是不分离的,关系如下表:
user对于不同的schema有不同的权利。
我们可以可以把database看作是一个大仓库,仓库分了很多很多的房间,schema就是其中的房间,一个schema代表一个房间,table可以看作是每个schema中的床,table(床)就被放入每个房间中,不能放置在房间之外。
然后床上可以放置很多物品,就好比table上可以放置很多列和行一样。数据库中存储数据的基本单元是table,现实中每个仓库放置物品的基本单位就是床。
User是对应与数据库的(即User是每个对应数据库的主人),既然有操作数据库(仓库)的权利,就肯定有操作数据库中每个schema(房间)的权利,就是说每个数据库映射的user有每个schema(房间)的钥匙
还可以给user分配具体的权限,也就是他到某一个房间能做些什么,是只能看(Read-Only),还是可以像主人一样有所有的控制权(R/W),这个就要看这个user所对应的角色Role了。
总结来说,我们的数据库就是一个数据的大仓库,而里面创建了很多很多模式,分别放着不同的数据库对象(包括表),而不同的模式有不同的权限,于是,不同的用户就有不同的访问权限来访问某个模式里的数据库对象。
1.数据库引入了索引
用户对数据库最频繁的操作是进行数据查询。一般情况下,数据库在进行查询操作时需要对整个表进行数据搜索。当表中的数据很多时,搜索数据就需要很长的时间,这就造成了服务器的资源浪费。为了提高检索数据的能力,数据库引入了索引机制。
2.有关“索引”的比喻
从某种程度上,可以把数据库看作一本书,把索引看作书的目录,通过目录查找书中的信息,显然较没有目录的书方便、快捷。
3.数据库索引实际是什么?(两部分组成)
索引是一个单独的、物理的数据库结构,它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。
4.索引在表中的角色
一个表的存储是由两部分组成的,一部分用来存放表的数据页面,另一部分存放索引页面。索引就存放在索引页面上。
5.索引高效原理
通常,索引页面相对于数据页面来说小得多。当进行数据检索时,系统先搜索索引页面,从中找到所需数据的指针,再直接通过指针从数据页面中读取数据。
目前所说的概念,都是在逻辑层上进行的操作,而有的时候,我们需要做出来一个虚拟的表给用户看,除安全性考虑(视图是只读的)之外,更加考虑到用户的直觉问题(让他看到更合理的数据)。
视图(view)是从一个或几个基本表中根据用户需要而做成一个虚表。
1:视图是虚表,它在存储时只存储视图的定义,而没有存储对应的数据。
2:视图只在刚刚打开的一瞬间,通过定义从基表中搜集数据,并展现给用户。
视图和查询都是用由sql语句组成,这是他们相同的地方,但是视图和查询有着本质区别:
它们的区别在于:
1:存储上的区别:视图存储为数据库设计的一部分,而查询则不是.
2:更新限制的要求不一样
要注意:因为视图来自于表,所以通过视图可以间接对表进行更新,我们也可以通过update语句对表进行更新,但是对视图和查询更新限制是不同的,以下我们会知道虽然通过视图可以间接更新表但是有很多限制.
3:排序结果:通过sql语句,可以对一个表进行排序,而视图则不行。比如:创建一个含有order by子句的视图,看一下可以成功吗?
view和table的关系就像是cache和内存的关系。
内存中的数据修改之后,会对应修改cache的数据,但是不允许直接修改cache中的数据。
视图是可以被展开的,也就是说,可以用视图来定义视图(这个功能很cool吧),但是不可以递归定义。
为什么有了表还要引入视图呢?这是因为视图具有以下几个优点: