工程传奇——会飞的猪 数据结构SQLXML大众软件IT厂商

在空军之翼网站上有一篇文章叫给猪装上翅膀。标题党的厉害，实际上内容是很严肃的，讲的是隐形飞机的里里外外。第一代的隐形飞机是F-117 Nighthawk，的确是很雷人。很难想象，这副样子的东西，居然还能飞起来，还能打仗。从某种程度讲，它长得真有几分像一头猪，还长着翅膀。
f-117的身世还极具传奇色彩。研制的时候它的保密工作做到了家，造谣、掩盖、烟幕弹，都干过，甚至还出了款玩具欺骗大众，把地球人忽悠了十多年。废话少说，回到主题。F-117项目差不多开始于1975年，也是Skunk Works的 杰作。美国人在越战后想造一种能够躲过雷达侦测的战斗机。但是限于当时的计算能力，无法计算曲面的雷达反射特性，更不说复杂曲面和曲面的组合了。如果做模 型挨个试，纯粹大海捞针，况且雷达波反射测试费用不菲，不能像F-104那样用点战争剩余物资就能摆平的。结果洛马的工程师们做了很geeky的设计—— 用平面造飞机。既然平面的电磁反射特征是可以计算的，那么把各种不同形状的平面拼接起来，就有可能造出一架雷达难以探测的飞机。Skunk Works很快做出了一个模型， 并且验证了其隐身特性。那么这样的飞机能飞吗？很显然，它飞起来了。非但飞起来了，还正式服役到今年（今年8月份最后一架夜鹰退役）。在入侵*的作战 行动中扔下了第一枚，参与了海湾战争，空袭伊拉克，并在科索沃被击落一架。为了不被侦测到，F-117事实上付出了巨大的代价。不能超音速，不能做剧 烈机动，没有雷达，只能带两枚2000lb的。一旦被发现，打不了，也跑不了。
但是，作为第一种全面隐身的战斗机（实际上是攻击机，拿战斗机的名头糊弄人呢），F-117是相当成功的。最关键的，它达到了根本的目标——隐形战斗机。 首先，它能飞，而且飞的还不错。其次，能够战斗，它可以扔，尽管只有两枚。最后，它隐形了，雷达难以侦测。F-117的设计基于这样一个核心逻辑：无 论你多么强悍，如果看不见对手，一个小毛孩子拿着吉利刀片也能要你的命。只要达到隐形这个目标，即便有不佳的飞行性能和很少的载弹量，也足以发挥关键性的 作用。因而，F-117被用于针对关键目标的关键任务，就好比用剃刀割对手的颈动脉那样，一击致命。
从工程角度来讲，Skunk Works的工程师们主动地简化设计，降低目标要求。他们在当时技术条件的制约下，不追求完美的解决方案，把目标集中在关键性的特性（隐形）上。在其他方 面，主动放弃次要目标。这是典型的：make it run first。我们在设计软件时，有时会陷入最求完美的困境。要求更多的灵活性、适应性、扩展性、性能等等。最终，迷失在特性的海洋里。我们时常被告诫，先 实现80%的功能。而这80%的功能，通常都集中在20%的特性上。

