外键

–禁用约束： alter table XXX disable constraint XXX; –启用约束 alter table XXX enable constraint XXX; 来源： https://blog.csdn.net/qq_30189805/article/details/99288995

SELECT T1.TABLE_NAME, T2.TABLE_NAME AS “TABLE_NAME®”, T1.CONSTRAINT_NAME, T1.R_CONSTRAINT_NAME AS “CONSTRAINT_NAME®”, A1.COLUMN_NAME, A2.COLUMN_NAME AS “COLUMN_NAME®” FROM USER_CONSTRAINTS T1 INNER JOIN USER_CONSTRAINTS T2 ON T1.R_CONSTRAINT_NAME = T2.CONSTRAINT_NAME INNER JOIN USER_CONS_COLUMNS A1 ON T1.CONSTRAINT_NAME = A1.CONSTRAINT_NAME INNER JOIN USER_CONS_COLUMNS A2 ON T1.R_CONSTRAINT_NAME = A2.CONSTRAINT_NAME WHERE T2.TABLE_NAME = ‘表名’; 来源： https://blog.csdn.net/qq_30189805/article/details/99288678

1. 原始单据与实体之间的关系 　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。 在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。 　　　　　　 这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 　　一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键 　　(因为它无子孙), 但必须要有外键(因为它有父亲)。 　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专 　　家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核 　　心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3. 基本表的性质 　　基本表与中间表、临时表不同，因为它具有如下四个特性： 　　 (1) 原子性。基本表中的字段是不可再分解的。 　　 (2) 原始性。基本表中的记录是原始数据（基础数据

一 . 建立外键 　　一对一建立外键 外键名称 = models.OneToOneField(to='要连接的类名', to_field='字段') 　　一对多建立外键 外键名称 = models.ForeignKey(to='要连接的类名',to_field='字段') # 外键要写在一对多的 那个多的类 下面,比如一个老师对应很多学生,外键就要写在学生的下面 　　多对多建立外键 外键名称 = models.ManyToManyField(to='另一个类名') # 这个外键名称(属性)要写在其中一个类的下面,然后to=另一个类名, 这个外键就相当于第三张表(多对多建立外键必须通过第三张表) 二 . 多表查询(基于子查询) # models.py创建表 class Author(models.Model): id = models.AutoField(primary_key=True) name = models.CharField(max_length=16) age = models.IntegerField() # to后面加类名 to_field后面写类名中的字段名 这是一对一的外键写法 author_detail = models.OneToOneField(to='AuthorDetail', to_field='id') def __str__(self):

Django多表ORM设计规则 1. 关联表之间建议建立外键,但是可以取消关联关系(db_constraint=False) 2. 关联表之间的晚间字段建议采用对应类名的全小写 3. 采用关联表的主键或对象均能进行操作 ''' 书籍: Book: id name price publish_date publish author(多对多关联字段) 出版社: Publish:id name address 作者: Author : id name author_detail 作者详情: AuthorDetail : id age telephone info ''' 创建数据表(Models) # 一对多：出版社（一） 书籍（多，外键在多的一方，依赖于出版社） # 一对一：作者详情（一） 作者（一，外键在任意一方均可，一旦外键放在作者中，作者依赖于作者详情） # 多对多：作者（多）书籍（多）建立关系表（存放两个表的外键信息 => 将建表转化为关系对应字段） ​ # Book书籍：id name price publish_date publish(publish_id) class Book(models.Model): id = models.AutoField(primary_key=True) name = models.CharField(max_length=20)

　 关系表的操作语句： 以上一节中创建的书籍、出版社、作者、作者信息表为例进行： 增： # 一对一 # (1) 类属性外键关联，使用外键约束属性直接进行对象关联插入 author_detail_obj=models.AuthorDetail.objects.get( id = 4 ) author_obj = models.Author.objects.create( author_name = ' 脉动 ' , author_birth = '2010-10-10' , author_detail =author_detail_obj) # （ 2 ）外键关联的字段进行指定值插入 # author_obj = models.Author.objects.create(author_name=' 脉动 ', author_birth='2010-10-10',author_detail_id=4) # 多对一 # （ 1 ）类属性外键关联，使用外键约束属性直接进行对象关联插入 publish_obj=models.Publish.objects.get( id = 3 ) book_obj =models.Book.objects.create( book_name = ' 时光不散 ' , book_price = 22 , book_publisher =publish_obj

