二 面向用户，才是关键
回首自己两年多的编程生涯，我感觉除了知识水平的局限，制约程序员个人发展的一个重要因素，恰恰是“技术至上”。
记得当初给唐山国土资源局开发DigitalLand OA的时候，软件设计说明书中赫然写着“本系统采用先进的B/S架构，可大大降低系统的部署成本...使用面向对象的方法开发，对于系统的可维护性和可扩展性...”。
然而，我们扪心自问，OO和B/S对于用户来说，真的有那么大的吸引力吗？还是只是我们刻意的炒作呢？
给唐山国土资源局作系统实施的时候，我发现很多规划处的用户宁可使用中地公司用MapGIS开发的规划软件，而不是我们的系统，令我十分困惑。无论是软件的功能，数据的完整性还是软件的总体技术水平，我们的系统是绝对不输MapGIS的，客户有什么理由“弃明投暗”呢？规划处的王处长是这么说的：
“也许你们系统的技术水平确实比MapGIS高，可是我们还是觉得MapGIS用得顺手，你们的系统操作太复杂了...你和我们说的什么OO，什么S，什么数据完整性，我们也不明白，我们用系统，只要好用就行了。”
最后的结果是，我们被迫对系统的界面和操作方式做了若干的改动，系统才勉强得以实施。可是在唐山，包括吉林、东莞和河南项城，还是有N多的用户对MapGIS的规划系统和开思的绘图功能念念不忘，令我们大感困惑——我们，中国技术水平最强的GIS公司（无论是资金，还是人员，我都绝对不是吹牛），竞争对手居然是两个名不见经传的公司，真是匪夷所思！
也许这两个软件的数据完整性，安全性等方面的确存在一些瑕疵，但瑕不掩玉，系统的操作方式和方便性，确实值得我们学习。例如图形的外延功能，一座房屋，需要画出沿房屋轮廓外延2米的图形，在我们的系统中，需要进行一些复杂的操作才能实现，而在MapGIS中，只需选中房屋的面层，进行一次操作就能完成。
坦率的说，那次的事情对我的触动很大，刚刚毕业的时候，我总是觉得好的设计，良好的编码，数据的完整性和系统的安全性，是一个软件成功的关键，这件事情之后，我觉得只有满足客户的要求，才是一个软件最重要的目标。还是用数据库设计来举例吧，我们都知道，数据库的设计，要求满足范式，以消除数据的冗余和不一致性，可是是否完全满足数据库范式的系统，才是好的系统呢？或者说，好的应用系统，是否要满足所有的数据库范式呢？答案是否定的。两年的编程生活告诉我，一个得以顺利实施的应用系统，其数据库设计常常是在一定程度上违反数据库范式的；而完全依照数据库范式设计的应用系统，很多恰恰不能顺利实施。
难道数据库范式是没有意义的吗？难得大学中所学的数据库原理课程，都是老学究的空想？
当然也不能走这个极端，一个良好的数据库设计，常常是以数据库范式为基础，依照系统具体情况，做出适当的让步。
例如：
方案A：
table:employee
=============================================
name gender nativeplace position
---------------------------------------------
Doe,John 1 1 4
Doe,Jane 0 2 5
blue 1 3 6
table:gender
==================
genderid gender
------------------
0 F
1 M
table:nativeplace
=====================
cityid cityname
---------------------
1 Boston
2 New York
3 Tianjin
table:position
=====================
positionid position
---------------------
4 Saleman
5 CFO
6 SDE
方案B
table:employee
=============================================
name gender nativeplace position
---------------------------------------------
Doe,John M Boston Saleman
Doe,Jane F New York CFO
blue M Tianjin SDE
table:gender
==================
genderid gender
------------------
0 F
1 M
table:nativeplace
=====================
cityid cityname
---------------------
1 Boston
2 New York
3 Tianjin
table:position
=====================
positionid position
---------------------
4 Saleman
5 CFO
6 SDE
以上，就是一个HR系统中雇员表的两个设计方案。
方案A依照数据库范式进行设计，将籍贯，职位，性别等信息抽取出来，建立字典表，通过主键和雇员表连接。可是你有没有想过这么做有什么缺点吗？我们的例子中涉及到的字典字段是三个，那么，如果有十个呢？三十个呢？也许你觉得这根本不可能发生，可是shit may happen！如果依照这个方案设计数据库，当你需要检索一个雇员的相关信息时，也许会这么做:
select emp.name,gender.gender,city.cityname,position.position
from employee as emp,gender as gender,nativeplace as city,position as position
where emp.gender = gender.genderid and emp.nativeplace = city.cityid and emp.position = position.positionid
哇～是不是比较复杂呢？闭上眼睛，想象一下，一共三十个字典表...额滴神啊~
这种方案不只实现复杂，在实际运行的时候，还可能造成系统服务器的巨大开销。
okay，我们再来看看第二种方案，那边的兄弟说了，你这个东东好像不符合数据库3NF哦，这个...不错，不过请听我慢慢道来。
我们设计字典表的目的是什么？为了防止数据的不一致，否则employee的position字段中，SDE也是软件开发工程师，或者你也可以写全称software developing engineer，明明是一个含义，统计的时候却会有两条记录。可是，维护数据的唯一性，是不是只能通过插入外键呢。我们换一个方法，我们在程序的窗体上放一个combobox，将dropdownstyle设置为dropdownlist，在窗体加载的时候，对combobox中的内容进行动态绑定，这样不是也能控制客户输入有效的数据吗？区别只是在插入数据和更改数据的时候，是传入combobox的SelectedIndex还是SelectedValue的问题。至于取得一个雇员的信息:
select * from employee
爽吧？呵呵，不只是写着过瘾，运行速度也绝对比方案A快很多。且对于数据的查看次数大大多于插入和更改的次数的情况，尤为有效。
并不是所有的客户都知道OO，B/S，数据库范式是什么东东，系统的界面漂亮，功能好用，运行速度快捷，确实客户可以切实感受到的。