假设我们需要开发一个基于web的查询平台，具体查询的内容和算法会随着客户的变化和需求的变化而变动，有时还会有现场快速实现的需求。同时所查询的数据 的结构具有动态的特征，有些数据的结构在运行时方能确定。基于这些要求，我们不能把查询写死在代码里，需要脚本化。又因为是web的应用，那么如果能够从 数据库中获得数据，直接转换成html片段插入页面，那么系统就会很容易实现和变化。实现这个任务最理想的做法是使用xml db之类的数据库，利用xslt或者xquery直接在数据上查询。但是，目前xml db并不成熟，性能也不如rdms。现在，我们有两种选择：开发成熟的，性能优良的xmldb；或者仍旧使用rdms，但利用一些辅助工具。很显然，前者 是愚蠢的行为。
最初，我们可以手工地写sql语句，然后把结果集组织成层次化的结构，提取出xml，再用xslt或者xquery处理，获得html。更好一些的方法， 利用现成的数据转换模块，诸如.net的DataSet，进行结果集组织和xml提取。这种设计所需的东西就在手边，可以很快实现。它的不足之处在于，必 须提取出所有的结果集数据，然后才能转换成完整的xml，在处理大数据量时，会有性能问题。做到这一步，我们可以分析一下，是否还需要更进一步地深入开发，增加功能。
首 先，这个方案是否容易变化。在这个方案中，实现查询的是一个sql命令和一个xslt stylesheet。前者用于从rdms中提取数据，并组织成xml结构。而后者则负责构造html，并处理一些在sql中实现困难的查询。两者都是用 于数据处理的DSL，相比通用语言，执行查询任务更加简洁方便。两者都可以组织在一个脚本文件中，都是文本，可以方便修改。
其次，是否能够现场快速实现需求变化。sql和stylesheet都可以脚本化，可以直接修改运行，无需编译，和ide的支持。
再次，能否处理运行时的数据结构变化。sql只能依赖固定的数据结构，这是在design time已经确定的东西。但是当sql查询获得的结果集转换为xml后，就成为半结构化数据，可以拥有动态的数据构造。而xslt则具备在这种构造上查询数据的能力。
最 后，再来看看性能问题。对于一般应用，查询获得的数据量不会，也不应当太多。对于人而言，成千上万条数据放在面前，也是无法处理的。所以，一般情况下，一 次查询返回的数据不超过3、5百条，大约30KB以内。这些数据量，转换成xml，然后再执行xslt转换，在普通的PIV 3.0/1G内存的系统上，0.1秒以内肯定可以完成。这点时间对于用户而言完全可以接受。更何况系统运行在web服务器上，执行时间会有数量级的提升。
但是，终究会有不少查询需要处理大量的数据。这 些查询中可以进一步分类。其中比较多出现的，是简单结果集，也就是一个sql查询获得的结果集就是用户需要的结果。这些结果集没有层次结构，完全就是一个 table。这样的查询，可以先分段，比如100条数据一段，把一段数据转换成xml，然后执行xslt，结果传送到客户端显示，然后再处理下一段。这 样，用户就不必等待数据全部提取并处理完成，几乎立刻就能看到数据，而后续数据，则利用用户阅读第一批数据的时间进行处理。这种分段处理机制可以很容易地 加入查询平台，无需很大的工作量。
至此，大部分的查询需求（差不多就有80%了吧）都得到覆盖。至于那些大数据量的有层次结构的数据，或者无法分段处理的数据，或者无法固定分段处理的数据，可以不做考虑。一旦用户需要，定制专门的模块处理。

F-117并不是“飞猪”故事的终结，而是开始。随着技术的发展，工程师们拥有了处理简单曲面的计算能力。于是，立刻将其运用到飞机上，B-2 Spirit诞 生了。无论如何，B-2看起来更像一架正常的飞机了，尽管它也不是一种常规的飞机。仅从数据上看，B-2强大的令人发指，最大起飞重量170吨，航程 11000km，载弹量22.7吨，可以携带几乎所有的美军现役，最新的改进，使得它能够同时扔下80枚，打击80个不同的目标。相对于F- 117，这已经是质的飞跃了。而尽管其身躯庞大，但隐身能力则比F-117更进一步。这也就是关键技术突破带来的必然结果。不过，B-2还不够，80年代后期开始，it技术的发展使得人们拥有了处理复杂曲面的计算能力。于是，美国人不惜血本地研发了终极战机——F-22 Raptor。F-22的能力只需一个数字便可说明：在美军组织的F-22vsF-15/16演习中，F-22取得了114:1的战绩。
这 三代隐形战机的成功故事再一次强调了工程中的一个经典实践：make it run first。在最初阶段，着力实现最关键，最核心的功能，而这些功能足以满足多数的应用需求。而其他方面的需求则暂时加以回避，或通过传统手段实现。随着 技术的发展和进步，那些外围功能的技术条件逐步成熟，相应的功能也会自然而然地得到实现。

随着xml及其相关技术的大规模应用，各大传统rdms厂商也逐步地在各自的数据库中引入xml相关的技术。比如xml/sql，for xml子句等等。这些技术可以使得我们直接在sql语句中将结果集构造成有层次结构的xml文档。利用这些技术，大数据量却拥有层次结构的结果集，以及无 法固定分段的结果集，都可以进行分段处理。在这些技术的作用下，真正无法在这个查询系统中实现的查询，变得很稀少了。此时，我们也可以近似地认为这个查询 系统可以满足所有面临的应用，而不必耗费更多的精力来实现剩下的这些千年一遇的需求了。

不过，在运用这种工程方法的时候，有一个先决条件：必须正确地识别关键目标特性。如果我们在查询系统的案例中，一开始把大数据量处理能力作为关键目标特 性，那么很显然，不会采用这样的设计，从而偏离真正的目标。对于关键目标特性的识别，可以通过考察需求，寻找那些满足最多需求的特性，加以排序分析。