摘要：经过15天的夜以继日的努力工作，一个复杂的数据库计算型的软件终于开始投入使用。在制作的工程中，笔者吸取了以前做软件的经验教训，在这次的软件设计与制作过程中把所学和所思的知识投入到实践当中，并取得了良好的效果（MSSQL
数据库）。本系列将讲述整个软件的核心部分，不论是初学者还是编程高手，笔者认为在这一个系列中多多少少都能学到一些东西。
首先从业务的需求来说，笔者所作的软件属于直销类的软件。直销是一种行业，在国外是合法的，在中国尚未在法律上规定为合法的。一提起直销，大部分人会想到可恶的传销，早在98年的时候开始打击传销，经过党和国家的大力宣传，把传销丑化的十分的可怕。笔者认为，传销有其合理的一面，传销中经常会有人被洗脑，就是一些牛人给你灌输一些思想，让你跟着他的意识走。而那些牛人常用的手段就是讲授成功学，成功学教会人们如何更好的生存，成功学本身并没有错，错就错在那些牛人把成功学用在非法的敛财上了，这就在人么内心目中导致了成功学就是传销这样一个歪曲的理念。传销顾名思义就是宣传销售，直销是一种商业模式，销售的对象是最终的消费者，而产品的来源就是其直接的生产商，这样便减少了中间的商业过程，为最终的消费者提供实惠的消费品。商家便利用这层关系来推动市场来赚钱…跑题了，
接着说需求，直销的制度有许多中，但是不变的就是返利计算，为最终的用户返回部分投资，这样便能吸引更多的客户来参与活动。这一次笔者所作的是一个队列+矩阵，队列就是排队，先进先出的队列，出来之后再进去，直到你进进出出共n此为止，每次出来都会得到一定的奖金，称之为分红。矩阵其实就是一个树壮结构，3叉树，二叉树，每次添加一个叶子节点，上面的节点都会有相应的奖金，队列+矩阵的这一部分只占了总工作量的20%，系统中这一个需求基本上能满足多个制度所需的功能。但是麻烦的是，系统中还有另外一个截然不同的制度需要搅和在一起，因此这就比较麻烦了。考虑到两种制度一个系统的复杂性，在设计数据表之前先定义了数据类型和默认值，这样在插入数据的时候这些默认值便可以起作用，并且如果在软件正式使用之前发现数据类型定义不能满足需求，比如原来是char(10)的现在需要修改为Char(20)，只需要修改类型的定义即可。数据表，视图和存储过程中可以使用自定义的数据类型，但是在函数的定义中不能使用自定义的数据类型，不知道为何。使用SQL脚本来定义数据库，使得数据库具有可重复性，在测试的时候比较方便。定义类型的SQL语句比较简单，如下：
--------------------D_M_ID--------------
exec sp_addtype D_M_ID, 'VARCHAR(16)', 'NULL'
go
--------------------D_PASSWORD--------------
exec sp_addtype D_PASSWORD, 'VARCHAR(16)', 'NOT NULL'
go
--------------------D_NAME--------------
exec sp_addtype D_NAME, 'VARCHAR(16)', 'NULL'
go
--------------------D_REGDATE--------------
exec sp_addtype D_REGDATE, 'datetime', 'NULL'
go
--------------------D_ZIP--------------
exec sp_addtype D_ZIP, 'VARCHAR(12)', 'NULL'
go
--------------------D_SEX--------------
exec sp_addtype D_SEX, 'VARCHAR(4)', 'NULL'
go
--------------------D_ADDRESS--------------
exec sp_addtype D_ADDRESS, 'VARCHAR(100)', 'NULL'
go
--------------------D_IDCARD--------------
exec sp_addtype D_IDCARD, 'VARCHAR(38)', 'NULL'
go
--------------------D_BANKCARD--------------
exec sp_addtype D_BANKCARD, 'VARCHAR(38)', 'NULL'
go
--------------------D_PHONE--------------
exec sp_addtype D_PHONE, 'VARCHAR(30)', 'NULL'
go
--------------------D_EMAIL--------------
exec sp_addtype D_EMAIL, 'VARCHAR(50)', 'NULL'
go
--------------------D_TINY--------------
exec sp_addtype D_TINY, 'smallint', 'NULL'
go
--------------------D_BIRTHDAY--------------
exec sp_addtype D_BIRTHDAY, 'dateTime', 'NULL'
go
--------------------D_BIT--------------
exec sp_addtype D_BIT, 'bit', 'NULL'
go
--------------------D_int--------------
exec sp_addtype D_int, 'int', 'NULL'
go
这些定义的类型基本上能满足大部分的需求，在数据由老系统进入新系统的过程中，曾经遭遇过字符串过长的问题，在此一定要提醒各位，数据类型的字符串或者数据大小范围不妨设置的宽松一些，以备使用。定义了数据类型后，把他们放在一个单独的文件中，比如types.txt,使用ue进行编辑也比较方便，最好能写注释，这样的话如果过了n天以后忘记了原来的设计思路，看到注释还能够回忆起来。在上面的设计中，可能有人会问为什么zip的设计的字符长度为12，6个不就够了吗？问得好，本来邮政编码都是六位，于是在WEB的控件输入框中设置maxlength=6不就解决问题了吗？这个回答貌似有道理，其实仔细想想，这是一方情愿的事情，你不能控制客户输入的内容，如果他输入6个汉字，也没有超出输入控件的设置范围，又或者问，我使用JavaScript检查，如果输入汉字，就不让提交。问得好，如果客户端把javaScript屏蔽掉的话，照样可以提交到服务器端，导致数据插入出错，又或者问，我在服务器端进行检查，这样问我就没有办法回答了，比如Struts,.net等很多软件支持客户端和服务器端的双重验证，这样虽然好，但是我觉得使用(Struts)那些软件来快速的开发人机界面比较慢，如果有黑客绕过浏览器，直接提交数据，那也没有办法。但是别忘了，杀鸡不用牛刀，除非是有名的网站才值得黑客攻击，大部分的网站被黑客攻击的可能性很小，我不愿意花费80%的精力来做20%的事情，所以干脆就设计为这样的。牢记二八原则，人生回过的比较宽松。
接下来的设计就是定义一些默认值，为什么要定义默认值？有一些业务规则需要如果不填写一些值他就需要一个默认值而不是空值，就是这么简单，典型的应用就是注册的时候需要一个注册的时间，取得系统的实践作为注册时间。为什么不把默认值直接写在创建表的SQL语句中，当然是可以的，但是，如果要修改默认值的话，每个相关的建立数据表的SQL语句都需要修改。插一句，为什么要使用SQL脚本来建表，使用SQL脚本建表具有可重复性，可测试性等优点。强烈建议初学者一定要学会使用 SQL脚本。不多扯了，看看建立默认值的SQL语句：
---------------tiny default----------
create default [tiny_default] as 0
GO
exec sp_bindefault 'tiny_default', 'D_TINY'
go
---------------regDate default----------
create default [REGDATE_default] as getDate()
go
exec sp_bindefault 'REGDATE_default', 'D_REGDATE'
go
---------------------------------------
create default [bit_default] as 0
go
exec sp_bindefault 'bit_default', 'D_BIT'
go
---------------------------------------
create default [int_default] as 0
go
exec sp_bindefault 'int_default', 'D_INT'
go
默认值创建以后，需要绑定到列上或者自定义的数据类型上，把默认值的创建放在一个单独的文件中default.txt以方便修改。在本设计中没有使用到check(约束)，因为业务规则会变化，或者以后做另外的系统的时候业务规则变化，就比较麻烦，把设计放的宽松点让生活更美好。
今天就先到这里，明天接着讲述数据表的设计，如果你能学到一些东西或者指出笔者的一些不足之处，笔者会十分高兴。
本文转自凌辉博客51CTO博客，原文链接http://blog.51cto.com/tianli/42011如需转载请自行联系原作者
lili00okok
