您的位置:首页 > 其它

机房收费系统验收总结

2012-12-02 14:14 267 查看
一、机房收费系统功能验收
1、对于学生注册中,像学生“性别”这种必选同时又是固定选项的类型的下拉菜单,应该有一个默认值。还比如说学生注册用户类型“固定用户”“临时用户”都应该有一个默认类型。

2、主窗体的大小设计存在问题,主窗体的变换不能够影响主界面的视图效果(应该始终显示在主界面中央)。对于为注册的用户上机提示信息之外还应该清空上一个上机用户的信息。

3、基本数据设定中对于金额类型的设定存在问题,我测试的时候时候的类型是char(10)。给以后计算上机费用的过程中带来了很大的麻烦。char等的扩展如下:

char

char是定长的,也就是当你输入的字符小于你指定的数目时,char(8),你输入的字符小于8时,它会再后面补空值。当你输入的字符大于指定的数时,它会截取超出的字符。

nvarchar(n)

包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍。所输入的数据字符长度可以为零。

varchar[(n)]

长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度,而不是 n 个字节。所输入的数据字符长度可以为零。

①CHAR。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间。

②VARCHAR。存储变长数据,但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢?这一个字节用于保存实际使用了多大的长度。

从空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点。

③TEXT。text存储可变长度的非Unicode数据,最大长度为2^31-1(2,147,483,647)个字符。

④NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道字符中,英文字符只需要一个字节存储就足够了,但汉字众多,需要两个字节存储,英文与汉字同时存在时容易造成混乱,Unicode字符集就是为了解决字符集这种不兼容的问题而产生的,它所有的字符都用两个字节表示,即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来,nchar、nvarchar则最多存储4000个字符,不论是英文还是汉字;而char、varchar最多能存储8000个英文,4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字,较为方便,但在存储英文时数量上有些损失。

所以一般来说,如果含有中文字符,用nchar/nvarchar,如果纯英文和数字,用char/varchar。

4、针对于退卡窗体中,犯了两个错误(见下面)。对于第一个错误给人复杂的感觉,总是不必要出现提示信息;第二个错误,是致命的,用户或者管理员不能清晰的看到用户退卡信息。

①退卡成功后出现提示信息;

②确定提示后该卡的信息自动清空。

5、同样对于充值和退卡窗体是一样的问题。

6、学生修改信息窗体中学生卡号是万万不能够随意修改的。因为一个饭卡一个固定的卡号,这个该后就不能继续使用原来的卡上机了。


二、机房收费系统思想

针对于这次机房收费系统验收的最主要目的就是这里了。第一次做机房收费系统大家都是照葫芦画瓢,大概功能谁都能够实现,最重要的就是最软件的思想。将自己想象成一个机房收费系统软件的使用者,从使用者的角度出发来怎么样做这样一个系统,大的方面该做到哪儿能够服务到位,小的细节该怎么提现的贴心。

一段坎坷的历程终于算是过去了。能够全身心地投入到下一阶段的学习中了。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: