一对一双向外键关联

这个一对一双向外键关联要怎么理解，双方都持有对方的引用，也就是你中有我，我中有你。 

以前一篇的例子来说，学生方持有身份证类的引用，身份证类也持有一个学生对象的引用，这两个引用都充当各自表中的外键。

主控方的配置和一对一单向外键关联中的是一样的，不一样的地方是被控方。被控方的引用属性上边也要加上@OneToOne注解，其中要设置一下mappedBy属性，这个mappedBy属性指定了把控制权交给了主控方，这里要指定主控方对应的外键属性。 

这里要注意，双向关联，必须设置mappedBy属性。因为双向关联只能交给一方去控制，不可能在双方都设置外键保存关联关系，否则双方都无法保存。

之前的例子中，主控方Students类不需要改变，主要修改身份证类。加一个private Students stu并进行封装。注意对于前边的pid的注解是写在属性上边而不是get方法上边，所以stu的注解也是写在属性的上方，要保持一致。

    @OneToOne(mappedBy="card")
    private Students stu;

然后要注意在配置文档中进行配置

    <mapping class="oto_bfk.Students"/>
    <mapping class="oto_bfk.IdCard"/>

然后是测试类，测试方法不需要改变，结果没有问题。



一对一双向外键联合主键

联合主键需要借助主键类来实现 

首先我们要创建一个主键类，这个主键类要添加一个@Embeddable注解。 

主键类必须实现Serializable接口，重写hashCode和equals方法。

然后在创建一个实体类，在实体类所对应的联合主键属性上边添加@EmbeddedId这个属性级别注解

数据库mysql 
建立外键的前提： 本表的列必须与外键类型相同(外键必须是外表主键)。 
外键作用： 使两张表形成关联，外键只能引用外表中的列的值！ 
指定主键关键字： foreign key(列名) 
引用外键关键字： references <外键表名>(外键列名) 
事件触发限制: on delete和on update , 可设参数cascade(跟随外键改动), restrict(限制外表中的外键改动),set Null(设空值）,set Default（设默认值）,[默认]no action 
例如： 
outTable表 主键 id 类型 int 
创建含有外键的表：  create table temp(  id int,  name char(20),  foreign key(id) references outTable(id) on delete cascade on update cascade); 
说明：把id列 设为外键 参照外表outTable的id列 当外键的值删除 本表中对应的列筛除 当外键的值改变 本表中对应的列值改变。 
自己实践 才能完全了解外键的作用 关键是：事件触发限制的作用
转载于:https://www.cnblogs.com/zhujiabin/p/3735537.html

发生这种情况时，通常意味着两个外键相互链接。通常，包含键作为主键的表甚至不在架构中。
示例：两个表COLLEGES和STUDENTS都包含一个名为ZIPCODE的列。
如果我们快速检查一下
SELECT * FROM COLLEGES JOIN STUDENTS ON COLLEGES.ZIPCODE = STUDENTS.ZIPCODE
我们可能发现这种关系是多对多的。如果我们的架构中有一个名为ZIPCODES的表，且具有主键ZIPCODE，那么显然发生了什么。
但是我们的架构没有这样的表。但是，仅仅因为我们的模式没有这样的表并不意味着不存在这样的数据。在USPO土地上的某个地方，有一张桌子。而且，即使我们不认可该表，但COLLEGES.ZIPCODE和STUDENTS.ZIPCODE都是对该表的引用。
与构建数据库的实践相比，这更多地与数据的哲学有关，但是它巧妙地说明了一些基本知识：数据具有我们发现的特征，而不仅仅是我们发明的特征。当然，我们发现的可能是其他人发明的。ZIPCODE肯定是这种情况。

A表的主键在B表中充当外键，谁是主表，谁是子表？
A为主表
B为从表
个人认为：
外键是约束的一种。不存在主从关系，只存在引用关系，如部门表与员工表。
每个员工都属于某个部门，必须与某个部门资料对应。
主从表的情况：类似于订单表与订单明细表的关系。
希望以上有所帮助. 
有两个表 A表中的C字段里面的内容是B表中的主键,并且值有多个,请问数据库该怎么设计啊?
create table B
(
 C char(6) primary key,
 C_Name varchar(50) not null
)
go
create table A
(
 A_ID char(6) primary key,
 A_Name varchar(100) not null,
 C char(6) references B(C)    --将A表中C字段设置外键
)
go 
从表的外键与主表的主键的列名必须相同吗？值呢？
列名不一定要相同，但是外键的取值要么从主键的域中取要么取空值，这在数据库中叫做参照完整性规则。
 
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。 
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。 
主键：
  关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
        1. 惟一地标识一行。
        2. 作为一个可以被外键有效引用的对象。
  基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
        1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
        2. 主键应该是单列的，以便提高连接和筛选操作的效率。
       注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。
        3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
       注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。
        4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
        5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。

 
转载于:https://www.cnblogs.com/highmayor/archive/2009/07/15/1524289.html