我用的mysql版本为: Mysql-5.5.45-win64.msi 密码是:26zw
图形化工具 Navicat(前期不推荐用,直接手动敲): Navicat 密码:c7fs
开始我的MySQL之旅吧 始于2016.12.04
--WH
一、数据库的安装
这个就不在这里过多阐述了,因为网上实在是太多安装mysql的教程了,有了我给的mysql,在按照这个安装教程(MySQL安装教程)去看,就能够安装完好。
安装好mysql后,如果需要使用windows命令窗口(也就是cmd)来 *** 作mysql,那么就需要配置环境变量,在安装好的mysql下找到bin,将其目录放到环境变量path中去,就行了,检测成功与否的方法是在cmd命令窗口中输入mysql,就会出现一大段英文,就说明成功了,反之失败,如果不会的话就去百度搜教程。
二、数据库的基本 *** 作
1、开启mysql服务命令
net start mysql
2、进入mysql的两种方式
明文进入:mysql -uroot -proot格式:mysql -u帐号 -p密码
密文进入:mysql -uroot -p 按enter会提示你输入密码(Enter pssword:),此时你写的密码就会显示为***这样。
3、查看mysql中所有的数据库(一般在固定的单词命令就会是用大写,这个要习惯,看多了敲多了就认识了)
前面四个数据库是mysql中自带的,也就是必须的.
SHOW DATABASES
4、创建名为test_1的数据库
格式:CREATE DATABASE 数据库名
CREATE DATABASE test_1
5、删除名为test_1的数据库
格式:DROP DATABASE 数据库名
DROP DATABASE test_1
总结:学习了对数据库的三个 *** 作,1、查看所有数据库 2、创建数据库 3、删除数据库
三、数据表的基本 *** 作
数据表和数据库还有Mysql三者的关系
mysql中保存了很多数据库、一个数据库中可以保存很多表。
对数据表的增(创建表)删(删除表)改(修改表字段)查(查询表结构)。 注意:这里的 *** 作对象是表,对表的 *** 作也就是表的结构,和表中的字段的 *** 作(字段和记录要分清楚)
前提:表是在数据库下的,所以要先确实使用哪个数据库。
USE test_1
1、创建数据表
格式:CREATE TABLE 数据表名(
字段名1数据类型[列级别约束条件],
字段名2数据类型[列级别约束条件],
字段名3数据类型[列级别约束条件]
)
注意:格式不一定需要这样隔着写,完全可以全部写成一行。但是那样写可观性非常差。我这样写只是为了可以看的更清晰。
解释:
1、[]中括号中的内容表示可以有可以没有,
2、列级别这个“列”一定要搞清楚说的是什么,一张表中有行有列,列表示竖,行表示横
3、约束条件后面会讲到
1.1、创建没有约束的student表
CREATE TABLE student( idINT(11), nameVARCHAR(12), ageINT(11) )
注释:SHOW TABLES 查询数据库底下的所有表。
1.2、创建有约束的student表
六大约束:主键约束、外键约束、非空约束、唯一约束、默认约束、自动增加
1.2.1:主键约束
PRIMARY KEY(primary key):独一无二(唯一)和不能为空(非空),通俗的讲,就是在表中增加记录时,在该字段下的数据不能重复,不能为空,比如以上面创建的表为例子,在表中增加两条记录,如果id字段用了主键约束。则id不能一样,并且不能为空。一般每张表中度有一个字段为主键,唯一标识这条记录。以后需要找到该条记录也可以同这个主键来确认记录,因为主键是唯一的,并且非空,一张表中每个记录的主键度不一样,所以根据主键也就能找到对应的记录。而不是多条重复的记录。如果没有主键,那么表中就会存在很多重复的记录,那么即浪费存储空间,在查询时也消耗更多资源。
一般被主键约束了的字段度习惯性的称该字段为该表的主键
单字段主键约束
两种方式都可以
CREATE TABLE student(CREATE TABLE student(
idINT(11) PRIMARY KEY,idINT(11),
nameVARCHAR(12),nameVARCHAR(12),
ageINT(11) ageINT(11),
) PRIMARY KEY(id) )
多字段主键约束(复合主键)
这个id和name都市主键,说明在以后增加的插入的记录中,id和name不能同时一样,比如说可以是这样。一条记录为id=1,name=yyy、另一条记录为:id=1,name=zzz。 这样是可以的。并不是你们所理解的两个字段分别度不可以相同。
CREATE TABLE student(CREATE TABLE student(
idINT(11) PRIMARY KEY,idINT(11),
nameVARCHAR(12) PRIMARY KEY, nameVARCHAR(12),
ageINT(11) ageINT(11),
)PRIMARY KEY(id,name) )
1.2.2:外键约束
什么是外键举个例子就清楚了,有两张表,一张表是emp(员工)表,另一张表是dept(部门)表,一个员工属于一个部门,那么如何通过员工能让我们自己他在哪个部门呢?那就只能在员工表中增加一个字段,能代表员工所在的部门,那该字段就只能是存储dept中的主键了(因为主键是唯一的,才能确实是哪个部门,进而代表员工所在的部门,如果是部门名称,有些部门的名称可能是同名。就不能区分了。),像这样的字段,就符合外键的特点,就可以使用外键约束,使该字段只能够存储另一张表的主键。如果不被外键约束,那么该字段就无法保证存储进来的值就一定是另一张表的主键值。
外键约束的特点:
1、外键约束可以描述任意一个字段(包括主键),可以为空,并且一个表中可以有多个外键。但是外键字段中的值必须是另一张表中的主键。
2、这样被外键关联的两种表的关系可以称为父子表或者主从表。子表(从表)拥有外键字段的表,父表(主表)被外键字段所指向的表。
3、子表被外键约束修饰的字段必须和父表的主键字段的类型一样。
注意:一个表中有被外键修饰的字段,就称该表有外键(是“有外键”。而不是“是外键”),并会给该表中的外键约束取一个名称,所以我们常说的这个表有没有外键,指的不是被外键约束修饰的字段名,而是指这个表是否有存在外键约束。也就是说,不能说这个表的外键是xxx(该表中被外键约束修饰的字段名),这种说法是错误的,但是大多数人已经习惯了这样,虽然影响不大,但是在很多时候需要理解一个东西时,会造成一定的困扰。
格式:CONSTRAINT外键名称FOREIGN KEY(被外键约束的字段名称)REFERENCES 主表名(主键字段)
英文解释:CONSTRAINT:约束REFERENCES:参考
CREATE TABLE tableA
(
id INT(11),
name VARCHAR(22),
location VARCHAR(50),
PRIMARY KEY(id)
)
CREATE TABLE tableB
(
id INT(11),
name VARCHAR(22) NOT NULL,
deptId INT(11),
PRIMARY KEY(id),
CONSTRAINT tableA_tableB_1 FOREIGH KEY(deptId) REFERENCES tableA(id)
)
解释:tableB中有一个名为tableA_tableB_1的外键关联了tableA和tableB两个表,被外键约束修饰的字段为tableB中的deptId,主键字段为tableA中的id
1.2.3:非空约束
NOT NULL. 被该约束修饰了的字段,就不能为空,主键约束中就包括了这个约束
CREATE TABLE tableA
(
id INT(11),
name VARCHAR(22) NOT NULL,
location VARCHAR(50),
PRIMARY KEY(id)
)
1.2.4:唯一约束
UNIQUE 被唯一约束修饰了的字段,表示该字段中的值唯一,不能有相同的值,通俗点讲,就好比插入两条记录,这两条记录中处于该字段的值不能是一样的。
CREATE TABLE tableA
(
id INT(11),
name VARCHAR(22) UNIQUE,
location VARCHAR(50),
PRIMARY KEY(id)
)
也就是说在插入的记录中,每条记录的name值不能是一样的。
1.2.5:默认约束
Default 指定这一列的默认值为多少,比如,男性同学比较多,性别就可以设置为默认男,如果插入一行记录时,性别没有填,那么就默认加上男
CREATE TABLE table
(
id INT(11) PRIMARY KEY,
name VARCHAR(22) NOT NULL,
deptId INT(11) DEFAULT 1111,
salary FLOAT
)
1.2.6:自动增加
AUTO_INCREMENT 一个表只能一个字段使用AUTO_INCREMENT,并且使用这个约束的字段只能是整数类型(任意的整数类型 TINYINT,SMALLIN,INT,BIGINT),默认值是1,也就是说从1开始增加的。一般就是给主键使用的,自动增加,使每个主键的值度不一样,并且不用我们自己管理,让主键自己自动生成
CREATE TABLE table( id INT(11) PRIMARY KEY AUTO_INCREMENT, name VARCHAR(22) NOT NULL)
2、查询表结构
2.1、查看表基本结构语句
格式1:DESCRIBE 表名/DESC 表名这两个的功能是一样的,简写了单词describe
DESCRIBE student
2.2、查看创建表的语句
格式:SHOW CREATE TABLE 表名
SHOW CREATE TABLE student
这样显示的格式很不好,看不清楚,所以有了下面这个语句
格式:SHOW CREATE TABLE 表名\G
SHOW CREATE TABLE student\G
3、修改数据表
修改数据表包括:对表中字段的增加、删除、修改。 在这个里面用的关键字为 ALTER
3.1、修改表名
格式:ALTER TABLE<旧表名>RENAME[TO]<新表名>
将student表名改为student1(改完后在改回来)
ALTER TABLE student RENAME TO student1
3.2、修改表中的字段名
格式:ALTER TABLE<表名>CHANGE<旧字段名><新字段名><新数据类型>
将student表中的name字段名改为 username
ALTER TABLE student CHANGE name username VARCHAR(30)
3.3、修改表中的数据类型
格式:ALTER TABLE<表名>MODIFY<字段名><数据类型>
ALTER TABLE student MODIFY username VARCHAR(20)
解释:只能修改字段名的数据类型,但是其原理跟上面change做的事情一样,这里也有修改字段名的过程,只不过修改后的字段名和修改前的字段名相同,但是数据类型不一样。
3.4、修改字段的排列位置
方式1:ALTER TABLE<表名>MODIFY<字段1><数据类型>FIRST|AFTER<字段2>
解释:将字段1的位置放到第一,或者放到指定字段2的后面
ALTER TABLE student MODIFY username VARCHAR(20) AFTER age
方式2:ALTER TABLE<表名>CHANGE<字段1><字段2><数据类型>FIRST|AFTER<字段3>
解释:其实是一样的,将是字段2覆盖字段1,然后在进行排序
ALTER TABLE student CHANGE username username VARCHAR(20) AFTER age
总结
CHANGE和MODIFY的区别?
原理都市一样的,MODIFY只能修改数据类型,但是CHANGE能够修改数据类型和字段名,也就是说MODIFY是CHANGE的更具体化的一个 *** 作。可能觉得用CHANGE只改变一个数据类型不太爽,就增加了一个能直接改数据类型的使用关键字MODIFY来 *** 作。
3.5、添加字段
格式:ALTER TABLE<表名称>ADD<新字段名><数据类型>[约束条件][FIRST|AFTER<已存在的表名>]
解释:在一个特定位置增加一个新的字段,如果不指定位置,默认是最后一个。
ALTER TABLE student ADD sex VARCHAR(11)
3.6、删除字段
格式:ALTER TABLE<表名称>DROP<字段名>
ALTER TABLE student DROP sex
3.7、删除表的外键约束
格式:ALTER TABLE<表名称>DROP FOREIGN KEY<外键约束名>
注意:外键约束名 指的不是被外键约束修饰的字段名,切记,而是我们在创建外键约束关系时取的名字。
3.8、更改表的存储引擎
格式:ALTER TABLE<表名>ENGINE=<更改后的存储引擎名>
这个存储引擎目前我自己也不太清楚,虽然知道有哪几种引擎,但是稍微深入一点就不清楚了,所以打算留到日后在说。
4、删除表
4.1、删除无关联表
格式:DROP TABLE<表名>;
ALTER TABLE student
4.2、删除被其他表关联的主表
这个是比较重要的一点,在有外键关联关系的两张表中,如果删除主表,那么是删不掉的,并且会报错。因为有张表依赖于他。那怎么办呢?针对这种情况,总共有两种方法
1、先删除你子表,然后在删除父表,这样就达到了删除父表的目的,但是子表也要被删除
2、先解除外键关系,然后在删除父表,这样也能达到目的,并且保留了子表,只删除我们不需要的父表。在3.7中就讲解了如何删除外键关系。
数据表的设计原则:
( )不应针对整个系统进行数据库设计 而应该根据系统架构中的组件划分 针对每个组件所处理的业务进行组件单元的数据库设计不同组件间所对应的数据库表之间的关联应尽可能减少 如果不同组件间的表需要外键关联也尽量不要创建外键关联 而只是记录关联表的一个主键 确保组件对应的表之间的独立性 为系统或表结构的重构提供可能性
( )采用领域模型驱动的方式和自顶向下的思路进行数据库设计 首先分析系统业务 根据职责定义对象 对象要符合封装的特性 确保与职责相关的数据项被定义在一个对象之内 这些数据项能够完整描述该职责 不会出现职责描述缺失 并且一个对象有且只有一项职责 如果一个对象要负责两个或两个以上的职责 应进行分拆
( )根据建立的领域模型进行数据库表的映射 此时应参考数据库设计第二范式 一个表中的所有非关键字属性都依赖于整个关键字 关键字可以是一个属性 也可以是多个属性的集合 不论那种方式 都应确保关键字能够保证唯一性 在确定关键字时 应保证关键字不会参与业务且不会出现更新异常 这时 最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字
( )由于第一点所述的领域模型驱动的方式设计数据库表结构 领域模型中的每一个对象只有一项职责 所以对象中的数据项不存在传递依赖 所以 这种思路的数据库表结构设计从一开始即满足第三范式 一个表应满足第二范式 且属性间不存在传递依赖
( )同样 由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系 所以在领域模型中的对象存在主对象和从对象之分 从对象是从 N或N N的角度进一步主对象的业务逻辑 所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常
( )在映射后得出的数据库表结构中 应再根据第四范式进行进一步修改 确保不存在多值依赖 这时 应根据反向工程的思路反馈给领域模型 如果表结构中存在多值依赖 则证明领域模型中的对象具有至少两个以上的职责 应根据第一条进行设计修正 第四范式 一个表如果满足BCNF 不应存在多值依赖
( )在经过分析后确认所有的表都满足二 三 四范式的情况下 表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构 并且 我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的 只是一个存储介质 所以 表和表之间也不应用强关联来表述业务(数据间的一致性) 这一职责应由系统的逻辑层来保证 这种方式也确保了系统对于不正确数据(脏数据)的兼容性 当然 从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据 单从另一个角度来说 脏数据的产生在一定程度上也是不可避免的 我们也要保证系统对这种情况的容错性 这是一个折中的方案
( )应针对所有表的主键和外键建立索引 有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引 提高检索效率 虽然建立索引会消耗部分系统资源 但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响 以及无索引时的排序 *** 作所带来的性能影响 这种方式仍然是值得提倡的
( )尽量少采用存储过程 目前已经有很多技术可以替代存储过程的功能如 对象/关系映射 等 将数据一致性的保证放在数据库中 无论对于版本控制 开发和部署 以及数据库的迁移都会带来很大的影响 但不可否认 存储过程具有性能上的优势 所以 当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时 可经过平衡考虑选用存储过程
( )当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改 删除 更改异常所付出的代价 并且数据冗余也不是主要的问题时 表设计可以不符合四个范式 四个范式确保了不会出现异常 但也可能由此导致过于纯洁的设计 使得表结构难于使用 所以在设计时需要进行综合判断 但首先确保符合四个范式 然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法
( )设计出的表要具有较好的使用性 主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧
lishixinzhi/Article/program/SQL/201311/16156
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)