数据库设计难题的求教 最近在设计一个数据库，但是碰到这样一个难题，一直找不到合适的解决方案，希望有过类似经验的高手能够帮忙分析下，看有没有好的处理策略。 举个管道建设中的例子吧，同样有三个对象： 管道：起点连接对象，结束点连接对象，管道的其他属性信息 管件：管件名称、管件类型 设备：设备名称、设备编号、设备所属单位 关系是：管道的起点和终点连接管件或者设备，而设备和管件没有多少属性是相同的，所以不能合并，这时候表的关系应该如何建？ 目前的一种考虑是使用软关联，就是在管道的表里用4个字段，分别是起点对象类型和起点对象ID，终点连接类型和终点连接ID，但是数据库建模时这种关系无法用实体关系图合理的展示，也无法在数据库中用外键关系来描述，无法保证数据的完整性，所以感觉不是很好的解决方案，想知道大家有没有更好的思路。:) 提问者： Enjoy Everyday - 初学一级 最佳答案 其实不必追求实体关系图的合理，也未必非要用外键，虽然可以没有约束，但是依然可以由程序来很好的管理这些 不过非要追求这个的话，我以前倒是做过一个，效果也还可以，可以参考一下： 管道表里包括：起点连接管件ID、起点连接设备ID、终点连接管理ID、终点连接设备ID、其他属性信息 前面四个ID都是外键，管件ID和设备ID分别关联到各自的表，四个都设置为可空，这样在程序中或者select时判断一下到底取哪个

mysql的引擎问题： 　　需要知道的三个引擎：InnoDB--是一个事务处理引擎，不支持全文检索，支持事务操作，即DML操作； 　　　　　　　　　　　　Memory--是一个数据存储在内存，速度很快，功能上等同于MyIsam,适合于临时表； 　　　　　　　　　　　　MyIsam--是一个性能极高的引擎，支持全文检索，但是不支持事务的处理，没有声明的时候大多数默认是这个引擎！一般在不支持事务处理的时候用这个是比较好的！ 在创建表的时候，引擎这一块要值得注意一下，就是在做 主键和外键表的时候一定要做到 主键表的引擎和外键表的引擎一致的情况,都应该是inoDB引擎,否则外键创建不成功,因为存在事务关系 ，主键字段的类型，和设置的字符长度和外键的必须一致，否则会导致不能创建外键表的错误！ 来源： https://www.cnblogs.com/qiaohechen/p/11332974.html

原文： http://www.cnblogs.com/stephen-liu74/archive/2011/12/16/2290803.html 一、表的定义： 对于任何一种关系型数据库而言，表都是数据存储的最核心、最基础的对象单元。现在就让我们从这里起步吧。 1. 创建表： CREATE TABLE products ( product_no integer, name text, price numeric ); 2. 删除表： DROP TABLE products; 3. 创建带有缺省值的表： CREATE TABLE products ( product_no integer, name text, price numeric DEFAULT 9.99 --DEFAULT是关键字，其后的数值9.99是字段price的默认值。 ); CREATE TABLE products ( product_no SERIAL , --SERIAL类型的字段表示该字段为自增字段，完全等同于Oracle中的Sequence 。 name text, price numeric DEFAULT 9.99 ); 输出为： NOTICE: CREATE TABLE will create implicit sequence "products_product_no_seq" for

这几天，要开始面试了，数据库无疑是各家面试的重头之一，在此总结一下数据库的一些知识点。 数据库： 　　数据库表面上就是一系列的表格，包含的属性主要有： 约束： 　　 　　主键约束：唯一标志一个数据库 　　外键约束：用来连接标语表之间的关系 　　唯一性约束： 索引： 原理（B Tree / B+ Tree) 　　数据库对一个属进行普通的检索的时候，需要从头到尾进行遍历，直到查到相应的数据，如果数据量巨大的话则相应的开销也是相当大，不利于实际使用，于是索引诞生 　　对我们需要频繁进行查找的列进行设置索引，则，下次搜索的时候可以直接搜索索引一列，而不需要全盘搜索，又因为BTree的作用，可以将这其中的搜索时间呈指数式减少 　　比如： 有100000000条某数据，现在要在其中检索出某个数值，最差情况下要检索10000000次，而如果设置索引，根据BTree的深度，可以下降到10（B树的深度即需要检索的次数），甚至更少。 　　索引优点：可以更快的检索数据 　　既然索引这么方便，为什么不给每个列设置一个索引，以方便使用，这是因为，索引需要占据实际的物理空间，且每次对相应的列进行增删改的时候，都需要相应的修改索引，因此，在过多的不需要频繁查询的列设置索引只会增加维护的难度，总结：对索引进行查找省时间，索引占空间，维护耗时间。所以需要综合考虑，达到一个最完美的状态，少了达不到效果，多了增加消耗。