数据库表设计感悟

前面零零总总的看了看一些规范。那么这里则要结合自己的实践谈谈自己的理解。

之前设计数据库的时候主要存在以下一些问题：

1.对于关系型数据库来说，如何开始设计？当然这里不是指常规的软件工程那样的步骤。就java而言，我所知道的就有，一种先在数据库中设计，然后建立相应的实体。另外一种就是采用数据关系映射的关系，直接用hibernate产品帮我们建表。前者是老牌程序员较喜欢的。后者是比较简便的办法，但是会违背一些性能规范，也就是带来性能的问题。在小项目里面应该还是影响不大的。此外，需要了解hibernate的映射规则，相关的注解等。

2.数据库的表名如何取？如何能够保证一致性，并且增强团队协作的能力？那么以后就确定一个标准，比如统一使用 tb_xxx，或者统一使用 t_xxx。

3.设计好数据库以后，如果不用hibernate帮我们解决查询的连接表的问题，我们需要自己手写很多的连接sql语句。比如我们用mybatis的时候，如何能够在看到让人望而却步的枯燥的代码中解放出来，也就是不写sql语句，同时保证性能。这就成了一个问题。不过目前能想到的还是用hibernate吧，并且配合它的关于合法性的一些注解，还解放了部分业务层的代码，何乐而不为？？

4.数据表字段名的确定，以及属性的确定。事实上，不是这里的命名，而是所有要命名的地方都存在命名的一个不确定性。这对需要很多命名的地方，如android 的页面设计，html的页面设计中都存在这样的问题。。属性的确定，则主要来自于内心的不自信，也就是练的比较少，不敢确定属性。。

5. 为了性能的需要，都推荐将外键约束舍去，而不在数据库中声明。这样的话会增加业务层的代码，也就是增加开发人员的任务。对企业级开发应该是适用的，但是对于个人的练习，应该以人为主。。嗯！！语言从低级到高级本质也就是为了亲人性，所以对待性能的问题，一定要有一定的忍耐度。。。

-------------------------------------------------------------------------------------------------------------------------

嗯，中间有点事情耽搁了一下。下面就上面的观点所代表的Hibernate的注解相关的API。经过不断的查找，总算找到了自己想要的信息：写的太好，地址。。才发现自己长期纠结的问题有个核心的问题就是映射关系的问题。一与一，多与一，多与多，单向与双向等等。。。

跟着这个大神的思路，将整个过程过一遍吧。写的实在是很感动。

首先，数据关系映射中两端的关系不分方向有三种，分方向有四种。即一对一，一对多，多对一，多对多。

但是，hibernate的所谓单向多向，并不是说代表方向问题，它的核心在于它的级联操作，代表的是数据操作问题。所以没有可比性。

多与一：

关于这种关系，在哪端维护的问题。思考一个老板记住员工容易还是所有员工记住老板容易就行了。这样做可以相对的冗余度要低一些。（也就是在多的一端。因为在多的一段增加的是属性列。而如果在少的一端维护，则要增加元组。开销肯定是要大一些的）。基于这个理念，多对一与一对多最终生成的表格是一样的。

但是需要注意，他们的级联操作逻辑是不同的。针对查询而言，多对一时，操作多时，可以将一查出来。一对多的时候，操作一可以将多查出来。针对插入而言，因为一与多都是在多的一端维护关系，所以，他们的关系存在一种不对等性。。如操作多的时候，并不知道一的枚举有哪些。

他们的构成：

cascade级联，意思是指两个对象之间的操作联动关系，即对象之间的连锁反应，只能影响数据更新操作。可选项有： all,none,save-update,delete。

为了解决单向级联方面的缺陷，引入了双向映射。它们的构成：

实现方式为：在多的一端的关联属性上加上 many-to-one,一对多在对应的一的关系上加上 one-to-many的映射。需要注意，理解方面 to 之前指的是this对象，to 之后指的是该属性对象。此外，这样的话会增加程序的冗余度。因为他实际上是即有元组的增加，又有属性列的增加。同时，它提供一个inverse参数。若为false（默认），表示本端可以维护关系。否则反之。且，多与一只有一方负责维护关系。推荐的是用一维护关系，但是又保证了数据间的对等性。最后，它映射的表字段会有所变化。

一与一：

实现方式有两种：一对一主键关联映射；以及唯一外键映射。

单向一对一的构成：