说明在设计数据库表时你是如何考虑的?
发布网友
共2个回答
懂视网
创建数据库里最基本的应该就是建表，建索引、存储过程等一系列操作了。谈到表就不得不谈到实体。
一、数据实体
什么是实体，客观存在并且可以相互区别的事物称为实体。这里我们就简单的把它理解为一个表吧，描述实体的特性，我们就把他们称为了属性。也可以说当我们把一个数据库表当作一个实体，那么它里面的所有字段是不是就是一个属性了呢？结果是肯定的。
二、实体间的联系
我想说的是，很简单，数据库里表跟表间的关系莫过于三种：一对一；多对多；一对多。
一对一其实就是说我们建的主表跟相关联的表之间是一一对应的，比如说，我建了一个学生基本信息表：t_student,然后我又建了一个成绩表，里面有个外键，studentID，学生基本信息表里的字段studentID和成绩表里的studentID就是一对一。
一对多，也是类似，我另外建一个班级表，而每个班级有多个学生，每个学生就对应一个班级，对班级来说当然就是一对多了。
多对多，我还举这个例子，我建个选课表，可能有许多科目，每个科目有很多学生选，而每个学生又可以选择多个科目。这就是多对多了。
三、基本表的完整性
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
这是基本表的完整性，也是它特有的。这里我想说的是，在数据库里还有几种表也是常用的那就是中间表和临时表。
1、中间表
中间表是针对多对多关系的，就比如做公交查询系统。里面有两个表，分别是车站表、线路表。这里我们起个名字叫：t_busstation 、t_road，根据常识我们也知道，一个站有多个线路经过，而每个线路又有多个车站，怎么才能将两个表联系起来呢，如果是一对一，一对多，我们一个表，两个表就可以将他们实现了，但是多对多呢，这样我们就必须借助中间表用来连接两个表。一般中间表都是有一个本表的自增主键，还有另外两个表的主键。中间表是没有属性的因为它不是一个基本表。
2、临时表
首先所使用的数据库要支持临时表。
临时表：其实就是那些以#号开头为名字的数据表，它主要是用来存放临时数据的，当用户断开连接但没有出去临时表里的数据时，系统会自动把临时表里的数据清空。这里要说一点，临时表是放在系统数据库tempdb中的，而不是当前数据库。
临时表总共是分两种：本地临时表和全局临时表。
（1）这里我们需要了解的就是，在数据库中本地临时表是以一个#开头的，这种临时表只对当前的数据库用户可见，而其他的用户是不可见的。当数据库实例断开后当然也就丢失了数据了，不管是显式清空还是系统回收。
（2）还有一个就是全局临时表。它是以“##”开头的，而且是对于所有的用户都是可见的，当你断开数据库实例连接时，只要还有别的系统项目在引用它，连着数据库，那么数据就存在，只有当别的系统也断开连接时，系统才会清除全局临时表的数据。
现在就来看看三大范式。
第一范式：如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.比如一个工人的基本信息表，里面有工人的工号，性别，年龄，这些属性都是不可分割的，所以这个表就符合了第一范式。
第二范式： 就是在第一范式的基础上延伸，使之表里的每个字段都与主键发生关系。假如一个关系满足第一范式,并且除了主键以外的其它字段,都依赖于该主键,则满足第二范式.
例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，这个列我们就可以把它删除。
第三范式：在第二范式的基础上更进一步，也就是为了实现表里的列都与主键列直接相关，不是间接相关。这个我们可以用“Armstrong 公理”中的传递规则来推理。
我们来看一下它的定义：
设U是关系模式R 的属性集，F 是R 上成立的只涉及U 中属性的函数依赖集。若X→Y 和 Y→Z在R 上成立，则X →Z 在R 上成立。因此我们就来看在网上搜索到的例子：例如:订单表(订单编号，定购日期，顾客编号，顾客姓名，……)，初看该表没有问题，满足第二范式，每列都和主键列"订单编号"相关，再细看你会发现"顾客姓名"和"顾客编号"相关，"顾客编号"和"订单编号"又相关，最后经过传递依赖，"顾客姓名"也和"订单编号"相关。为了满足第三范式，应去掉"顾客姓名"列，放入客户表中。
这里其实就是为了说明数据库的表里步要出现冗余，在顾客表里已经有了"顾客姓名"了，而在订单表里就别出现了，而直接根据顾客编号相关联就可以，否则造成资源浪费。
热心网友
数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！ 那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则： （1）、数据库设计最起码要占用整个项目开发的40%以上的时间
数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。 （2）、数据库设计不仅仅停留于页面demo的表面 页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。 （3）、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了 每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。 （4）、数据库设计时就要考虑到效率和优化问题 一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。 （5）、添加必要的（冗余）字段 像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。 （6）、设计合理的表关联 若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。 （7）、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联 这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。 （8）、选择合适的主键生成策略
