技术背景：

 在开发程序过程中涉及到相关数据信息的系统软件都离不开数据库，在设计数据库时往往都是先搞好系统的业务逻辑以及业务功能需求，经过千思百虑后有了数据库的整体设计方案后，开始建每个模块涉及的表信息。

在建表时考虑到整体系统的结构设计，规划好了表的结构设计后开始建表信息属性，但也在表的性能设计方面总会有所欠缺，比如表的字段命名规范不，属性说明有没有具体提示，设计字段类型时考虑到用哪一种类型是否合理以及字符长度等。更小的数据类型使用了更小的磁盘空间，内存和cpu缓存，而且需要的cpu周期也更少。都需要考虑一翻或者考虑好了但在开发设计程序过程中又发现不合理，又的重新修改还是有点麻烦。所以何不在设计表的同时有一种智能提示的方法这样解决表的整体是否合理性，以及表的性能最佳。

方法内容：

   在涉及到的数据库时根据数据库底层函数创建一些标准的表的SQL语句来定义一个表的最佳合理性，存储到数据库建模中然后通过用户来创建表时的SQL语句进行判断比对每个表的各个属性设置。

1.表的名称必须是易于理解，能表达表的功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。 表名称不应该取得太长一般不超过三个英文单词。

对于有主明细的表来说，明细表的名称为：主表的名称 + 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts。只要判断到命名不合理就给出不合理的说明并且给予一个完整正确的例子来让用户按照规范性来写。

表必须填写描述信息，如果没有描述就进行给予用户提示。

2. 表字段采用有意义的字段名，字段的名称必须是易于理解，能表达字段功能的英文单词或缩写英文单词，单词首字母必须大写，一般不超过三个英文单词。例如:人员信息表中的电话号码可命名为：Telephone。产品明细表中的产品名称可ProductName表示。然后根据自动判断检测SQL语句如果检测到的字段设计不合理就给予不合理的醒目提示以及给予一个合理的字段设计规范例子让用户规范化。

  涉及到字段ID用于标示唯一性和程序内部用到的标示性字段，系统中属于是业务范围内的编号的字段，比如客户编号的需要以Code来标示。数据类型的选择要考虑什么样的数据字段要选择什么样的类型，比如ID字段的要选择Int或number类型，Name字段要考虑使用varchar、char还是Nvarchar。还有时间字段选择长时间还是短时间类型等，判断检测到字段属性命名和字段的类型不合理时就进行醒目提示解释不合理性并给予一个合理的使用建议。当字段定义为字符串型时建议使用varchar而不用nvarchar等。

有默认值的，字符型的默认值为一个空字符值串；数值型的默认值为数值0；逻辑型的默认值为数值0；类型的字段没有默认值，必须为NULL。

3. 数据库中每个字段的描述

表内的每一个值只能被表达一次、表内的每一行都应当被唯一的标示、表内不应该存储依赖于其他键的非键信息 、如果字段事实上是与其它表的关键字相关联而未设计为外键引用，需建索引。 如果字段与其它表的字段相关联，需建索引。

如果字段需做模糊查询之外的条件查询，需建索引。 除了主关键字允许建立簇索引外，其它字段所建索引必须为非簇索引。 字段必须填写描述信息。这样循环判断直到建一个完整而且设计合理规范化并且性能良好的表，这样不仅对于我们开发系统性能上优化以及良好的体验外甚至对以后维护工作带来方便而且还培养了我们设计数据的良好习惯。

 

方法流程：