摘要：接着昨天的数据库的数据类型定义和默认值设计,今天叙述数据表的设计。
昨天叙述了数据库的数据类型定义和默认值设计，由于业务规则的复杂性和商业上机密性，笔者不方便讲述需要定义的表的原因。只是在建表的过程中使用了定义的数据类型。数据表的定义不是很复杂，使用自定义的数据类型代替定义列的原始数据类型就可以了。在设计的过程中有一些需要思考斟酌的东西，就是数据表之间的关系，下面着重讲解一下几个重要的表。
会员注册的时候有一个会员信息表，他们的登陆信息需要保存在一个表中还是两个表中，如果是两个表， 比如member表保存基本信息，login表保存登陆信息，这两个表应该是一对一的关系。笔者在设计的过程中把会员的基本信息比如身份证，会员姓名等放在一起，把登陆信息放在另外的表中。理由有2，1.登陆表小，方便查询优化，2，为了应付以后可能的新的需求，比如要增加一个登陆信息，转到一个特定的能执行SQL的管理页面，就没有必要添加登陆对应的会员基本信息。实践证明这样是正确的，因为经常需要维护系统的数据，比如修改一些使用界面不能修改的东西，就可以使用这样的登陆来执行。下面是会员表的设计
create table member(
m_id D_M_ID,
name D_NAME,
sex D_SEX,
country D_NAME,
province D_NAME,
city D_NAME,
bank_name D_name,
bank_card D_BANKCARD,
bank_city D_name,
bank_site D_ADDRESS,
ID_CARD D_IDCARD,
mobile_phone D_PHONE,
phone D_PHONE,
E_MAIL D_EMAIL,
zip D_ZIP,
address D_ADDRESS,
user_level D_TINY,
regDate D_REGDATE,
constraint pk_member primary key(m_id),
)
go
另外一个就是奖金的信息表，奖金的种类有三十多种，对应每种奖金都建立一个表的话可能需要三十多个表，经过研究发现，奖金中有一些共同的特征，比如有ID号码，期数等，把这些信息可以综合在一个表中，使用一个奖金类型的列来进行区分，这样的话就需要两张表，一张表用于记录奖金所有的种类信息，另外的一张表用来记录奖金的具体信息。在查看个人奖金的时候可以使用视图来区分，以下就是 这两张表的设计，
create table award_about(
award_type int,
award_num int,
description varchar(100),
constraint pk_award_about primary key(award_type)
)
go
-----------------------award_level------------------
create table award_level(
al_id int identity(1,1),
m_ID D_M_ID,
turns D_TINY,
c_times D_TINY,
rm_id D_M_ID,
level D_TINY,
award_type D_TINY,
amount D_TINY,
money D_INT,
enabled D_BIT,
primary key(al_id)
)
Go
由于系统需要在每次结算的时候进行数据备份，如果计算错误的话，需要进行回退，这样就使得一部分表在每次结算之前必须存放在另外的一张表中，称之为软备份。系统需要设置一个保存点，这个保存点其实是一张表，里面记录了当前系统的一些全局的信息，比如当前所在的期。这个表需要在每次计算的时候进行备份，系统恢复的时候首先恢复这个表，然后根据这个表的信息恢复所有其他表的信息。这个表需要始终保持只有一行。
create table misc(
turns int default 1,
head int default 1,
tail int default 1,
leave_coins D_INT,
new_coins D_INT,
consume_coins D_INT,
c_times tinyint default 1,
max_level D_TINY,
deposition D_TINY,
locked D_BIT,
)
Go
历史纪录保存在下面的表中
create table misc_history(
turns int default 1,
c_times tinyint default 1,
head int default 1,
tail int default 1,
leave_coins int,
new_coins int,
old_coins D_INT,
new_shops D_INT,
consume_coins D_INT,
max_level D_TINY,
deposition D_TINY,
locked D_BIT,
regdate D_REGDATE,
constraint pk_misc_his primary key(turns,c_times)
)
Go
还有一个比较复杂的表就是有着父子关系的树状表，其中的一个列代表了父节点的ID,在此就不多说了，不完整的表示如下：
create table stock(
s_id D_INT identity(1,1),
ps_ID D_INT,
)
Go
整个数据库表的设计需要不断的调整，直到满足所有的业务需求之后才能最终定下来。定下来的时间越早越好，有经验的数据库设计师可以预测到可能的变化，然后作出相应的机动设置信息。这种经验是可贵的，需要不断的实践才能获得，绝非一朝一夕能学到的。
今天就先到这里，明天接着讲述数据视图的设计，如果你能学到一些东西或者指出笔者的一些不足之处，笔者会十分高兴。
本文转自凌辉博客51CTO博客，原文链接http://blog.51cto.com/tianli/42190如需转载请自行联系原作者
lili00okok
