数据迁移的时候，往往会碰到旧系统的人员身份证数据是15位的，或是经办人员接受的是15位的身份证，而统一18位的身份证是未来系统的方向，因此，数据迁移需要将15位身份证转为18位身份证，这里在网上搜索了一个15位身份证号码转18位身份证号码的函数，稍作了下改动。
create or Replace function CardTo18(p_OldID varchar2) return varchar2 is
-- Author : XJG(xjg@netsky-tech.com)
-- Created : 2003-11-03 18:38:56
-- Purpose : 从原有的15位身份证号转换成新的18位
-- Modify : 只转换身份证号为15位的情况，非15位不处理
type TIArray is table of integer;
type TCArray is table of char(1);
Result varchar2(18);
W TIArray;
A TCArray;
S integer;
begin if Length(p_OldID) = 15 then
W := TIArray(7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2, 1);
A := TCArray('1', '0', 'X', '9', '8', '7', '6', '5', '4', '3', '2');
Result := SubStr(p_OldID, 1, 6) '19' SubStr(p_OldID, 7, 9);
S := 0;
begin for i in 1 .. 17 loop
S := S + to_number(SubStr(Result, i, 1)) * W(i);
end loop;
exception when others then return '';
end;
S := S mod 11;
Result := Result A(s + 1);
end if;
return(Result);
end CardTo18;
在数据库中结合SQL可把15位身份证全部转换为18位，而18位的身份证忽略不处理。
Update person Set idcard=decode(length(idcard),15,cardto18(idcard),18,idcard,idcard) Where Rownum<21;
2008年8月22日星期五
2008年8月6日星期三
软件设计师
进公司已经一年了，想当初，刚进公司开始做项目，就被告诫大家以后要当自己是一个软件工程师...
回想这一年来，自己所学到的东西有多少呢？软件设计？框架改造？过程改进？需求变动？旧数据处理？这一年里，自己有很多的想法，可惜都没有付诸于实施--那不白说！可是，哪天老总问起来说：你跟我谈谈做软件这段时间以来有哪些想法吗？怎么谈？
这里，就随便谈谈内心的想法吧，算自己做软件一年来的一点记录。
1.需求是软件的灵魂
做软件，一定要真正理解用户要的是什么，否则设计根本无从谈起。一年来金保工程这个项目，很多子系统到了项目试用的时候再大改，甚至是重新开发，主要有两方面的原因：第一，软件需求当初就没有明确，甚至连需求调研的人都不了解业务，这就造成软件理解一环完全确实，软件根本无从做起。第二，政策变动，政策的变动造成了前期提出的软件需求不再适应后期政策的需要，流程不得不进行变动。
需求是变化的，不可能一步到位，这也是软件开发过程中经常碰到的一个问题。因此，软件经常改，为了应对软件需求的变动性，必须从其他方面来加以协调和弥补。包括记录客户需求变更以由项目组进行审议是否接受；根据软件螺旋模型修改应用系统；保存软件设计的弱耦合性和可配置性。
2.软件设计是软件的生命
软件工程师负责软件编码，软件设计则是软件设计师的职责。
第一：总体设计
软件系统总是面向用户的需求，这里不是讲编码的时候，不去考虑编码，而要考虑业务流程与数据来源、数据输出。
(1)业务流程：就金保工程软件来讲，业务流程主要从政策文件体现出来，这点在前几个月深有体会，政策文件相当重要，它规范化了一些重要的办事流程，是我们理解业务的最好材料。
(2)数据来源：数据来源一部分来源于政策文件的附件，一部分来源于政策文件的描述，一部分来源于与客户的交流，根据客户的描述而衍生出来的一些参数性数据，最后还来源于报表的提示，包括年份、日期、时间、金额等衍生出来的统计性数据。还有些数据是由用户上传和导入的，如EXCEL表格，公示性文件，照片，声音，视频等各种格式的数据。
(3)数据输出：数据处理后会流向几个地方，如应用系统的数据库、生成报表、数据打印、数据查询、数据导出到文件等等。
总体设计要保证数据流闭合，不出现数据丢失、不造成垃圾数据。
第二：软件的详细设计
(1)数据库的设计
数据库设计无疑是十分重要的，良好的数据库设计是一门学问。在公司的开发模式中，不推荐使用外键，而数据间的引用关系放在中间层来处理，这是为了避免外键过于复杂而采用的一种方式，但也造成了数据冗余比较严重，当然，适当的数据容易还是很必要的。简言之，数据库设计要做到:适度冗余、关键索引、数据表划分明确、对于业务表，经常要加入时间元素和经办历史。
(2)软件功能模块设计
功能模块设计是系统编码的核心，一切遵循：结果正确，操作相关，体验良好这个就可以了。
第三：软件编码
编码过程其实占用的时间不多，而且很多开发工具能自动生成代码，编码主要的时间也许花在页面设计和文本替换上面。
软件编码应该做好注释，否则其他人很难看懂，这将为软件移交造成难题。因此，必须在关键算法的地方或是业务复杂的地方做好注释。
软件编码是一个比较注重细节的环节，数据准确性验证应从页面、中间层、数据库数据类型层层把关。
3.软件测试是软件的质量保障
4.文档是软件产品的一部分
暂时写这么多吧，有时间继续。。。
回想这一年来，自己所学到的东西有多少呢？软件设计？框架改造？过程改进？需求变动？旧数据处理？这一年里，自己有很多的想法，可惜都没有付诸于实施--那不白说！可是，哪天老总问起来说：你跟我谈谈做软件这段时间以来有哪些想法吗？怎么谈？
这里，就随便谈谈内心的想法吧，算自己做软件一年来的一点记录。
1.需求是软件的灵魂
做软件，一定要真正理解用户要的是什么，否则设计根本无从谈起。一年来金保工程这个项目，很多子系统到了项目试用的时候再大改，甚至是重新开发，主要有两方面的原因：第一，软件需求当初就没有明确，甚至连需求调研的人都不了解业务，这就造成软件理解一环完全确实，软件根本无从做起。第二，政策变动，政策的变动造成了前期提出的软件需求不再适应后期政策的需要，流程不得不进行变动。
需求是变化的，不可能一步到位，这也是软件开发过程中经常碰到的一个问题。因此，软件经常改，为了应对软件需求的变动性，必须从其他方面来加以协调和弥补。包括记录客户需求变更以由项目组进行审议是否接受；根据软件螺旋模型修改应用系统；保存软件设计的弱耦合性和可配置性。
2.软件设计是软件的生命
软件工程师负责软件编码，软件设计则是软件设计师的职责。
第一：总体设计
软件系统总是面向用户的需求，这里不是讲编码的时候，不去考虑编码，而要考虑业务流程与数据来源、数据输出。
(1)业务流程：就金保工程软件来讲，业务流程主要从政策文件体现出来，这点在前几个月深有体会，政策文件相当重要，它规范化了一些重要的办事流程，是我们理解业务的最好材料。
(2)数据来源：数据来源一部分来源于政策文件的附件，一部分来源于政策文件的描述，一部分来源于与客户的交流，根据客户的描述而衍生出来的一些参数性数据，最后还来源于报表的提示，包括年份、日期、时间、金额等衍生出来的统计性数据。还有些数据是由用户上传和导入的，如EXCEL表格，公示性文件，照片，声音，视频等各种格式的数据。
(3)数据输出：数据处理后会流向几个地方，如应用系统的数据库、生成报表、数据打印、数据查询、数据导出到文件等等。
总体设计要保证数据流闭合，不出现数据丢失、不造成垃圾数据。
第二：软件的详细设计
(1)数据库的设计
数据库设计无疑是十分重要的，良好的数据库设计是一门学问。在公司的开发模式中，不推荐使用外键，而数据间的引用关系放在中间层来处理，这是为了避免外键过于复杂而采用的一种方式，但也造成了数据冗余比较严重，当然，适当的数据容易还是很必要的。简言之，数据库设计要做到:适度冗余、关键索引、数据表划分明确、对于业务表，经常要加入时间元素和经办历史。
(2)软件功能模块设计
功能模块设计是系统编码的核心，一切遵循：结果正确，操作相关，体验良好这个就可以了。
第三：软件编码
编码过程其实占用的时间不多，而且很多开发工具能自动生成代码，编码主要的时间也许花在页面设计和文本替换上面。
软件编码应该做好注释，否则其他人很难看懂，这将为软件移交造成难题。因此，必须在关键算法的地方或是业务复杂的地方做好注释。
软件编码是一个比较注重细节的环节，数据准确性验证应从页面、中间层、数据库数据类型层层把关。
3.软件测试是软件的质量保障
4.文档是软件产品的一部分
暂时写这么多吧，有时间继续。。。
订阅：
博文 (Atom)
