SIGMOD会议位列数据库方向的三大顶级会议之首（其次是VLDB及ICDE）。2019SIGMOD于6月30日至7月5日在荷兰阿姆斯特丹举办。本文由OceanBase团队为读者带来最权威、最前沿的大会独家报道。 SIGMOD是数据库方向的三大顶级会议之一（另外两个是VLDB及ICDE），2019 SIGMOD于6月30日至7月5日在荷兰阿姆斯特丹举办。阿姆斯特丹是一个非常美丽的城市，以郁金香、运河、风车、梵高等闻名于世。今年的SIGMOD在欧洲举行，参加的总人数相比往年更少，欧洲本土的参会人员相比往年更多。OceanBase团队的核心成员也有幸亲临现场参加了这一数据库的盛会。 OceanBase展台前聚集了来自世界各地探讨技术的参会者 随着SIGMOD每年在世界各地的召开，我们越来越能感受到OceanBase在华人学者工程师中的知名度越来越高。很多同学已经了解到OceanBase在诸多金融机构拥有了很多落地应用的案例，甚至还有欧洲同学希望来到千里之外的中国来做OceanBase的intern。我们也愈发感受到，华人在数据库领域正在逐步形成一股不可忽视的力量。 SIGMOD分为Research Session和Industrial Session。其中，Research Session总共提交了430篇文章，录用88篇，录用比例为22%；Industrial Session提交了53篇论文，录用了16篇。整体上看，今年的SIGMOD算是一个小年，很难看到让人眼前一亮的论文。 最重磅 | 两大议题：机器学习&区块链 今年的两个Keynote分别是：Lise Getoor的“Responsible Data Science”，以及C. Mohan的“State of Public and Private Blockchains：Myths and Reality”。 这两篇论文都和传统的数据库关系不大，第一篇是机器学习相关，近年来一直都是SIGMOD的热点，第二篇是区块链，今年的SIGMOD还专门加入了一个区块链的专场。 C. Mohan认为联盟链比较有前景，不过台下有人提问反对，认为不能因为公有链比较难就回避问题，而是应该投入精力去研究。 最权威 | 最佳论文/奖项花落谁家 SIGMOD 2019的十年最佳论文（Test of Time Award）颁给了—— Privacy Integrated queries: an extensible platform for privacy-preserving data analysis 关于数据管理中的隐私性处理的文章。这也符合这两年全社会对于互联网大数据时代隐私保护的关注，Google和Facebook等互联网巨头，都在美国和欧洲受到相关监管机构的挑战。 SIGMOD还有一个奖项叫做System Awards，2015到2018年的获奖者分别是Postgres（2015），MonetDB（2016），SQLite（2017），Hive and Pig（2018），今年的获奖者是Aurora（2019）。可以看出，这些系统都具备世界范围内的影响力，我们也期待未来中国的系统能够获得该奖项。 最独家 | Anastasia荣获终身成就奖 今年的E.F. Codd Innovation Award给了Anastasia Ailamaki，这一奖项类似于数据库研究领域的终身成就奖，表彰对于数据库研究事业做出了重要贡献的人士。 Anastasia Ailamaki是EPFL的教授，在University of Wisconsin-Madison获得的PhD学位，是David DeWitt和Mark Hill两位数据库和计算机体系架构方向大牛的弟子，她提出了一个很有意思的话题——Architecture-conscious data management。 她认为除了扩展性以外，单线程的极致性能在数据库的实现中是至关重要的一点，而要做到这一点，数据库的系统架构，编码设计都需要充分考虑到计算机体系架构的特点，1998年就提出了这些方向的话题和研究，然而20年过去了，这方面的工作反而并不见提升，相关研究方向的学生越来越少，工程产品实现的性能也不尽如人意。 大家对于计算机编程的理解越来越往上而不是往下走了，很少有人能做到一个配合体系架构的更好性能的设计和实现。这其实也是我们日常工作中常常会思考到的一个问题，实事求是的说，我们今天的系统软件开发者可能在对底层体系架构的理解，反映到上层编码实现上是存在着理论知识和实践经验的缺失。 最全面 | 四大研究领域论文全解读 从大的方向来看，院校学术研究方向，以欧洲（慕尼黑工大TUM，CWI等）和亚洲院校（NUS, HKUST）为代表，主要在做一些新硬件，列存，in-memory，向量引擎编译执行方面的工作和传统的数据库优化的方向，开源社区在更加积极的拥抱SQL，传统商业数据库公司忙着进行数据库的云化，MS在本次会议上关于数据库上云一气提出了三篇相关paper，结合Oracle 19c的新功能开发点来看，都是围绕着在云上部署和自动运维，管理数据库而展开工作。整体来看也确实符合当下数据库研究的趋势以及工业界的发展现状。 然而传统关系数据库内核的突破性工作变得越来越少，很多研究工作是多个领域相结合的成果。云数据库、新型硬件，自治数据库、AI+数据库、图数据库，以及今年新增的区块链，这些都成为了SIGMOD 2019讨论的热点。接下来我们从参会关注的角度，分别列举一些会议的论文以飨读者。 研究领域一：学院派数据库1.Cache-oblivious High-performance Similarity Join这篇论文，如前述Anastasia所述的针对计算机体系架构进行数据库的设计这个方向，是要解决在当前内存数据库的情况下，传统的IO bound不再是瓶颈的情况下，如何使得算法能够更好的适应三级缓存，CPU寄存器以及TLB表，从而能够做到cache-oblivious的去解决similarity join的问题，比如关系数据库中会用到的band join(Oracle 12c也有实现)，N-way join等。更进一步的，相比于大部分实现仅是做到cache-aware，修改算法去适配已知的cache大小去达到更好的性能，在系统硬件变化，或者有多个用户争抢不能确定可使用缓存大小的前提下，做到cache-oblivous的情况下同样能够高效的实现算法执行。 主要的贡献就是提出了采用F(ast)G(eneral)F(orm) Hilbert curve join的方法，充分的发掘SIMD、MIMD的能力，做到高效的执行。实验显示，runtime和cache miss都大幅好于现有的算法。下一步他们计划在更多的数据库算子，比如k-nearest neighbor, N way-join上采用类似的算法，从而可以高效的利用CPU缓存和寄存器，实现极致的算法性能。这篇论文其实对于工业界的数据库实现来说是一个很好的工程实践的例子，相关的算法实现有非常好的参考价值。 2.Hyperion: Building the Largest In-memory Search Tree这是继去年SIGMOD Best Paper之后，又一篇讨论以Trie的方式来实现数据库的索引结构的论文。大家知道通常来说，最常见的数据库索引有B+ tree, hash, bitmap等，最近这些年对以Trie来实现数据库索引有不少的研究在投入，主要想要达到的目的是做到一个效率和内存使用的平衡。效率上要做到对范围查询和点查询都能够有比较好的支持。本篇论文的主要贡献在于通过减少额外开销，减少内部分片和优化内存管理的实现，达到了一个极优的点查询性能和不错的范围查询性能，同时内存使用比其他同类的实现要大大的降低。这也是索引结构实现的又一个有意义的尝试。 3.Designing Distributed Tree-based Index Structures for Fast RDMA-capable Networks这篇论文介绍了在当今大集群，大内存的情况下，分布式场景中，如何更好的利用这一硬件特性，构建分布式索引并采用RDMA技术来进行性能加速的思想。在当前的Network Attached Memory(NAM)架构下，集群的整体内存总量是非常大的，那么在处理这样海量数据的情况下，构建的大量的索引也需要分布式的存储在多台机器的内存里，那么对索引的查询，更新等操作，在传统的操作方法下，必然会存在网络的额外开销。RDMA技术已经提出了很多年，本论文最大的贡献点就在于对于建索引这个场景，详细讨论了粗粒度，细粒度以及混合策略的三种索引内部结构设计方式，采用RDMA的方法，评估各种方式索引的性能。这是一个非常实用的方向，在我们的分布式数据库的工程产品实践中也可以借鉴。新硬件，尤其是基于高速网络实现的远程高效访问机制，是对share nothing系统架构的一个很大的红利。 4.BriskStream: Scaling Data Stream Processing on Shared-Memory Multicore Architectures这篇论文是新加坡国立的同学对于在Scale up的系统里，如何应对多核NUMA(Non Uniform Memory Access)架构，更好的进行流计算处理做的一些工作。传统数据库领域，以Oracle为代表，是Scale up的重要实践者，而在Scale up的硬件设计中，NUMA是一个重要的设计点。Oracle对此做了很多的优化，保证OLAP查询在多个Socket上的负载均衡，保证内存的本地访问，提高系统的整体性能。在流计算领域，目前还没有太多的这方面的工作。 作者提出了一个叫做Relative-Location Aware Scheduling(RLAS)的执行优化策略，在数百核NUMA架构下能够将计算性能真正的Scale up，性能超过开源的DSPS一个数量级。从分布式数据库系统的角度来看，NUMA也会是未来的一个方向，当计算机体系架构进一步发展，单机的Scale up设计继续往前演进的时候，对于NUMA架构的引入可能会更加的普遍，到那时候，不是一定要特别高端的硬件CPU架构才会需要做NUMA aware的设计，很可能普通的PC server用的CPU也是这样的架构。如何在这样的架构下让代码表现的更好，这也是architecture aware设计的一个重要的考虑点。 5.DuckDB: an Embeddable Analytical Database这篇文章是一个Demo小短文，出自CWI的数据库实验室，想法出自SQLite这个产品形态，因为对于分析型查询的支持效率不高，他们做了一个完备的数据库系统，并没有什么特别创新的思想，就是根据已有的各方面比较成熟的理论，搭建了一个系统，有自己的parser，optimizer，query engine等等，采用向量处理引擎，做了一些工程上的优化，同时实现了Hyper的MVCC思路，提供了较好的OLTP的支持。之所以提及这篇论文，是觉得欧洲学术圈的同学们这种不是为了追求创新而创新，看到实际的问题就去搭建系统解决的做法，很是值得称道。目前DuckDB能跑所有的22个TPC-H查询，和99个TPC-DS查询中的97个，项目的同学还在持续的开发着这个系统。 研究领域二：开源数据库／大数据产品6.Apache Hive: From MapReduce to Enterprise-grade Big Data WarehousingApache Hive在项目成立之初是一个面向大数据分析的系统，在这篇paper中，Hive全面转向了拥抱传统关系型数据库的思路，这充分证明了一点，技术是为商业服务的，企业客户既然是这个市场的大金主，那么一切企业客户需要解决的问题，喜欢的解决方案，才是技术方案需要去要考虑的方向。在这篇论文中，Hive表示做了如下的几点增强，以更好的适应企业数据库市场的需求，去和传统数据库厂商竞争：1.SQL和ACID的支持，基于Hive的Metastore做了一个transaction manager，实现了read-committed级别的隔离；2.优化器技术，没有采用自己实现的方案，集成了Calcite，对于开源生态来说，这也是一个很自然的选择，从开发周期，工作量，生态维护来看，自研对自己系统最好的优化器的投入非常大；3.执行引擎优化，从MapReduce转换到了Tez，还加入了LLAP的支持，可以对数据做缓存的执行系统；4.多数据源支持。看得出来Hive想要在企业市场去分一杯羹的野心，但是企业市场对开源的服务支持，企业自身技术能力的门槛是一个很重要的考量，这一块开源产品还有很长的路要走。 7.One SQL to Rule Them All-an Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables这篇论文是Apache几个顶级的开源项目，Beam/Flink/Calcite的贡献者加上美国能源部下属的橡树岭国家实验室共同做的一个项目，从标题就可以看出，主要的建议和工作就是用一套统一的SQL语言同时支持现在的point-in-time的关系查询以及流处理查询，他们建议对现有的SQL标准进行扩展。主要的想法是将现有的关系扩展，看成可以随着时间维度变化的关系，在此基础上引入事件时间处理的语义和流数据的时间维度物化控制。其实数据库领域对于流式的关系数据处理一直都有研究，如OpenCQ，CONQUER以及获得过SIGMOD十年大奖的NiagaraCQ系统，现在做流处理的社区希望能在不改变现有SQL算子的基础上，通过扩展SQL标准，能够实现大一统的处理。这应该是一个有益的尝试，如果关系数据库社区能够接纳这一意见，相信未来的关系数据库产品能够给客户带来更大的价值。 8.FoundationDB Record Layer：A Multi-Tenant Structured DatastoreFoundationDB是一个底层支持事务的分布式Key-Value存储，2015年被苹果收购，用于iCloud存储服务。收购之前，FoundationDB有一些公开的设计文档，我就是从这个系统借鉴了table group的设计。在分布式系统中，经常出现同一个事务同时操作多张表格，比如一次交易需要同时修改交易基础表和交易扩展信息表，FoundationDB会把这些表格放到一个table group里面，避免分布式事务。Table group和Google Spanner里面的entity group解决了类似的问题，但语法有些不同。这篇论文的Record Layer是一个构建在FoundationDB之上的开源库，封装数据类型、Schema、索引、多租户等功能。 研究领域三：老牌商业数据库厂商对于传统的数据库厂商来说，这几年的关键词其实就一个——云化。在传统数据库市场格局已经基本定型的局面下，数据库云化是一个对市场进行重新洗牌，重新塑造新的市场领导者的机会。在刚刚过去的6月份，Gartner发布了题为《The Future of the DBMS Market Is Cloud》的报告，明确的断言了未来数据库市场将会是云的天下。根据Gartner的统计数据显示，数据库市场在过去的两年增长率分别是13%和18.4%（过去十年增长最快的速率），其中68%的增长来自于云数据库市场，而在剩下32%的来自于用户本地数据库服务的增长中，更多的是由于数据库价格的提升和现有系统升级而产生的开销——换句话说，本地数据库服务的新增长相比之下非常之少。 在云数据库的这片战场上，我们既看到了像Microsoft SQL Server这样的传统数据库大厂，也有靠提供数据库云服务起家的市场新贵——Amazon AWS，二者在过去两年的云数据库市场表现最为抢眼，他们两家一起贡献了约75%的云数据库增长份额。相比之前，数据库的老牌霸主Oracle在转型云化的道路上走的就不那么顺利，市场份额在不断受到瓜分的同时，云服务负责人Thomas Kurian和其他几位管理骨干的出走也为整个云化蒙上了一层阴影。 这些市场上的变化在今年的SIGMOD上也能看到一些端倪。比如，微软今年一口气提交了三篇论文，都是和数据库上云的部署、运维有关；而AWS的Aurora数据库则因为“在云服务环境下重新定义了关系数据库的存储系统”而获得了2019 ACM SIGMOD System Award。相比之下，Oracle仅仅是在去年的SIGMOD上发表了一篇来自于Oracle Labs的研究论文，云数据库方面的产出并不是很多（不过据了解相关的研究和工程实现也在不停的推进中）。 9.Socrates: The New SQL Server in the Cloud近两年来，云数据库在架构上选择单机模型+存储计算分离是一个总体的趋势，比较有代表性的有Amazon的Aurora，这篇论文介绍了SQL Server的存储计算分离的数据库服务: Socrates。Socrates是SQL Server的存储计算分离架构。相比本地存储架构，Socrates的优势在于提升了存储容量（4TB => 100TB），提高了可用性（99.99% => 99.999%），并且存储容量更加弹性。 Aurora是公有云上第一个存储计算分离的系统，论文发表在SIGMOD 2017，叫做“Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases”。Aurora提出了“the log is database”的设计理念，数据库实例往底层存储只写redo日志，将日志回放等操作下放到底层存储，从而大大降低网络开销。Socrates与Aurora在这点上原理类似，XLog Service用来存储日志，Page Server用来存储物理页面，数据库计算层往XLog Service写入redo日志，Page Server从XLog Service读取日志并回放。Socrates的特点在于把XLog Service和Page Server分得比较开，整体架构比较清晰。 值得一提的是，SQL Server之前的一个版本是基于逻辑复制单机技术库的HADR系统，很显然，作为一个逻辑复制的高可用方案，HADR并不能解决SQL Server作为一个单机云数据库在扩展性上遇到的挑战，这也是Socrates系统的设计目的。相比这个架构下的前辈——Aurora，Socrates从概念上创新的点似乎不多，但其作为Azure云数据库产品的一个重要补充是有明确的市场价值的。 10.Automatically Indexing Millions of Databases in Microsoft Azure SQL Database索引是关系数据库——尤其是OLTP场景——最重要的优化手段之一，因为谈到数据库的运维和调优，索引的创建是最重要的问题。关于索引建议的论文有非常长的研究历史，相比那些研究性论文来说，这篇论文在理论上的创新不算很多，但作为一篇工程实践的总结，还是值得一读。 作者提出了在云数据库时代自动索引创建的四大挑战：索引创建的服务的可扩展性、如何生成用于索引建议的输入（如何识别有价值的workload）、在优化器估计有误的情况下如何避免性能回退以及如何尽可能不影响系统的正常运行。在系统架构上，作者引入了control plane这个模块，用以在全局层面控制、调度、监控、管理整个索引创建的各个环节，这个设计笔者觉得还是很有必要的。随着云数据库的应用场景越来越广，用户越来越多，如何在大规模下同时管理多个数据库实例是重要的研究方向，而我们也会看到越来越多的数据库单实例的功能（例如index advisor）被抽象到整个云数据库运行环境，数据库管控平台和数据库内核的能力边界需要被重新定义。 论文同时也提到了一个重要的经验，就是对于索引自动创建这个功能来说，不影响用户正常的应用是非常重要的，只有在不“做恶”的情况下，才能使更多的用户更放心的使用“自动创建索引”的功能，才能真正将整个功能大面积的推广开来，这也是该项目得以“成功”落地的关键。 11.AI Meets AI: Leveraging Query Executions to Improve Index Recommendations跟上面一篇论文一样，本篇文章也来自微软研究院，解决的都是SQL Server的索引推荐问题，但做法有些不同，感觉有点像“一鱼多吃”。这篇论文可以当做是上一篇论文的延伸阅读。上一篇论文提到，优化器在进行代价模型估计的时候其实会犯各种各样的错误，这也造成一个索引的创建很有可能适得其反的引入性能回退，那么有没有一种不依赖优化器的索引推荐方式呢？论文就尝试使用机器学习的方法来对“好”索引和“坏”索引进行判断，由于测试场景有限，这种依赖机器学习算法的推荐方式的通用性，我们还不太确定，但机器学习算法作为优化器的补充或是替代这个方向还是值得继续关注。 12.Designing Succinct Secondary Indexing Mechanism by Exploiting Column Correlations说过Oracle和微软，总要提一下IBM。相比较而言，IBM似乎对DB2已经不太上心了，C Mohan把主要的精力都投入了区块链的研究。不过这篇来自IBM Almaden实验室——System-R这个现代关系数据库的鼻祖产品的发源地的论文还是一篇比较纯粹的在传统数据库领域做研究的文章，研究的核心问题也是数据库用户比较关心的问题——索引的空间占用问题。建索引是传统数据库优化的重要手段。随着数据库负载复杂化，越来越多的索引被创建，系统空间的使用也越来越多，对用户来说，这是一笔不小的成本开销。针对这个问题，学术界过去提出了几种不同的优化思路，一个方向是以用户的空间或者存储预算作为约束，对保留哪些索引进行选择以及优化；另外一个思路是从数据结构上对索引进行压缩和裁剪，使单个索引的空间利用率更高。本文的作者在这里提供了一个新的思路，这个思路就是利用在数据库中经常存在的数据键的关联性（correlation）——也就是文中所称的数据间的“软依赖”——来综合多个索引的数据存储。论文的思路是通过一个叫做“TRS-TREE”的数据结构，建立相关联的数据在一定范围内的映射，从而减少了冗余数据的存储。由于数据关联性往往是近似或者模糊的，这样的索引查询数据往往带有假阳性（false positive），因此，最终结果还需要在原始表中进行再次验证才能返回给用户。数据库中的数据关联性也是一个经常被研究的特性，例如数据关联性对优化器的影响等问题，这篇论文也为数据关联性的应用提供了一个全新的思路。 研究领域四：数据库与其他技术的结合与应用13.FITing-Tree：A Data-aware Index StructureLearned Index是AI+System的热门方向，利用AI统计实际数据的规律来设计更加高效的索引结构。前两年Google Jeff Dean团队提出了一种Learned BTree Index，不过这个结构有一个明显的缺陷：对插入和更新不友好。FITing-Tree的思路看起来更接地气一些，它也是一个BTree结构，中间节点和传统BTree相同，但叶子节点不存储全量，只存储数据段（Segment）的范围，而如何划分数据段是通过机器学习统计的方法实现的。 14.Fast General Distributed Transactions with Opacity这篇论文讲的是如何通过RDMA新硬件优化分布式事务，实现透明可扩展。2015年有一篇相关论文，叫做“No compromises：distributed transactions with consistency，availability，and performance”，这篇论文的工作更进一步。其中，这篇论文提到了一个使用Marzullo算法实现全局时钟同步的做法，不依赖原子钟等硬件，服务器之间的时钟误差大约在6毫秒左右，和Google Spanner系统中的TrueTime有共同之处，可以用来实现分布式系统的租约机制。 15.Towards Scaling Blockchain Systems via Sharding区块链的一大难题在于可扩展性，无论是公有链还是联盟链，区块链的每个节点都必须存储全量数据，每个事务都要求多数节点提交。这篇文章想要解决可扩展性问题，但解决方案并不是通用的。它做了一个基本假设：区块链里面的说谎的节点不超过一定比例。接下来，就是如何把区块链sharding，使得每个shard之内说谎的节点不超过一定比例，并在这个假设的基础上优化PBFT算法。 总结 不光是传统的数据库大厂将战场选在了数据库云化，一些中小型的数据库服务商也开始在云服务市场发力，例如历史悠久的列存储数据库MonetDB，这两年就把研究重心放到了云服务版本的开发上；而一些新兴的数据库引擎，例如近几年备受关注的分析数据库厂商Snowflake，则干脆直接基于云服务的运行环境进行开发，直接跳过了on-premise的产品形态，同样得到了市场的高度认可，这些都是数据库市场正在进行重构的显著信号。 值得一提的是，尽管Gartner的报告旗帜鲜明的指出“云”是数据库市场的未来，报告中也明确的提到了一种称为“数据库斯德哥尔摩综合综合征”的现象——即建立在传统本地数据库服务架构之上的企业，虽然看到了云服务化的优势和趋势，在面临选择时仍然可能出于规避风险的考虑继续使用本地的数据库服务，整个企业面向云化转型的周期也会非常之长——他们就像是被绑架了的人质，小心翼翼的维系和传统数据库解决方案（绑架者）的“锁链”。因此，尽管云数据库市场发展迅猛，但要真正将传统企业用户争取过来，云数据库服务商们还需要做好打持久仗的准备。从这个角度来讲，大家都还有机会。

  一直都要做GIS方面的开发，所以准备将本博客从讲解VS.Net方面的知识转型到专门讲解GIS介绍与开发上。还望各位同仁仍同以往一样大力支持本博客。       前些时候在使用ArcGIS产品做开发工作，虽然ArcGIS是一个很不错的产品，帮助我实现了很多GIS功能，但是还是有三点让我放弃了对ArcGIS的研究：1、ArcGIS是国外产品，非国内产品，本人还是希望能支持国内GIS软件事业的蓬勃发展；2、ArcGIS较为昂贵，所以使用的是盗版软件，帮助很差，开发进度很慢；3、因为本人英文不好，所以对于国外关于ArcGIS很好的帮助文章也是一知半解，同样非常影响开发进度。总体看来，我怀着兴奋和惋惜的心情离开了ArcGIS产品，从而转向了国内对GIS产品支持非常好的平台——SuperMap产品。       SuperMap产品其实我早就听说了，只是由于时间、空间、人为和所做的事情的约束，无缘与SuperMap产品相聚。通过接触，本人详细地了解了SuperMap产品，发现了很多优越的地方，提出来让大家共同研究探讨： 1、SuperMap产品系列也很全面       SuperMap产品系列都是由北京超图软件股份有限公司自主研发，该公司成立于1997年，并致力于GIS平台的研发，且对于GIS的技术和商业的推广都很全面到位。据我所知目前北京超图软件股份有限公司在全国各省都设立了分支机构或是办事处，产品还在日本和东南亚甚至欧洲都有一定份额的市场，据悉2009年北京超图软件股份有限公司成功在创业板上市。虽然实力不如国际领先的GIS产品厂商，但在中国已经走在了GIS领域的前端了。       北京超图软件股份有限公司的SuperMap产品有如下几个系列： （1）SuperMap Deskpro 功能全面且强大的GIS电子地图处理工具，支持很多种数据源，如：文件数据、Oracle、Sql Server、DB2、SyBase、KingBase（国产数据库——金仓数据库）等等，还能对各类栅格数据进行处理，导入各种数据格式等等。 （2）SuperMap Express 比较强大的GIS电子地图处理工具，在功能方面比SuperMap Deskpro要缺少些，而在价格上也同样便宜了些。 （3）SuperMap Viewer 浏览电子地图的工具，没有对电子地图的任何编辑功能，但却是免费使用的软件产品。 （4）SuperMap Objects 优秀的C/S模式下的GIS开发平台，包含了所有在SuperMap Deskpro中对地图的操作功能。可以很不夸张的说，如果您有时间又非常了解SuperMap Objects产品的二次开发，您完全可以利用SuperMap Objects自己开发出一套SuperMap Deskpro。 （5）SuperMap IS.Net 在Asp.Net环境下开发B/S架构的GIS应用程序平台。SuperMap IS.Net的底层是基于SuperMap Objects内核的。也是我们.Net开发人士开发WebGIS的理想工具。 （6）SuperMap iServer 一款跨平台的B/S架构产品，提供的是GIS Web服务。 （7）其他产品，如：GIS的嵌入式开发平台以及导航产品等。   2、本人用到的SuperMap产品       GIS是一门以多学科为基础的学科，对地理信息、制图技术、管理科学、计算机知识等都有较高要求。本人用到的产品有SM Deskpro、SM Objects、SM IS.Net，这些产品的帮助都很全面易懂，因此对开发很有帮助。 本文转自刚刚博客园博客，原文链接：http://www.cnblogs.com/lijigang/archive/2010/06/08/1751672.html，如需转载请自行联系原作者

 一直都要做GIS方面的开发，所以准备将本博客从讲解VS.Net方面的知识转型到专门讲解GIS介绍与开发上。还望各位同仁仍同以往一样大力支持本博客。       前些时候在使用ArcGIS产品做开发工作，虽然ArcGIS是一个很不错的产品，帮助我实现了很多GIS功能，但是还是有三点让我放弃了对ArcGIS的研究：1、ArcGIS是国外产品，非国内产品，本人还是希望能支持国内GIS软件事业的蓬勃发展；2、ArcGIS较为昂贵，所以使用的是盗版软件，帮助很差，开发进度很慢；3、因为本人英文不好，所以对于国外关于ArcGIS很好的帮助文章也是一知半解，同样非常影响开发进度。总体看来，我怀着兴奋和惋惜的心情离开了ArcGIS产品，从而转向了国内对GIS产品支持非常好的平台——SuperMap产品。       SuperMap产品其实我早就听说了，只是由于时间、空间、人为和所做的事情的约束，无缘与SuperMap产品相聚。通过接触，本人详细地了解了SuperMap产品，发现了很多优越的地方，提出来让大家共同研究探讨： 1、SuperMap产品系列也很全面       SuperMap产品系列都是由北京超图软件股份有限公司自主研发，该公司成立于1997年，并致力于GIS平台的研发，且对于GIS的技术和商业的推广都很全面到位。据我所知目前北京超图软件股份有限公司在全国各省都设立了分支机构或是办事处，产品还在日本和东南亚甚至欧洲都有一定份额的市场，据悉2009年北京超图软件股份有限公司成功在创业板上市。虽然实力不如国际领先的GIS产品厂商，但在中国已经走在了GIS领域的前端了。       北京超图软件股份有限公司的SuperMap产品有如下几个系列： （1）SuperMap Deskpro 功能全面且强大的GIS电子地图处理工具，支持很多种数据源，如：文件数据、Oracle、Sql Server、DB2、SyBase、KingBase（国产数据库——金仓数据库）等等，还能对各类栅格数据进行处理，导入各种数据格式等等。 （2）SuperMap Express 比较强大的GIS电子地图处理工具，在功能方面比SuperMap Deskpro要缺少些，而在价格上也同样便宜了些。 （3）SuperMap Viewer 浏览电子地图的工具，没有对电子地图的任何编辑功能，但却是免费使用的软件产品。 （4）SuperMap Objects 优秀的C/S模式下的GIS开发平台，包含了所有在SuperMap Deskpro中对地图的操作功能。可以很不夸张的说，如果您有时间又非常了解SuperMap Objects产品的二次开发，您完全可以利用SuperMap Objects自己开发出一套SuperMap Deskpro。 （5）SuperMap IS.Net 在Asp.Net环境下开发B/S架构的GIS应用程序平台。SuperMap IS.Net的底层是基于SuperMap Objects内核的。也是我们.Net开发人士开发WebGIS的理想工具。 （6）SuperMap iServer 一款跨平台的B/S架构产品，提供的是GIS Web服务。 （7）其他产品，如：GIS的嵌入式开发平台以及导航产品等。   2、本人用到的SuperMap产品       GIS是一门以多学科为基础的学科，对地理信息、制图技术、管理科学、计算机知识等都有较高要求。本人用到的产品有SM Deskpro、SM Objects、SM IS.Net，这些产品的帮助都很全面易懂，因此对开发很有帮助。 本文转自刚刚博客园博客，原文链接：http://www.cnblogs.com/lijigang/archive/2010/06/08/1751672.html，如需转载请自行联系原作者

关键字：程序员 私活 经验 外包作者：  row@csdn标题：个人外包项目全记 - Best Partner 地址：http://www.cnblogs.com/txw1958/archive/2012/11/06/programmer-personal-work.html 正文：（一）项目确立 一年前，CSDN的外包频道，一家贸易公司寻求开发业务系统。我注意到这家公司和我正好在一个城市，索性就跟了一帖，写了点简要的个人开发情况，当然最重要的是附上了自己的手机号码（当时CSDN外包频道还不限制这个信息的）。第二天就接到那家公司总经理的电话，这让我多少有点意外，电话中，双方客套两句后，约定好周末面谈。 和以往面试一样，我带上个笔记本（上面有以往开发的项目演示版）按照约定好的时间，准时去洽谈。地点是在对方的办公室，一进会客室，给我第一感觉整齐、清新、优雅、绿色；窗外则是宁静的半岛和微澜的海浪，心情顿时感觉非常畅快。 电话中那位非常绅士的总经理，年纪大概45岁左右，我们的谈话直奔主题。我先简单介绍了一下自己的情况（工作和开发经历），用笔记本演示自己以前开发过的两个类似项目情况，他则不时地提几个关心的问题。然后，他简单地将自己公司的需求告诉我，并把现行的系统的主要功能演示给我看了看。 整个谈话过程中，我印象最深刻的是他最后时刻说的话：“我看了你以前开发的系统演示，认为你完全有能力开发我们的系统；我也不打算再寻找其他人来面试，因为我的时间不允许我这样做。你如果觉得刚才我们谈到需求内容和开发价格都合适，那么我们就此开始合作。” 我是个程序员，他是个商人，我们的合作就此开始。 正文：（二）需求确定1 有了第一次的面谈，我对这家公司的整体印象不错。说起来，我以前去过不少公司（自己工作过的公司或谈项目去过的公司），尤其是从事贸易的公司，还是第一次见到办公室这样让人感觉如此舒服的。 简单说一下我需要开发的系统，其实并不复杂，就是一个典型的贸易系统，主要功能是管理公司的产品、客户信息，然后给客户报价、生成合同、给厂家下生产单等等。当然，这每一个模块中都会有很多特定的需求，例如，产品的价格组成，当某些价格组成发生变化时，系统需要自动更新到所有可能产生影响的部分去。 （那位非常绅士的总经理，为了叙事方便，给他取个名字吧，就叫Gentleman吧） Gentleman把他们现在使用的系统，发了一份给我，在我看来这个系统简直就是一个学生的实习作业。无论从系统的性能上，还是操作的界面上，逻辑的条理性上，都存在很多的问题。但就是这样的系统，Gentleman居然使用了近7年的时间，这让我感到很惊讶，甚至于难以理解。而Gentleman经常在需求的沟通过程中，提到他们原先的系统如何如何实现，我心中总是会非常不舒服，觉得拿这样原始而粗糙的系统来与即将开发的系统相提并论，我认为是对我的轻视或者说低估。 对了，需求中有个重要的部分，那就是数据同步。因为Gentleman长期定居在国外，每年只回国两次，每次大概一个半月，平时他都是通过IM和Email来管理他的公司。 正文：（三）需求确定2 我用2天时间，把他们原先的老系统的所有功能，都'学习'了一遍，在自己大脑中已经有了一个比较清晰的轮廓。其实行业软件，大家只要熟悉其业务流程，就会感觉非常简单。因为从程序实现上来看，主要工作就是数据库的表结构设计，以及相关前台界面的操作合理性。 Gentleman在他回CA国之前，约我再见一次面，并给我发来一份他自己整理的需求文档（20页左右）。因为我白天要正常上班，而他的返程机票已经订好，所以我们只能约定好晚上见面。这次，他约我的地点是一家五星级酒店的自助餐厅。用他的话说，他不知道该去哪合适，只知道这个地方吃饭还比较自在，他喜欢这的环境。这家自助餐厅给我留下的印象，就是用餐的外国人比中国人多，当然Gentleman给我的感觉也有点像个外国人，只是和我说话的时候还是用中文而已。 我们边吃边谈系统的需求，他把自己需求文件中描述的内容，再给我讲述一遍。而且讲得非常仔细，生怕我有不明白地方。其实他说的大部分内容，对于一个有8年开发经验的程序员来说，完全没必说得这么细致。当然，我也不打断他的思路，只是默默地听着，因为我不想让他以为我很狂妄。我看着他认真的神情，思想反倒有点走神，脑子里寻思这一个问题：我什么时候能像他这样工作和生活？ 就系统的需求，我们聊了大概有3-4个小时，从自助餐厅到酒店大厅的会客区。Gentleman想把他所有能想到的想法和问题都告诉我，因为他明天就要飞回CA国，这半年内，再也没有这样好的沟通机会了，毕竟Email中的描述只能停留在字面上。 那夜，我回去后，脑子里并没想任何系统需求，只是一直在想：我什么时候能像他这样工作和生活？ 正文：（四）系统整体设计1 需求大致上了解以后，我开始着手系统的整体设计工作。 首先，从应用角度上来看，这个系统是准备在一家30人左右的公司运行，而且Gentleman需要在自己的笔记本上安装一套系统，并与国内公司这边进行数据同步。另外，他们公司在每年的春秋广交会期间，都会带产品去参展，期间有5-6台笔记本需要使用系统，以便随时给客户报价。所以说，各个数据库之间的同步，是这个系统的一个非常重要内容。 其次，我开发系统有个习惯，即在完成系统功能的同时，比较注重界面的设计。这个习惯，也让我在这个系统上多花了30-40%的时间（Gentleman对于界面并未做任何要求）。但我认为是必要的，我们程序员在写程序的时候，都使用IDE工具，我个人的感觉，如果这个开发工具非常丑陋或看起来别扭，在开发系统的时候，是会非常不舒服的。同理，业务人员每天都是使用这套系统来工作，如果系统的界面非常差，操作起来很别扭，那工作简直就是遭罪。 还有，系统的整体框架。我没有采用以前开发过度系统框架，虽然这样能节省我很多时间。但我仔细考虑了一下，由于这个系统对于时间要求并不紧迫，而我也想积累更多的系统框架，所以最终决定在原框架的基础上做许多升级改良，以便更试用于这套系统。 （不少程序员开发系统，是一套框架多处使用。我认为如果时间不是很紧张的情况下，完全可以设计更好的方案。这样在接下一单项目的时候，就可以有更多更好的系统演示给客户看） 系统的功能就像人的五脏六腑，界面则是人的长相和外衣；长相虽然不影响身体健康，但绝对影响找对象，呵呵，所以说，界面是个不大不小的问题。 正文：（五）系统整体设计2 Gentleman回CA国后的一个月内，他仍然每周都给我发过来最新的系统需求，其中有专题性质的（例如：某处的价格算法，以及价格调整的系列影响），也有系统整体性的需求调整。我则有条不紊地地分析着每份需求文件，从这些需求文件中，我能感觉到Gentleman对这个系统的期望值很高，因为他不仅是在提需求，甚至是在做程序设计工作，哪些部分需要加按钮，这些按钮完成什么功能，具体某个字段是下拉列表显示，还是弹出窗口等等。 在此期间，我并未急于做实质性的业务程序开发工作。我从Gentleman的众多需求文件，逐步整理和设计出系统的几个核心表结构，在这几个核心表结构还没有相对稳定之前，我是不会写一行业务程序代码的，这是原则。当然，我的程序框架的改进工作是一直在同步进行的，因为程序框架部分和业务程序部分几乎是平行的，只需要在框架中考虑到几处重要的StatusBar和ProgressBar，以及系统的整体显示风格即可。 （即便如此，在后续的开发过程中，还是出现了需要调整核心表结构的情况，当然这是后话，暂且不提） 随着核心表结构的设计过程，我的脑海中正在一步步地形成整套系统的数据脉络（主业务数据流和辅助数据流）。与此同时，Gentleman经常在发送新需求文件的同时，询问系统的进度情况。而此时的系统进度只是在我脑海中，在一份数据库表结构文件中（我没去写非常详尽的设计资料，因为一个人的系统没必要把过多的时间放在文档上，文档工作是对于协同开发小组比较重要的），我无法让Gentleman感知进度的情况。我只是告诉他正在做系统的设计工作，我也没发送改进好的程序框架给他看，我认为把一个半成品给对方看，还不如不给对方看。 Gentleman很理解我的工作，虽然我的当前的工作汇报只是停留在口头上。噢，又忘交代了，Gentleman在成为商人以前是学计算机专业的，不过，我至今还不知道他是否当过程序员。 中间插一讨论篇《程序风格》，本篇与这个项目开发有些关系，但并不纳入到正文中。 欢迎各位程序开发高手积极讨论一下。 讨论篇1：程序风格 程序是什么？不同的角度有不同的看法，比较经典的论断是 程序=数据+算法。数据是一套系统的核心，他的地位是不可动摇的，好比人民的温饱问题。算法是什么，算法是系统的引擎，算法的好坏优劣决定了程序执行的效率。但随着现在硬件技术的提高，很多程序员已经淡化了算法的重要性，以完成功能为标准，这是可悲的事情。 依我的看法，程序不光是数据+算法，那只是程序的行体部分；程序还需要有风格，这才是程序的神态部分。只有形神兼备的程序，才是一个优秀的程序。程序风格又包涵哪些内容呢？在解释这个问题之前，我们先设想一下，如果一个闭月羞花的美女，出口就是脏字；如果一篇行文洒脱的文章，字确写得东倒西歪；如果一座雄伟的山峰，上面确寸草不生。那样是不是很煞风景？ 程序风格是什么？程序风格就是一个程序中，在数据内容以外所体现出来的内涵，它表现在程序的各个方面。从使用者的角度：主要体现在程序的整体显示风格（颜色基调、图标风格、字体大小）和交互风格（数据组合方式、功能区划分、操作流程）；从程序开发者的角度，它包括项目的管理、源文件的组织、代码的风格、注释的写法。 对于一个人的项目，程序的风格就取决于你的个人风格。程序员在锻炼开发技术水平的同时，应该同时培养你的程序风格。 恭候拍砖！ 正文：（六）Coding 1 程序的风格和核心数据库表基本确定后，我开始了系统的模块设计和编码工作。我的基本思路是，按照程序模块的重要性，逐个模块实现。单个模块的设计和编码同时进行的，完成好一个模块，就发送给Gentleman审核，以模块程序为交流载体，方便双方沟通。 夜晚22:00后，静夜孤灯下，一杯水，一个人。时而低头沉思，时而握笔绘图，时而指走键盘，这就是我平时工作的画面。一行行代码，一个个画面就这样跃然屏幕上。 系统中最先做到是产品管理模块，大家可能会认为这样的模块应该是比较简单的。是的，如果只是实现新建、编辑、删除功能的话，肯定很简单，但我确故意要将简单的东西复杂化。厨师的水平高低，不在菜上，而在于做菜的功夫上。 我在实现产品管理模块时，考虑到很多问题。如何将主货号和详细货号关联？主货号中的哪些字段应该与详细货号中的相同，两者之间应该怎么显示和编辑最合理？程序实现的过程中，哪些模块可以共用，哪些字段需要冗余？编辑某个货号的时候，应该怎么显示其他货号的详细内容作为参考？怎么让业务员输入最少的信息即可完成操作？ 上面这些问题，有Gentleman提到的，更有Gentleman没提到的。我认为系统的开发过程，就像一段外语的翻译过程，有人是直译，有人是意译，孰高孰低，明眼人一看就知道。至于其中多付出的劳动，虽然只有自己知道，但同样可以体现在你的劳动成果中。 在我的观念中，开发系统不仅仅是为了开发而开发，应该再提升一个高度，至少要让自己满意。后来证实我的思路是正确的，Gentleman对于我的程序实现方式，很满意，或者说赞赏。以至于他总是说我聪明，能准确地理解他的意图，并恰当地实现出来。具体体现在他的需求文档中，以往那些琐碎的、近似设计的描述少了，他只提他想要的结果，具体实现他已经不用操心了 - 这正是我的目的。 我和Gentleman的关系，开始有点像Partner了。 正文：（七）Coding 2 自从编码开始后，项目开发工作似乎进入了正轨。 这套系统的编码过程中，有一个十分麻烦的地方，那就是货号价格的变化，需要更新多非常多的地方。这些都是Gentleman在常年的工作中总结出来的，他心中非常清楚。他只要一看这些价格数字，就能知道哪些是正确更新后的，哪些是未更新的。可我在短时间内确是很难做到的这一点的，因此，我单独写了一份价格更新对照表，虽说整理着份文件花了不少时间，但磨刀不误砍柴功，这份文件在后续的工作中发挥了重要的作用。 因此，我认为在开发过程中，对于那些容易混淆或需要非常仔细的地方（例如：本系统中的各种价格组成、公式、更新对照等），应该单独写份文档作为项目参考资料（这份文档一定要准确无误），即便是一个人开发系统，也有必要。就像Windows API参考文档一样，当程序需要调用具体API函数的时候，只要查一下参考文档就可以了，完全没必要去记住那些具体参数，因为短时间内去记住那些参数，是不现实的。随着开发的过程，对于那些经常调用的部分，自然就熟悉了。 编码的过程，是对设计的逐步修正的过程。设计时理解不准确的部分，在Coding的过程中，都会逐一发现。 很多人羡慕一个人开发系统，其实一个人开发系统的优势和劣势同样明显。优势在于整个开发中，省却了所有的开发沟通时间，因为整个系统（哪怕是非常细小的环节）都了然于胸；劣势就是孤单，遇到任何技术问题都必须自己一个人去解决，解决问题后的快感也没人分享。 这个劣势在后续的开发中，给项目带来了一点问题。 正文：（八）Coding 3 编码的工作是辛苦的，远没有程序设计时的天马行空，需要的是严谨的工作态度、良好的编码习惯和相对完整的开发时间。对于Part-Time开发者来说，很多人觉得非常辛苦，主要是因为没有完整的开发时间。 项目的开始阶段，一般开发者都能保持相对高的开发热情，但一旦进入编码的中期，这种热情支撑下的开发进度就开始疲态尽显。我也是遇到了同样的问题，项目进行了3-4个月左右的时候，开发进度明显比预期的低了很多，就连大洋彼岸的Gentleman也能明显感觉得到。 Gentlman开始有些着急了，经常在Email中询问开发进度（其实就是催促开发进度），并主动提出快速开发奖励。我非常清楚Gentleman的心思，首先，他是想在下一次的广交会之前使用上这套新的系统，以便提高工作效率；其次，他是认为我当前的系统开发质量比他原先预期的要好，所以很乐意提高开发费用。面对相对优厚的额外奖励（这是Gentleman高明的地方），我也很想提高效率，但由于种种原因我很难进入快速开发状态。 多说两句当时的情况，权当为自己开脱吧。其一，项目进展到3-4个月左右的时候，我老婆正到预产期，我可爱的女儿来到了这个花花世界；其二，在去年轰轰烈烈的A股牛市中，我这新股民怀着快速发财的梦想，在5500点的高位杀入了大量的资金，结果亏损严重，致命的是这些资金有大部分不是自己的存款。这让我承受了巨大的精神压力，几次出现失眠的情况。仅此两点，大家就可想而知我当时的状态了。 心态上无法进入工作状态，时间上无法保证开发时间，一个人的战斗，孤立无援，我把项目带入到了最艰难的境地。 正文：（九）Coding 4 面对Gentleman的额外奖励，我深感惭愧，虽然内心很想加快开发进度，但当时的心思确又很难聚焦到项目开发上来。这样浑浑噩噩的状态大概延续了一个月左右，项目的开发进度比预期已经差了一大块。我几次想在Email中告诉Gentleman我的痛苦，但炒股导致的心理失衡问题，怎么能让他去承担后果。我问心有愧啊！ 即便在如此情形下，程序的代码质量还是我把握的第一要素。要么不写，要写就一定要保证质量，我绝对不会做杀鸡取卵这样的事。盲目上线带来的一定是后续更大量的补救工作，同时也会影响客户的信心。这一点，应该也是Gentleman欣赏我的地方之一。 随着春季广交会时间的日益临近，Gentleman已经感觉到项目无法在此之前完成，但他表现得非常大度。不仅没有过多地责怪我，相反还继续鼓励我，额外奖励依然有效，只是要求我全力把程序开发好。Gentleman的做法，让我非常感动，我时常自己在问自己：如果我不能及时调整好心态，不能坚持把项目开发好，对得起Gentleman这样的好人吗？ 我的名言：生命就是折腾与被折腾的过程。 这浑浑噩噩的一个多月，其实就是我个人心态的筑底过程，而这心态铸底成功的因素中，我清楚，有Gentleman一份功劳。伴随心态的调整成功，项目开发也重新步入正轨。当然Gentleman也从CA国飞回到本市，开始筹备公司的春季广交会的展览。 准确的说，此时此刻，系统的编码工作已经完成了80-90% 正文：（十）数据库选型 个人项目中，心理层面的问题需要自我调节，技术层面的问题同样只能独自解决，下面就写点技术问题。 在这套系统的数据库选型中，我是经过一番思考的。从我个人技术熟悉程度上来说，是对DB2和Sql Server比较熟悉。但对于30人规模的中小型公司，没必要选用过大的数据库，Oracle、DB2这类首先被PASS掉了，在Sql Server、MySql、Sybase ASA中，MySql中，到底应该选用哪个呢？ 可能很多人认为Sql Server应该是首选，最初我也在重点考虑它。但是Sql Serverd数据库，部署起来有点麻烦，考虑到Gentleman是长期在国外生活，在系统开发的过程中，我时常需要对数据库的结构进行调整。因此，数据库一定要便于打包和部署。其次，考虑到数据同步问题，因为这个系统最终数据库的部署，是需要在公司本部放一个中心数据库，另外几台笔记本上各放一个远程数据库。而这些数据库之间，要能够非常方便的进行数据同步。此时Sybase的Mobilink同步技术就进入了我的视线。（在这个项目之前，我并未做过数据同步方面的工作） 综合上面两个主要问题，我最终选择了 Sybase Asa 数据库，这款数据库，非常方便部署。更新数据库的时候，只需要直接替换数据库文件和日志文件就可以。而且我从Mobilink的资料中了解到，它是基于偶连接的同步技术，专用于中心数据库与多个移动数据库的数据同步的解决方案。我心想：Mobilink技术简直就是为我们这种应用而设计的。 同为Sybase的产品，ASA数据库理应与Mobilink无缝衔接。 讨论篇2：技术与应用 很多在校的学生和入行的新人，总是最关心开发技术，而且最关注流行技术。就好像流行时装一样，看哪些语言或工具流行，就学哪样，有甚者把市场主流的应用开发语言都学了个遍。其实大家会发现一个问题，即便学习了所有的开发语言，仍然不可能就此成为开发高手，因为他们学到的只是外在功夫，而非内功。 关于技术的内功和外功问题，大家只需要在开发的过程中，稍微用心体会一下，就可以找到练内功的方法。写代码的时候是不是频繁 Ctrl+C 和 Ctrl+V ，而不去琢磨复制过来这段代码或算法的基本原理？函数中的参数设置，是否仅仅满足功能就可以，还是需要预留下某个扩展？哪些功能代码可以抽象成一个类来实现，而非在程序中到处Copy同样的代码？等等！ （书法作品中一笔一画即能体现深厚的功底，想成为行家，就应该在程序的每个地方有自己的心得） 同样的程序，从客户角度，他们关注的侧重点是完全不同的。依据我的开发经验，客户基本上不关注系统采用的技术架构，哪怕你说得天花乱坠，那最多只是谈价格的一点小资本而已。他们关注的是系统功能，能否设计出他们认为最快捷、最安全、最实用的系统。“落后”的技术，同样有广阔的生存空间。因为对于客户，适用的就是最好的。 一个人做项目的时候，请记住：技术不是越新越好，而是越适用于项目越好，越熟悉的技术越好。在技术上你站得越高，项目的成功率就越高。（想学习和锻炼新技术，最好请到其他的项目组中学习，因为一个人的项目，新技术意味着无数未知的问题） 恭候高手拍砖！ 正文：（十一）项目中期收款 Gentleman回国后的这一个多月时间，几乎一直在忙于春季广交会的事情，很少和我联系。只是约定等他从广交会回来后，让我去他那领取部分项目款。 （在第一次面谈的时候，Gentleman就问过我项目收费方式的问题。现在一般公司的付款方式是361方式，即30%作为项目启动款，60%在项目验收后付款，10%的尾款最后在确认系统运行正常后付清。而我给Gentleman的答复是，项目开发前我不收任何款，等系统基本成型后（即客户可以认同开发质量和效果后）付60%的项目款，正式上线运行后，再付40%的项目款。 我之所以采取这样的收款方式，首先，我对自己的开发实力有信心，相信客户在见到系统后，会乐于付款；其次，我考虑对方是一家公司，而我是个人开发者，让对方提前把钱付给个人，这其中的风险明显大于付给一家公司。而我关心的是项目款的多少，并非付款时间。） 这次，我们见面的地点是Gentleman在本市的House，我按照约定好的时间准时到达。他的房子位于本市一段黄金海岸线上，从室内就能看到浩瀚的大海，总面积约有160平米，价值至少两百多万。屋子以浅色调为主，家具并不多，显得非常整洁。用Gentleman的话说，他常年定居在CA国，这房子基本是空着，只是回来的时候住这，所以陈设简单了些。 我们的话题，始终围绕着房子，而并没有说太多关于项目的事情。那天，我才了解到，Gentleman在做生意之前，也是工薪族，居住在一套30平左右的老房子中。后来公司逐步地发展壮大，他家的房子也随之换了三次，地段一次比一次好，面积一次比一次大，而他现在在CA国的家，是一栋独门独院的木房子。 从Gentleman家出来的时候，我已怀揣着刚收到的项目款，心中虽说有几分成功的喜悦，但同样有几分抹不去的惆怅。 正文：（十二）意译的烦恼 在整套系统开发的过程中，我一直采用‘意译’的模式，对Gentleman所提出的需求进行改进设计，但也有例外的情况。系统中有一个模块是给工厂下生产通知单，在这个模块的处理上，就出现了问题。 公司当前的做法是依据合同中的产品数量，给工厂下达生产。一份合同由多种货物组成，每种货物的订购数量和外销价是不同的。实际工作中都是将一种货物中所有的订购数量都制定一家工厂生产，当时，我从逻辑角度上分析，认为存在这种可能，即一种货物分交给两家以上的工厂生产。 所以我在设计中提出了改进模块的设计思路，并汇报给Gentleman，他当时的反应显得有些犹豫。因为现在的实际工作中是不存在这样的情况的，如果系统能实现到这种程度，肯定是更灵活，因此他就准许了我的设计思路。 这个模块的设计和实现过程中，由于要实现到同一种产品分配给多家工厂，并且订购数量要动态分配和回收。所以需要考虑到情况就复杂了很多，时间自然也多花了N倍。最终实现出来的效果是非常不错的，操作员可以清楚地看出每份合同下达的生产通知单，以及每种产品的生产数量。 但以上所认为到的程序最佳实现效果，都仅仅是我个人认为的状态。当把这个模块拿到具体业务员那测试操作的时候，问题就显现出来了。他们都反映麻烦，第一，从思路上和现状有点差别，感觉别扭；第二，在操作步骤上又多了一步操作，耽误时间。最后，Gentleman在考虑再三后，让我把这个改进模块功能去掉，依旧实现最原始的需求。 后来我总结此次教训，虽然模块的功能更灵活、更强大，但客户只需要他想要的，改进模块一定不能成为画蛇添足。 正文：（十三）测试之痛1 程序编码工作逐步接近尾声，接踵而来的就是功能测试、模块测试、集成测试、系统测试等。对于系统测试，开发人员大都不愿意去做的，因为这是一项既繁琐、又无成就感的工作。 一套没有经过严格测试的系统，就像一匹没有缰绳的野马，谁也不知道它发飙的时候，会跑到什么地方去。再繁琐的工作也要做，初步的功能测试和模块测试工作自然是由我自己来完成。可我发现个问题，我只要输入一些数据到系统中，开始做测试工作，就会自然地进入到一种自我欣赏系统的状态中，一圈数据测试下来，只能找到少量的程序错误。 Bug大体上可以分为两类，第一类是程序错误，例如：由于数据边际校验不强而引起系统异常死机，程序显示不正确等；第二类是算法错误，即程序中某些数据的计算方法不正确，或数据更新不完整。对于第一类错误，我还好测试些，毕竟出现问题后，一目了然。但对于第二种错误，我根本无法察觉，例如一套产品的最终价格是58，我很难直接判断出这个价格是正确计算结果，还是有问题。但对于有丰富经验的业务员来说，他们是很容易做到的，因为这些价格他们太熟悉了。 考虑到我在测试过程中很难发现第二类错误，所以就和Gentleman商量，看能否找人来协助我做这部分的测试工作。（当时我以为Gentleman的日子过得很潇洒，身在国外，遥控公司，自己则周游列国，好不自在。）而他也没含糊，一口就答应下来，我真是喜出望外。 其实我的想法仅仅是，让他找个心细的业务员来做系统的测试工作，但出乎意料的是，他居然亲自上阵，自己一个人来做测试工作。 正文：（十四）测试之痛2 Gentleman是一个办事认真仔细的人，他每次测试完一个模块后，都会详细地记录下错误的具体情况（效果、他估计的原因、在什么数据输入流程下出现错误等等），然后发一份错误报告给我。有时为了描述一个错误，需要要写上百字，并配以屏幕截图。我见过他在电脑上输汉字，基本上是二指禅的功夫，输入速度非常慢。所以我可以想象，他在做完测试后，敲上一篇上千字的错误报告需要多少时间。而且，后来我从Gentleman那也证实了自己的猜测，他花在写Email的时间，远多于测试时间。 虽然我多次建议Gentleman将测试工作交由下属去做，但他一直都没有同意。他说，系统的需求和设计过程，都是他全程参与的，换了谁都没有他这么清楚。其中有很多地方都是与原系统不相同的，如果换由其他人来做测试的话，是测试不出问题来的。他坚持测试到基本可用的状态，再交由其他人来做后续测试。 我真的为他这种认真的工作态度所感动，所以他每次发送新的错误报告后，我都会尽快把这个错误修改好。我们就这样合作，他一有空就测试程序，然后把错误报告发给我，我将修改好的程序发送给他，他最后再做一次错误修正后确认测试。为了我们的测试能基于相同数据，我们之间还经常交换数据库，固定以某段数据为测试基础。初略估计，这个测试阶段他的工作量应该是我的2-3倍，因为大部分的Bug，都很容易修改，只有少量几个需要调整较多的地方。 看着系统一天比一天强壮，这种感觉真的很美妙，就像练健美的人看着自己的肌肉越来越发达，喝酒的人感觉自己酒量越来越大一样，都是很享受到事情。 同时，Gentleman也基本上切换到新系统下工作了，只是用老系统来查以前的数据。因为有了新系统的比较后，他已经无法忍受老系统的低效率了。 正文：（十五）测试之痛3 系统经过Gentleman和我的多次测试和修改后，健壮性得到了显著的提高。在测试期间Gentleman想从CA国飞回来，专程为系统上线前做最后的实战测试。我是不赞同的他这么做的，当时正好赶上万众瞩目的北京奥运会，他的签证上也遇到了些麻烦，所以也就顺利成章地取消了这一临时计划。 虽然Gentleman自己没回来，但他专门安排了他的助理（本文中称呼为MissLee）来协助我做上线前的最后测试工作。我和Gentleman协商后，制定的计划是：测试数据库放在MissLee的电脑上（以后再配备专用的数据库服务器），首先在营销部的5台电脑上安装客户端程序。即本套系统先由营销部来做实战测试，因为他们的业务中使用到的模块最多，数据所走到流程也最全。当系统测试没有问题后，再全面推广到公司的所有机器上，这个过程预计2-4周。 系统安装到营销部后的那些天，他们马上就有很多信息反馈。依据Gentleman的要求，营销部所有的反馈意见都统一发到MissLee那儿，再转交给Gentleman本人。Gentleman和MissLee会对这些信息反馈进行分析，例如：哪些意见是非常正确的，系统的确需要在某处添加数据项、添加功能或数据导出。然后他们会整理好，发送Email给我。我越来越觉得Gentleman真是个Good Partner，他的事先安排，让我的工作井然有序，而不是面对嗡嗡作响的各种嘈杂意见，这应该是很多人值得学习的地方。 当然，这期间系统也有很多'莫名其妙'的错误，例如，他们在导出一份报表文件的时候，进度条总是停在30%处就不动了。而我在自己的电脑上，和Gentleman的电脑上都测试不出这样的问题（这些问题大多是因为，产品库中缺少了某些产品的图片啊，或金山词霸的自动取词功能引起系统中特效按钮显示不正确等等）。类似于这种情况的问题大概有五六次，我都是需要及时到现场测试，然后逐一排查原因，最终找到问题所在。 解决这些疑难杂症的话说起来很轻松，但在实际找寻错误的过程中，没有交流，只有自己一个人琢磨。都是在结合程序源代码的基础上，仔细排查错误，这个过程既曲折更痛苦，需要相当的开发经验。以至于后来Gentleman开玩笑，说我无所不能，在我这所有问题都不是问题。 经历了半个多月的系统测试后，营销部人员，也由最初的对系统很不放心，到享受系统带来的高效工作。 讨论篇3：项目之上的情感 在本文前面的若干节中，我已经多次提及Gentleman身上的特点，认真仔细，善待员工。原本我以为他平时的工作很轻松，可后来才知道，他每天工作都在十小时以上。国内与CA国有八个小时的时差，这边白天上班的时候（他那就是17:00-01:00），他基本上都挂在IM上，随时与公司这边保持着联系，而且还要处理大量的客户Email。 现在回想起测试阶段，我把大量的测试工作都交由他来做，真是于心不忍。系统安装到营销部的时候，MissLee和其他同事也都说Gentleman非常辛苦，希望系统能给他减少负荷。我当时心中就在想一个问题，当今社会，有几家公司的员工会这样为老板说话？大家为什么会这样向着老板说话？如果Gentleman身上没有特殊的品质，员工又是会怎么样？看到了这些，我就不难理解，为什么一家30人不到的贸易公司，每年的贸易量却能达到2000标箱以上。 今年一场金融危机几乎席卷了全球，我由于炒股的原因，所以非常关注全球各股市的走势。我能意识到这场危机对于出口型公司的冲击会有多大，所以在9月18日的时候，冒昧地给Gentleman发了一封与项目无关的Email。全文如下： “您好！ 不知您最近是否关心全球经济动向？现在能看到的情况已经非常糟糕。美国五大投资银行已经倒闭和被他人收购了三个（贝尔斯登、雷曼、美林），另外两个（高盛、摩根士丹利）也是关注的焦点，昨天高盛股价下滑23%，摩根士丹利股价大跌44%。 上周我和一个高中同学（他是耶鲁博士毕业，就职于美国雷曼兄弟公司纽约总部）MSN上聊天，他说美国遇到1929年以来最大的金融危机。上周末雷曼即宣布破产，美联储前主席格林斯潘在接受采访时也说，美国遭遇百年不遇的金融危机，经济回退很难避免。美股最近3天出现了2次4％以上的跌幅，这是美国911事件以来单日最大的跌幅。 我不清楚会对全球经济产生多大的振动，现在全球的股市（美洲、欧洲、亚洲）都是一片暴跌。波罗的海航运指数也从高点12000点，跌到现在不到6000点，这些都说明全球经济可能面临萎缩。我的一个朋友，是青岛一家4S店的总经理，他们最近2个月的汽车销售量为0，搞得他压力非常大。前天就是去他公司看套行业软件去了，和他聊了一下上面这些话题。他前期忙于生意，都不太清楚原来全球经济发生了这些事情，感觉他听后心情很沉重。您公司是做外贸，应该对这更敏感些，我也不了解这些变化会对咱们这个行业产生多大的影响，提前做有些准备总是有益的，希望我的担心是多余的。” 下面冒昧地将Gentleman的回信公布于此，希望他不会因此责怪我。 “谢谢你的关心！非常感谢，真的。我每天都在关注这些事情。一句话，冬天快要来了！ 1929年美国发生了大萧条，称为GREAT DEPRESSION.最近2－3年内，极有可能会发生GREATER DEPRESSION. 格林斯潘说，美国遭遇百年不遇的金融危机，并没有夸张－－虽然这是他一系列政策埋下的种子。 对于我们生意的影响有多大，现在还很难说。一种可能是：覆巢之下，焉有完卵？另一种是，沧海横流，方显出英雄本色。 （这话说的有点大了，我并没有把握。勉励自己而已。）谢谢！” 这封Email之后，我能明显感觉出我们的关系更亲近了，已经超出项目范畴了。一个人的成功不可能是偶然的，Gentleman身上有很多值得我学习的地方，在后续的Email中我直言，项目的收入对于我来说是次要的，能跟着成功男士学习优秀的品质对我来说更为宝贵。 正文：（十六）数据同步1 系统从一开始设计的时候，就有数据同步的需求，即公司局域网的电脑都访问中心服务器的数据库，而各台笔记本都访问本机上的分数据库，两者是完全同构的数据库。 由于在接这个项目之前，我没做过任何数据同步的项目。因此，一开始我还设想着自己写程序来实现数据同步功能，即设定时间点，然后通过程序导出每个数据库某段时间内的数据（新建、修改、删除），然后再将导出的数据进行比较，最终求出数据合集。可稍微考虑点详细的实现过程就觉得头大，情况太复杂了。如果要实现到应用的程度，可能单写数据同步程序所花费的精力，就远远超过了写业务程序，所以，最终放弃了这种不现实的想法。 （在校时，我的一位同学接了个进销存项目，可当时我们所掌握的技术主要集中在C++操作文件上，即所有的数据都是存储在二进制文件中。这老兄完成这个项目，楞是没有用数据库。所有的数据全用二进制文件来操作，读写删查都是自己写代码，没有用一句SQL。用他的话说，简直就是自己写了个数据库啊，累得快吐血，效果还很一般。） 同样的道理，如果我自己去写数据同步程序的话，我估计效果肯定和我那位同学当年一样。所以断然不能自己去写数据同步，即便我真有这能力写出来，那也不能这样做。因为如果业务发生变化或系统扩展，需要对数据库表进行调整（新增表或字段），那我的数据同步程序还要自己去重新完善，我想那一定是个场灾难。 数据对于任何公司来说，都是最宝贵的，所以我要选用成熟而安全的方式来实现数据同步。 正文：（十七）数据同步2 确定选用数据库同步工具来实现数据同步后，我就开始Google数据库同步工具，其中Sybase Mobilink进入了我的视线，它的主要功能介绍如下： “MobiLink 同步允许在符合 ODBC 标准的统一数据库和 Adaptive Server Anywhere 或 UltraLite 远程数据库之间进行复制。在本教程中使用的是 Adaptive Server Anywhere 远程数据库。统一数据库能够是使用 Sybase Adaptive Server Anywhere、Sybase Adaptive Server Enterprise、Oracle、Microsoft SQL Server 或 IBM DB2 生成的数据库。 MobiLink 适用于将一个统一数据服务器和大量远程数据库进行同步（通常包含多个移动数据库）。远程站点的管理和资源需要已降到了最低限度。此系统是基于偶连接的，并且远程站点可随时进行连接。在每次进行连接之后，数据库是完全同步的。 MobiLink 的工作方式是：将远程数据库上的多个事务的结果合并成一个更改集，然后应用到统一数据库中。因为同步始终在事务边界进行的，所以保持了参照完整性。不保留在组件事务过程中所做的各个更改的顺序：因为从不复制未提交的数据，所以保留了数据完整性。” 乍看到这些介绍的时候，我简直是喜出望外，这些同步功能简直就是为本项目需求所设计的啊。 我赶忙连夜下载了一套 Sql Anywhere 9 开发版（其中包含Mobilink同步工具），依据一些文档资料，我开始测试起数据同步功能来。先新建好一个中心数据库和两个远程数据库，然后按照文档中提供的例子，启动同步服务器和同步客户端。没想到进行得异常顺利，远程数据库和中心数据库的数据很快就实现了同步，我有点找不到北了，心想原本以为麻烦的问题，原来就是层窗户纸啊！ 可高兴劲还来得及过去，就发现一个问题，其他所有的同步都正常，就是删除操作的同步出来点问题。远程数据库中的删除可以正常同步到中心数据库上，但远程数据库之间却无法同步删除操作。具体情况的描述如下： 中心服务器取名CenterDB(Server)，两个远程数据库分别取名RemoteDB1(Client1)和RemoteDB2(Client2)，当你在RemoteDB1(Client1)中删除某条记录后，Clinet1执行同步语句后，能同步到CenterDB(Server)上，即CenterDB中也删除了这条记录。接着在Client2上执行同步语句后，却发现这条记录依然存在于RemoteDB2(Client2)中。 这是我在MobiLink使用过程中遇到的第一个麻烦。 正文：（十八）数据同步3 为了删除无法同步的问题，我到处Google解决方法，可网上几乎没有什么讨论MobiLink的文章，仅有的几篇都是介绍性的文章，逐渐地我开始有点毛爪了。可Gentleman在得知这个问题后，确表现得非常大度，他对我说，如果实在解决不了删除同步的问题，那系统在使用的过程中，就采取行政手段来同步。即需要数据删除的时候，大家就记录下来，然后互相发Email通知。 我很难想象在系统使用过程中，大家互相发Email通知删除的时候，会顺便暗自问候我这个程序开发者多少次。我没得选择，必须找出办法来。在翻了很多资料和搜索大量网页后，终于在Sybase网站上一个英文的帮助文件上，找到了这个问题的解决方法。 原来MobiLink在实现数据同步的过程中，中心数据库的删除就是无法同步到远程数据库上，而远程数据库的删除可以同步到中心数据库上。如果想实现这种删除的数据同步，有两种解决办法。第一种方法是建立影子表，即对每个表都新建一个影子表，某条记录删除的时候，都在其对应的影子表中记录下删除行的主键；第二种方法是逻辑删除，即在每个表中建一个删除标识字段。 考虑到实现的复杂度，我最终选用了逻辑删除的方法。但紧接着另一个问题又来了，此时的程序编码工作差不多完成了70%左右，现在把程序中所有的真实删除都改成逻辑删除，源代码中需要修改很多的地方。如何以最快最全的方法实现逻辑删除？我整整思索了半天，突然灵光一闪，想到了一个最佳方法。即从数据交互的父类中修改真实删除所调用的函数，把真实删除改的SQL语句改为逻辑删除所对应的SQL语句。这样只修改一处代码，即把系统中所有的真是删除都搞定。 我暗自夸奖自己：你怎么这么聪明啊！ 正文：（十九）数据同步4 在解决了MobiLink数据同步的中心数据库与远程数据库的删除同步问题后，我又开始测试数据同步的速度问题。发现局域网内和Internet网上MobiLink的数据同步速度差不多，这让我很是高兴，可接着另外一个问题又开始困扰我了。 开始做数据同步测试的时候，由于数据库中的数据量很小，每次数据同步的时间大概在2-5分钟。而随着数据库中的数据逐步增加，发现同步所需的时间越来越长。MobiLink资料上，都说数据同步的原理是依据日志文件中的数据库操作语句，对数据进行增量同步，即第二次同步的数据是第一次同步后的数据修改。这就让我很不理解了，为什么随着数据库的增大，同步的速度越来越慢，而且从同步服务器的滚屏显示上，明显是在扫描第一次同步以前的数据。 Google了N多的地方，都没有发现有讨论这个问题的地方，我又得自己摸黑前进了。凭借以往的经验初步推断，有两种可能原因，第一种是数据库的日志出来问题，第二种是数据库的MobiLink同步设置出来问题。 首先从第一种可能性考虑，我把ASA数据库的日志删除掉，重新构建日志。希望全新的日志能给我解决这个问题，可发现同步速度依然是老牛拉车。重构的新日志不行，我又遍查方法，希望能有日志整理的方法，把原先的日志重新整理。光折腾日志就花了我一个多星期，头也大了两圈，最终自认为是进来死胡同。 然后又考虑Mobilink同步设置的问题，把《Mobilink同步用户指南》《Mobilink同步参考手册》都翻了个遍，还查几乎所有能找到的资料，也都没查出所以然来。光前面两本书加起来就一千五百来页，真是郁闷得够呛。此时的Gentleman又给了我鼓励，说现在也能将就着用，无非就是速度慢些而已。可我心中明白啊，系统正式上线后，数据库会迅速加大，如果每次同步都是全扫描，那真是慢得跟头驴一样。 经过半个多月的查找，就在我几乎快绝望的时候，一次随意翻查《MobiLink Developer Resource Kit》的时候，居然发现里面有一篇“Mobilink数据分区”，详细地记载了如何设置实现数据的增量同步。这真是踏遍铁鞋无觅处，得来全不费功夫啊。我都感动得想喊出来，按照里面的设置方法，对数据库进行了相应的调整后，一测试，OK, No Problem。 那天，我感受到久违了的胜利喜悦，似乎一下子把我拉回到了读书时代。 正文：（二十）最后一次大考1 经过多次的数据库同步测试，我自认为已经大体上掌握了MobiLink的数据同步方法；同时，系统程序经过营销部的实际测试也日趋完善。与Gentleman商量后，决定系统在秋季广交会前全公司范围内上线。 由于前面的系统测试工作做得非常充分，所以系统上线后并未遇到任何技术上的问题，仅是某些部门和个人提出了一些小的功能修改意见。至此系统算是基本上线成功，但还有最后一次大考，那就是秋季广交会。 Gentleman和他的同事们，非常重视广交会，他们会在此前做好最细致的准备，其中包括参展的样品、名片的准备、笔记本、业务系统、打印机的调试等等。给我感觉就像上前线打仗一样，这比喻一点都不夸张。Gentleman说他们在以往的广交会上就是神经一直紧绷，来了客户以后，需要迅速给客户报出各种产品（或依据客户的需求组合的产品）的价格。其中容不得半点差错，价格报高了，会让客户失去兴趣，价格报低了，则公司蒙受损失。所以广交会期间，只要客户一来询价，大家就处于紧张状态，需要反复核算价格。 当然Gentleman这次去参加广交会是准备好了两套方案的，他们分别在新老两套系统中都输入好了参加广交会的新货号，如果新系统在广交会期间出现问题，他们就马上切换到老系统下使用。（这些是我事后从其他员工那儿得知的） 此次广交会，Gentleman他们租用来两个展厅，所以带去的六台笔记本组成2个局域网，分别在两处使用。整个广交会参展期间（大约10天时间），新系统不负众望，运行高效稳定，报价准确迅速，极大地减轻了Gentleman他们的工作量和精神压力。看着大家回来时对系统满意的神情，我心中甚是开心，说明新系统完全达到了预期的目的。 可就在广交会回来后的数据库同步过程中，我又挨了一记‘闷棍’——其中一台笔记本上的数据库与中心服务器数据库的同步过程中，出现了只下载数据不上传数据的奇怪现象。 正文：（二十一）最后一次大考2 由于全球金融危机的原因，今年的秋季广交会市场比较清淡，珠江三角洲附近以出口为主的家具和玩具企业纷纷倒闭。但从Gentleman那了解到，今年他们公司的情况还算不错，虽然比春季广交会的成交量差一些，但已经比预期的状况好多了。加之此次广交会上，由于新系统非常好用，所以在现场感觉工作比较轻松，并未出现手忙脚乱的现象。在此次广交会临近结束的时候，他们还特意举行了一场小型的庆功宴会。 大家从广交会上回来后，纷纷说新系统非常好用。得知这些喜人的消息，我自然也是非常高兴，在他们回来的第二天，我就去Gentleman公司那，帮他们把笔记本上的数据同步到服务器上。我原本预计最多一两个小时就能搞定的事情，可没想到居然整整耗了近十个小时（16:00 - 02:00 晚饭也没吃）。 因为出现了一个奇怪的现象，即其中一台笔记本与中心数据库同步的时候，只能下载数据，却无法上传数据，这让我一头雾水。因为这台笔记本上的同步语句和其他的都是一样的，MobiLink中的确提供了单向同步的设置，可我并未加上这个参数啊。问题出在什么地方呢？ 我仔细梳理着每一步环节，回想起来这台笔记本上的数据库与其他数据库不同在于，它的数据库是从另外一台笔记本上复制过来的。因为在广交会上，Gentleman是分两个展区的，而这第二个展区的开展时间比第一个展区晚两天，所以Gentleman当时在得到我的许可后，就把第一个展区用的数据库复制到了这台笔记本上。 而MobiLink数据同步的原理是，每个远程数据库都对应一个同步用户的，即每台笔记本都需要对应一个不同的同步用户。最初我认为MobiLink的数据同步过程，只要我不设置单向同步，即肯定是即上传又下载的。可那天经过我反复测试，发现对于一个新的同步用户，在初次与中心服务器做同步的时候，数据是只下载不上传的。 一开始，我以为是设置出来问题，可反复检查设置，并未查出问题。我再仔细琢磨MobiLink为什么这样处理？虽然我并未在任何MobiLink资料中印证我的猜测，但我最终认为这是MobiLink特意这样处理的。即对于一个全新同步用户，初次同步过程中，MobiLink的执行方法是只下载不上传的。其实这也很好理解，因在一个中心数据库和多个远程数据库发布的时候，只有默认这种方式才能最快完成同步，否则数据只有轮询同步两遍之后才能实现完全一致。在想明白了这一点后，我赶紧改变了方法，即采取手工SQL语句导出的方法，将那台无法上传数据的笔记本中的数据导出到文件中，然后再将这些文件数据导入到中心服务器内。 那晚，就这样琢磨后测试，测试后又琢磨，一直折腾到凌晨2点才把数据全部导入到中心服务器中。因为我清楚，如果不把数据整理好，Gentleman的公司明天就无法正常工作，所以一定要在那晚把数据整理好。 正文：（二十二）煮酒论英雄 那天为了将笔记本数据导入到中心服务器，我工作到凌晨两点，Gentleman为此深受感动。但我认为，一个值得我尊敬的合作伙伴，我就应该尽我全部的能量，将系统功能开发好，将数据同步完善好。 在这近一年的交往过程中，我深感Gentleman身上有太多值得学习的地方。所以每次Gentleman回国的时候，都是我抓紧学习的机会。为了有更好的交流时间，我迫不及待地在秋季广交会之前，就邀请Gentleman单独庆贺一翻。 Genteleman是个非常理性的人，在他的思想中，开发一套系统，无论投入多大精力和财力，只要系统能创造出更多的效益，那所有的投入都是非常值得的。而对于我来说，当前的新系统仅仅是第一步，只是简单地提升了业务的执行效率，并未给公司带来更多的利益。在我的头脑中，正在思索下一步的工作重点，如何能从繁琐的工作中解放出更多的人员？如何能让Gentleman站在全局的高度上，分析出公司的利润发展点和成本控制点？如何能有效地将营销部、海运操作部、财务部等各职能部门更有效得协同工作？我相信，心有多大，舞台就有多大。 借单独与Gentleman庆功的机会，我将自己成熟的与不成熟的想法都抛出来了。我们边饮酒边畅谈，对于新系统的下一步建设做了总体的规划，从这个规划中可见在Gentleman的心中，有更宏伟的蓝图，他希望建设的不仅仅是一个单纯的贸易公司，而是一个既有活力又有深度的集团性公司。   BEST PARTNER 全剧终  

此为转帖，编辑手下留情，我认为很不错，值得分享！ 关键字：程序员 私活 经验 外包作者：  row@csdn标题：个人外包项目全记 - Best Partner 地址：http://www.cnblogs.com/txw1958/archive/2012/11/06/programmer-personal-work.html 正文：（一）项目确立 一年前，CSDN的外包频道，一家贸易公司寻求开发业务系统。我注意到这家公司和我正好在一个城市，索性就跟了一帖，写了点简要的个人开发情况，当然最重要的是附上了自己的手机号码（当时CSDN外包频道还不限制这个信息的）。第二天就接到那家公司总经理的电话，这让我多少有点意外，电话中，双方客套两句后，约定好周末面谈。 和以往面试一样，我带上个笔记本（上面有以往开发的项目演示版）按照约定好的时间，准时去洽谈。地点是在对方的办公室，一进会客室，给我第一感觉整齐、清新、优雅、绿色；窗外则是宁静的半岛和微澜的海浪，心情顿时感觉非常畅快。 电话中那位非常绅士的总经理，年纪大概45岁左右，我们的谈话直奔主题。我先简单介绍了一下自己的情况（工作和开发经历），用笔记本演示自己以前开发过的两个类似项目情况，他则不时地提几个关心的问题。然后，他简单地将自己公司的需求告诉我，并把现行的系统的主要功能演示给我看了看。 整个谈话过程中，我印象最深刻的是他最后时刻说的话：“我看了你以前开发的系统演示，认为你完全有能力开发我们的系统；我也不打算再寻找其他人来面试，因为我的时间不允许我这样做。你如果觉得刚才我们谈到需求内容和开发价格都合适，那么我们就此开始合作。” 我是个程序员，他是个商人，我们的合作就此开始。 正文：（二）需求确定1 有了第一次的面谈，我对这家公司的整体印象不错。说起来，我以前去过不少公司（自己工作过的公司或谈项目去过的公司），尤其是从事贸易的公司，还是第一次见到办公室这样让人感觉如此舒服的。 简单说一下我需要开发的系统，其实并不复杂，就是一个典型的贸易系统，主要功能是管理公司的产品、客户信息，然后给客户报价、生成合同、给厂家下生产单等等。当然，这每一个模块中都会有很多特定的需求，例如，产品的价格组成，当某些价格组成发生变化时，系统需要自动更新到所有可能产生影响的部分去。 （那位非常绅士的总经理，为了叙事方便，给他取个名字吧，就叫Gentleman吧） Gentleman把他们现在使用的系统，发了一份给我，在我看来这个系统简直就是一个学生的实习作业。无论从系统的性能上，还是操作的界面上，逻辑的条理性上，都存在很多的问题。但就是这样的系统，Gentleman居然使用了近7年的时间，这让我感到很惊讶，甚至于难以理解。而Gentleman经常在需求的沟通过程中，提到他们原先的系统如何如何实现，我心中总是会非常不舒服，觉得拿这样原始而粗糙的系统来与即将开发的系统相提并论，我认为是对我的轻视或者说低估。 对了，需求中有个重要的部分，那就是数据同步。因为Gentleman长期定居在国外，每年只回国两次，每次大概一个半月，平时他都是通过IM和Email来管理他的公司。 正文：（三）需求确定2 我用2天时间，把他们原先的老系统的所有功能，都'学习'了一遍，在自己大脑中已经有了一个比较清晰的轮廓。其实行业软件，大家只要熟悉其业务流程，就会感觉非常简单。因为从程序实现上来看，主要工作就是数据库的表结构设计，以及相关前台界面的操作合理性。 Gentleman在他回CA国之前，约我再见一次面，并给我发来一份他自己整理的需求文档（20页左右）。因为我白天要正常上班，而他的返程机票已经订好，所以我们只能约定好晚上见面。这次，他约我的地点是一家五星级酒店的自助餐厅。用他的话说，他不知道该去哪合适，只知道这个地方吃饭还比较自在，他喜欢这的环境。这家自助餐厅给我留下的印象，就是用餐的外国人比中国人多，当然Gentleman给我的感觉也有点像个外国人，只是和我说话的时候还是用中文而已。 我们边吃边谈系统的需求，他把自己需求文件中描述的内容，再给我讲述一遍。而且讲得非常仔细，生怕我有不明白地方。其实他说的大部分内容，对于一个有8年开发经验的程序员来说，完全没必说得这么细致。当然，我也不打断他的思路，只是默默地听着，因为我不想让他以为我很狂妄。我看着他认真的神情，思想反倒有点走神，脑子里寻思这一个问题：我什么时候能像他这样工作和生活？ 就系统的需求，我们聊了大概有3-4个小时，从自助餐厅到酒店大厅的会客区。Gentleman想把他所有能想到的想法和问题都告诉我，因为他明天就要飞回CA国，这半年内，再也没有这样好的沟通机会了，毕竟Email中的描述只能停留在字面上。 那夜，我回去后，脑子里并没想任何系统需求，只是一直在想：我什么时候能像他这样工作和生活？ 正文：（四）系统整体设计1 需求大致上了解以后，我开始着手系统的整体设计工作。 首先，从应用角度上来看，这个系统是准备在一家30人左右的公司运行，而且Gentleman需要在自己的笔记本上安装一套系统，并与国内公司这边进行数据同步。另外，他们公司在每年的春秋广交会期间，都会带产品去参展，期间有5-6台笔记本需要使用系统，以便随时给客户报价。所以说，各个数据库之间的同步，是这个系统的一个非常重要内容。 其次，我开发系统有个习惯，即在完成系统功能的同时，比较注重界面的设计。这个习惯，也让我在这个系统上多花了30-40%的时间（Gentleman对于界面并未做任何要求）。但我认为是必要的，我们程序员在写程序的时候，都使用IDE工具，我个人的感觉，如果这个开发工具非常丑陋或看起来别扭，在开发系统的时候，是会非常不舒服的。同理，业务人员每天都是使用这套系统来工作，如果系统的界面非常差，操作起来很别扭，那工作简直就是遭罪。 还有，系统的整体框架。我没有采用以前开发过度系统框架，虽然这样能节省我很多时间。但我仔细考虑了一下，由于这个系统对于时间要求并不紧迫，而我也想积累更多的系统框架，所以最终决定在原框架的基础上做许多升级改良，以便更试用于这套系统。 （不少程序员开发系统，是一套框架多处使用。我认为如果时间不是很紧张的情况下，完全可以设计更好的方案。这样在接下一单项目的时候，就可以有更多更好的系统演示给客户看） 系统的功能就像人的五脏六腑，界面则是人的长相和外衣；长相虽然不影响身体健康，但绝对影响找对象，呵呵，所以说，界面是个不大不小的问题。 正文：（五）系统整体设计2 Gentleman回CA国后的一个月内，他仍然每周都给我发过来最新的系统需求，其中有专题性质的（例如：某处的价格算法，以及价格调整的系列影响），也有系统整体性的需求调整。我则有条不紊地地分析着每份需求文件，从这些需求文件中，我能感觉到Gentleman对这个系统的期望值很高，因为他不仅是在提需求，甚至是在做程序设计工作，哪些部分需要加按钮，这些按钮完成什么功能，具体某个字段是下拉列表显示，还是弹出窗口等等。 在此期间，我并未急于做实质性的业务程序开发工作。我从Gentleman的众多需求文件，逐步整理和设计出系统的几个核心表结构，在这几个核心表结构还没有相对稳定之前，我是不会写一行业务程序代码的，这是原则。当然，我的程序框架的改进工作是一直在同步进行的，因为程序框架部分和业务程序部分几乎是平行的，只需要在框架中考虑到几处重要的StatusBar和ProgressBar，以及系统的整体显示风格即可。 （即便如此，在后续的开发过程中，还是出现了需要调整核心表结构的情况，当然这是后话，暂且不提） 随着核心表结构的设计过程，我的脑海中正在一步步地形成整套系统的数据脉络（主业务数据流和辅助数据流）。与此同时，Gentleman经常在发送新需求文件的同时，询问系统的进度情况。而此时的系统进度只是在我脑海中，在一份数据库表结构文件中（我没去写非常详尽的设计资料，因为一个人的系统没必要把过多的时间放在文档上，文档工作是对于协同开发小组比较重要的），我无法让Gentleman感知进度的情况。我只是告诉他正在做系统的设计工作，我也没发送改进好的程序框架给他看，我认为把一个半成品给对方看，还不如不给对方看。 Gentleman很理解我的工作，虽然我的当前的工作汇报只是停留在口头上。噢，又忘交代了，Gentleman在成为商人以前是学计算机专业的，不过，我至今还不知道他是否当过程序员。 中间插一讨论篇《程序风格》，本篇与这个项目开发有些关系，但并不纳入到正文中。 欢迎各位程序开发高手积极讨论一下。 讨论篇1：程序风格 程序是什么？不同的角度有不同的看法，比较经典的论断是 程序=数据+算法。数据是一套系统的核心，他的地位是不可动摇的，好比人民的温饱问题。算法是什么，算法是系统的引擎，算法的好坏优劣决定了程序执行的效率。但随着现在硬件技术的提高，很多程序员已经淡化了算法的重要性，以完成功能为标准，这是可悲的事情。 依我的看法，程序不光是数据+算法，那只是程序的行体部分；程序还需要有风格，这才是程序的神态部分。只有形神兼备的程序，才是一个优秀的程序。程序风格又包涵哪些内容呢？在解释这个问题之前，我们先设想一下，如果一个闭月羞花的美女，出口就是脏字；如果一篇行文洒脱的文章，字确写得东倒西歪；如果一座雄伟的山峰，上面确寸草不生。那样是不是很煞风景？ 程序风格是什么？程序风格就是一个程序中，在数据内容以外所体现出来的内涵，它表现在程序的各个方面。从使用者的角度：主要体现在程序的整体显示风格（颜色基调、图标风格、字体大小）和交互风格（数据组合方式、功能区划分、操作流程）；从程序开发者的角度，它包括项目的管理、源文件的组织、代码的风格、注释的写法。 对于一个人的项目，程序的风格就取决于你的个人风格。程序员在锻炼开发技术水平的同时，应该同时培养你的程序风格。 恭候拍砖！ 正文：（六）Coding 1 程序的风格和核心数据库表基本确定后，我开始了系统的模块设计和编码工作。我的基本思路是，按照程序模块的重要性，逐个模块实现。单个模块的设计和编码同时进行的，完成好一个模块，就发送给Gentleman审核，以模块程序为交流载体，方便双方沟通。 夜晚22:00后，静夜孤灯下，一杯水，一个人。时而低头沉思，时而握笔绘图，时而指走键盘，这就是我平时工作的画面。一行行代码，一个个画面就这样跃然屏幕上。 系统中最先做到是产品管理模块，大家可能会认为这样的模块应该是比较简单的。是的，如果只是实现新建、编辑、删除功能的话，肯定很简单，但我确故意要将简单的东西复杂化。厨师的水平高低，不在菜上，而在于做菜的功夫上。 我在实现产品管理模块时，考虑到很多问题。如何将主货号和详细货号关联？主货号中的哪些字段应该与详细货号中的相同，两者之间应该怎么显示和编辑最合理？程序实现的过程中，哪些模块可以共用，哪些字段需要冗余？编辑某个货号的时候，应该怎么显示其他货号的详细内容作为参考？怎么让业务员输入最少的信息即可完成操作？ 上面这些问题，有Gentleman提到的，更有Gentleman没提到的。我认为系统的开发过程，就像一段外语的翻译过程，有人是直译，有人是意译，孰高孰低，明眼人一看就知道。至于其中多付出的劳动，虽然只有自己知道，但同样可以体现在你的劳动成果中。 在我的观念中，开发系统不仅仅是为了开发而开发，应该再提升一个高度，至少要让自己满意。后来证实我的思路是正确的，Gentleman对于我的程序实现方式，很满意，或者说赞赏。以至于他总是说我聪明，能准确地理解他的意图，并恰当地实现出来。具体体现在他的需求文档中，以往那些琐碎的、近似设计的描述少了，他只提他想要的结果，具体实现他已经不用操心了 - 这正是我的目的。 我和Gentleman的关系，开始有点像Partner了。 正文：（七）Coding 2 自从编码开始后，项目开发工作似乎进入了正轨。 这套系统的编码过程中，有一个十分麻烦的地方，那就是货号价格的变化，需要更新多非常多的地方。这些都是Gentleman在常年的工作中总结出来的，他心中非常清楚。他只要一看这些价格数字，就能知道哪些是正确更新后的，哪些是未更新的。可我在短时间内确是很难做到的这一点的，因此，我单独写了一份价格更新对照表，虽说整理着份文件花了不少时间，但磨刀不误砍柴功，这份文件在后续的工作中发挥了重要的作用。 因此，我认为在开发过程中，对于那些容易混淆或需要非常仔细的地方（例如：本系统中的各种价格组成、公式、更新对照等），应该单独写份文档作为项目参考资料（这份文档一定要准确无误），即便是一个人开发系统，也有必要。就像Windows API参考文档一样，当程序需要调用具体API函数的时候，只要查一下参考文档就可以了，完全没必要去记住那些具体参数，因为短时间内去记住那些参数，是不现实的。随着开发的过程，对于那些经常调用的部分，自然就熟悉了。 编码的过程，是对设计的逐步修正的过程。设计时理解不准确的部分，在Coding的过程中，都会逐一发现。 很多人羡慕一个人开发系统，其实一个人开发系统的优势和劣势同样明显。优势在于整个开发中，省却了所有的开发沟通时间，因为整个系统（哪怕是非常细小的环节）都了然于胸；劣势就是孤单，遇到任何技术问题都必须自己一个人去解决，解决问题后的快感也没人分享。 这个劣势在后续的开发中，给项目带来了一点问题。 正文：（八）Coding 3 编码的工作是辛苦的，远没有程序设计时的天马行空，需要的是严谨的工作态度、良好的编码习惯和相对完整的开发时间。对于Part-Time开发者来说，很多人觉得非常辛苦，主要是因为没有完整的开发时间。 项目的开始阶段，一般开发者都能保持相对高的开发热情，但一旦进入编码的中期，这种热情支撑下的开发进度就开始疲态尽显。我也是遇到了同样的问题，项目进行了3-4个月左右的时候，开发进度明显比预期的低了很多，就连大洋彼岸的Gentleman也能明显感觉得到。 Gentlman开始有些着急了，经常在Email中询问开发进度（其实就是催促开发进度），并主动提出快速开发奖励。我非常清楚Gentleman的心思，首先，他是想在下一次的广交会之前使用上这套新的系统，以便提高工作效率；其次，他是认为我当前的系统开发质量比他原先预期的要好，所以很乐意提高开发费用。面对相对优厚的额外奖励（这是Gentleman高明的地方），我也很想提高效率，但由于种种原因我很难进入快速开发状态。 多说两句当时的情况，权当为自己开脱吧。其一，项目进展到3-4个月左右的时候，我老婆正到预产期，我可爱的女儿来到了这个花花世界；其二，在去年轰轰烈烈的A股牛市中，我这新股民怀着快速发财的梦想，在5500点的高位杀入了大量的资金，结果亏损严重，致命的是这些资金有大部分不是自己的存款。这让我承受了巨大的精神压力，几次出现失眠的情况。仅此两点，大家就可想而知我当时的状态了。 心态上无法进入工作状态，时间上无法保证开发时间，一个人的战斗，孤立无援，我把项目带入到了最艰难的境地。 正文：（九）Coding 4 面对Gentleman的额外奖励，我深感惭愧，虽然内心很想加快开发进度，但当时的心思确又很难聚焦到项目开发上来。这样浑浑噩噩的状态大概延续了一个月左右，项目的开发进度比预期已经差了一大块。我几次想在Email中告诉Gentleman我的痛苦，但炒股导致的心理失衡问题，怎么能让他去承担后果。我问心有愧啊！ 即便在如此情形下，程序的代码质量还是我把握的第一要素。要么不写，要写就一定要保证质量，我绝对不会做杀鸡取卵这样的事。盲目上线带来的一定是后续更大量的补救工作，同时也会影响客户的信心。这一点，应该也是Gentleman欣赏我的地方之一。 随着春季广交会时间的日益临近，Gentleman已经感觉到项目无法在此之前完成，但他表现得非常大度。不仅没有过多地责怪我，相反还继续鼓励我，额外奖励依然有效，只是要求我全力把程序开发好。Gentleman的做法，让我非常感动，我时常自己在问自己：如果我不能及时调整好心态，不能坚持把项目开发好，对得起Gentleman这样的好人吗？ 我的名言：生命就是折腾与被折腾的过程。 这浑浑噩噩的一个多月，其实就是我个人心态的筑底过程，而这心态铸底成功的因素中，我清楚，有Gentleman一份功劳。伴随心态的调整成功，项目开发也重新步入正轨。当然Gentleman也从CA国飞回到本市，开始筹备公司的春季广交会的展览。 准确的说，此时此刻，系统的编码工作已经完成了80-90% 正文：（十）数据库选型 个人项目中，心理层面的问题需要自我调节，技术层面的问题同样只能独自解决，下面就写点技术问题。 在这套系统的数据库选型中，我是经过一番思考的。从我个人技术熟悉程度上来说，是对DB2和Sql Server比较熟悉。但对于30人规模的中小型公司，没必要选用过大的数据库，Oracle、DB2这类首先被PASS掉了，在Sql Server、MySql、Sybase ASA中，MySql中，到底应该选用哪个呢？ 可能很多人认为Sql Server应该是首选，最初我也在重点考虑它。但是Sql Serverd数据库，部署起来有点麻烦，考虑到Gentleman是长期在国外生活，在系统开发的过程中，我时常需要对数据库的结构进行调整。因此，数据库一定要便于打包和部署。其次，考虑到数据同步问题，因为这个系统最终数据库的部署，是需要在公司本部放一个中心数据库，另外几台笔记本上各放一个远程数据库。而这些数据库之间，要能够非常方便的进行数据同步。此时Sybase的Mobilink同步技术就进入了我的视线。（在这个项目之前，我并未做过数据同步方面的工作） 综合上面两个主要问题，我最终选择了 Sybase Asa 数据库，这款数据库，非常方便部署。更新数据库的时候，只需要直接替换数据库文件和日志文件就可以。而且我从Mobilink的资料中了解到，它是基于偶连接的同步技术，专用于中心数据库与多个移动数据库的数据同步的解决方案。我心想：Mobilink技术简直就是为我们这种应用而设计的。 同为Sybase的产品，ASA数据库理应与Mobilink无缝衔接。 讨论篇2：技术与应用 很多在校的学生和入行的新人，总是最关心开发技术，而且最关注流行技术。就好像流行时装一样，看哪些语言或工具流行，就学哪样，有甚者把市场主流的应用开发语言都学了个遍。其实大家会发现一个问题，即便学习了所有的开发语言，仍然不可能就此成为开发高手，因为他们学到的只是外在功夫，而非内功。 关于技术的内功和外功问题，大家只需要在开发的过程中，稍微用心体会一下，就可以找到练内功的方法。写代码的时候是不是频繁 Ctrl+C 和 Ctrl+V ，而不去琢磨复制过来这段代码或算法的基本原理？函数中的参数设置，是否仅仅满足功能就可以，还是需要预留下某个扩展？哪些功能代码可以抽象成一个类来实现，而非在程序中到处Copy同样的代码？等等！ （书法作品中一笔一画即能体现深厚的功底，想成为行家，就应该在程序的每个地方有自己的心得） 同样的程序，从客户角度，他们关注的侧重点是完全不同的。依据我的开发经验，客户基本上不关注系统采用的技术架构，哪怕你说得天花乱坠，那最多只是谈价格的一点小资本而已。他们关注的是系统功能，能否设计出他们认为最快捷、最安全、最实用的系统。“落后”的技术，同样有广阔的生存空间。因为对于客户，适用的就是最好的。 一个人做项目的时候，请记住：技术不是越新越好，而是越适用于项目越好，越熟悉的技术越好。在技术上你站得越高，项目的成功率就越高。（想学习和锻炼新技术，最好请到其他的项目组中学习，因为一个人的项目，新技术意味着无数未知的问题） 恭候高手拍砖！ 正文：（十一）项目中期收款 Gentleman回国后的这一个多月时间，几乎一直在忙于春季广交会的事情，很少和我联系。只是约定等他从广交会回来后，让我去他那领取部分项目款。 （在第一次面谈的时候，Gentleman就问过我项目收费方式的问题。现在一般公司的付款方式是361方式，即30%作为项目启动款，60%在项目验收后付款，10%的尾款最后在确认系统运行正常后付清。而我给Gentleman的答复是，项目开发前我不收任何款，等系统基本成型后（即客户可以认同开发质量和效果后）付60%的项目款，正式上线运行后，再付40%的项目款。 我之所以采取这样的收款方式，首先，我对自己的开发实力有信心，相信客户在见到系统后，会乐于付款；其次，我考虑对方是一家公司，而我是个人开发者，让对方提前把钱付给个人，这其中的风险明显大于付给一家公司。而我关心的是项目款的多少，并非付款时间。） 这次，我们见面的地点是Gentleman在本市的House，我按照约定好的时间准时到达。他的房子位于本市一段黄金海岸线上，从室内就能看到浩瀚的大海，总面积约有160平米，价值至少两百多万。屋子以浅色调为主，家具并不多，显得非常整洁。用Gentleman的话说，他常年定居在CA国，这房子基本是空着，只是回来的时候住这，所以陈设简单了些。 我们的话题，始终围绕着房子，而并没有说太多关于项目的事情。那天，我才了解到，Gentleman在做生意之前，也是工薪族，居住在一套30平左右的老房子中。后来公司逐步地发展壮大，他家的房子也随之换了三次，地段一次比一次好，面积一次比一次大，而他现在在CA国的家，是一栋独门独院的木房子。 从Gentleman家出来的时候，我已怀揣着刚收到的项目款，心中虽说有几分成功的喜悦，但同样有几分抹不去的惆怅。 正文：（十二）意译的烦恼 在整套系统开发的过程中，我一直采用‘意译’的模式，对Gentleman所提出的需求进行改进设计，但也有例外的情况。系统中有一个模块是给工厂下生产通知单，在这个模块的处理上，就出现了问题。 公司当前的做法是依据合同中的产品数量，给工厂下达生产。一份合同由多种货物组成，每种货物的订购数量和外销价是不同的。实际工作中都是将一种货物中所有的订购数量都制定一家工厂生产，当时，我从逻辑角度上分析，认为存在这种可能，即一种货物分交给两家以上的工厂生产。 所以我在设计中提出了改进模块的设计思路，并汇报给Gentleman，他当时的反应显得有些犹豫。因为现在的实际工作中是不存在这样的情况的，如果系统能实现到这种程度，肯定是更灵活，因此他就准许了我的设计思路。 这个模块的设计和实现过程中，由于要实现到同一种产品分配给多家工厂，并且订购数量要动态分配和回收。所以需要考虑到情况就复杂了很多，时间自然也多花了N倍。最终实现出来的效果是非常不错的，操作员可以清楚地看出每份合同下达的生产通知单，以及每种产品的生产数量。 但以上所认为到的程序最佳实现效果，都仅仅是我个人认为的状态。当把这个模块拿到具体业务员那测试操作的时候，问题就显现出来了。他们都反映麻烦，第一，从思路上和现状有点差别，感觉别扭；第二，在操作步骤上又多了一步操作，耽误时间。最后，Gentleman在考虑再三后，让我把这个改进模块功能去掉，依旧实现最原始的需求。 后来我总结此次教训，虽然模块的功能更灵活、更强大，但客户只需要他想要的，改进模块一定不能成为画蛇添足。 正文：（十三）测试之痛1 程序编码工作逐步接近尾声，接踵而来的就是功能测试、模块测试、集成测试、系统测试等。对于系统测试，开发人员大都不愿意去做的，因为这是一项既繁琐、又无成就感的工作。 一套没有经过严格测试的系统，就像一匹没有缰绳的野马，谁也不知道它发飙的时候，会跑到什么地方去。再繁琐的工作也要做，初步的功能测试和模块测试工作自然是由我自己来完成。可我发现个问题，我只要输入一些数据到系统中，开始做测试工作，就会自然地进入到一种自我欣赏系统的状态中，一圈数据测试下来，只能找到少量的程序错误。 Bug大体上可以分为两类，第一类是程序错误，例如：由于数据边际校验不强而引起系统异常死机，程序显示不正确等；第二类是算法错误，即程序中某些数据的计算方法不正确，或数据更新不完整。对于第一类错误，我还好测试些，毕竟出现问题后，一目了然。但对于第二种错误，我根本无法察觉，例如一套产品的最终价格是58，我很难直接判断出这个价格是正确计算结果，还是有问题。但对于有丰富经验的业务员来说，他们是很容易做到的，因为这些价格他们太熟悉了。 考虑到我在测试过程中很难发现第二类错误，所以就和Gentleman商量，看能否找人来协助我做这部分的测试工作。（当时我以为Gentleman的日子过得很潇洒，身在国外，遥控公司，自己则周游列国，好不自在。）而他也没含糊，一口就答应下来，我真是喜出望外。 其实我的想法仅仅是，让他找个心细的业务员来做系统的测试工作，但出乎意料的是，他居然亲自上阵，自己一个人来做测试工作。 正文：（十四）测试之痛2 Gentleman是一个办事认真仔细的人，他每次测试完一个模块后，都会详细地记录下错误的具体情况（效果、他估计的原因、在什么数据输入流程下出现错误等等），然后发一份错误报告给我。有时为了描述一个错误，需要要写上百字，并配以屏幕截图。我见过他在电脑上输汉字，基本上是二指禅的功夫，输入速度非常慢。所以我可以想象，他在做完测试后，敲上一篇上千字的错误报告需要多少时间。而且，后来我从Gentleman那也证实了自己的猜测，他花在写Email的时间，远多于测试时间。 虽然我多次建议Gentleman将测试工作交由下属去做，但他一直都没有同意。他说，系统的需求和设计过程，都是他全程参与的，换了谁都没有他这么清楚。其中有很多地方都是与原系统不相同的，如果换由其他人来做测试的话，是测试不出问题来的。他坚持测试到基本可用的状态，再交由其他人来做后续测试。 我真的为他这种认真的工作态度所感动，所以他每次发送新的错误报告后，我都会尽快把这个错误修改好。我们就这样合作，他一有空就测试程序，然后把错误报告发给我，我将修改好的程序发送给他，他最后再做一次错误修正后确认测试。为了我们的测试能基于相同数据，我们之间还经常交换数据库，固定以某段数据为测试基础。初略估计，这个测试阶段他的工作量应该是我的2-3倍，因为大部分的Bug，都很容易修改，只有少量几个需要调整较多的地方。 看着系统一天比一天强壮，这种感觉真的很美妙，就像练健美的人看着自己的肌肉越来越发达，喝酒的人感觉自己酒量越来越大一样，都是很享受到事情。 同时，Gentleman也基本上切换到新系统下工作了，只是用老系统来查以前的数据。因为有了新系统的比较后，他已经无法忍受老系统的低效率了。 正文：（十五）测试之痛3 系统经过Gentleman和我的多次测试和修改后，健壮性得到了显著的提高。在测试期间Gentleman想从CA国飞回来，专程为系统上线前做最后的实战测试。我是不赞同的他这么做的，当时正好赶上万众瞩目的北京奥运会，他的签证上也遇到了些麻烦，所以也就顺利成章地取消了这一临时计划。 虽然Gentleman自己没回来，但他专门安排了他的助理（本文中称呼为MissLee）来协助我做上线前的最后测试工作。我和Gentleman协商后，制定的计划是：测试数据库放在MissLee的电脑上（以后再配备专用的数据库服务器），首先在营销部的5台电脑上安装客户端程序。即本套系统先由营销部来做实战测试，因为他们的业务中使用到的模块最多，数据所走到流程也最全。当系统测试没有问题后，再全面推广到公司的所有机器上，这个过程预计2-4周。 系统安装到营销部后的那些天，他们马上就有很多信息反馈。依据Gentleman的要求，营销部所有的反馈意见都统一发到MissLee那儿，再转交给Gentleman本人。Gentleman和MissLee会对这些信息反馈进行分析，例如：哪些意见是非常正确的，系统的确需要在某处添加数据项、添加功能或数据导出。然后他们会整理好，发送Email给我。我越来越觉得Gentleman真是个Good Partner，他的事先安排，让我的工作井然有序，而不是面对嗡嗡作响的各种嘈杂意见，这应该是很多人值得学习的地方。 当然，这期间系统也有很多'莫名其妙'的错误，例如，他们在导出一份报表文件的时候，进度条总是停在30%处就不动了。而我在自己的电脑上，和Gentleman的电脑上都测试不出这样的问题（这些问题大多是因为，产品库中缺少了某些产品的图片啊，或金山词霸的自动取词功能引起系统中特效按钮显示不正确等等）。类似于这种情况的问题大概有五六次，我都是需要及时到现场测试，然后逐一排查原因，最终找到问题所在。 解决这些疑难杂症的话说起来很轻松，但在实际找寻错误的过程中，没有交流，只有自己一个人琢磨。都是在结合程序源代码的基础上，仔细排查错误，这个过程既曲折更痛苦，需要相当的开发经验。以至于后来Gentleman开玩笑，说我无所不能，在我这所有问题都不是问题。 经历了半个多月的系统测试后，营销部人员，也由最初的对系统很不放心，到享受系统带来的高效工作。 讨论篇3：项目之上的情感 在本文前面的若干节中，我已经多次提及Gentleman身上的特点，认真仔细，善待员工。原本我以为他平时的工作很轻松，可后来才知道，他每天工作都在十小时以上。国内与CA国有八个小时的时差，这边白天上班的时候（他那就是17:00-01:00），他基本上都挂在IM上，随时与公司这边保持着联系，而且还要处理大量的客户Email。 现在回想起测试阶段，我把大量的测试工作都交由他来做，真是于心不忍。系统安装到营销部的时候，MissLee和其他同事也都说Gentleman非常辛苦，希望系统能给他减少负荷。我当时心中就在想一个问题，当今社会，有几家公司的员工会这样为老板说话？大家为什么会这样向着老板说话？如果Gentleman身上没有特殊的品质，员工又是会怎么样？看到了这些，我就不难理解，为什么一家30人不到的贸易公司，每年的贸易量却能达到2000标箱以上。 今年一场金融危机几乎席卷了全球，我由于炒股的原因，所以非常关注全球各股市的走势。我能意识到这场危机对于出口型公司的冲击会有多大，所以在9月18日的时候，冒昧地给Gentleman发了一封与项目无关的Email。全文如下： “您好！ 不知您最近是否关心全球经济动向？现在能看到的情况已经非常糟糕。美国五大投资银行已经倒闭和被他人收购了三个（贝尔斯登、雷曼、美林），另外两个（高盛、摩根士丹利）也是关注的焦点，昨天高盛股价下滑23%，摩根士丹利股价大跌44%。 上周我和一个高中同学（他是耶鲁博士毕业，就职于美国雷曼兄弟公司纽约总部）MSN上聊天，他说美国遇到1929年以来最大的金融危机。上周末雷曼即宣布破产，美联储前主席格林斯潘在接受采访时也说，美国遭遇百年不遇的金融危机，经济回退很难避免。美股最近3天出现了2次4％以上的跌幅，这是美国911事件以来单日最大的跌幅。 我不清楚会对全球经济产生多大的振动，现在全球的股市（美洲、欧洲、亚洲）都是一片暴跌。波罗的海航运指数也从高点12000点，跌到现在不到6000点，这些都说明全球经济可能面临萎缩。我的一个朋友，是青岛一家4S店的总经理，他们最近2个月的汽车销售量为0，搞得他压力非常大。前天就是去他公司看套行业软件去了，和他聊了一下上面这些话题。他前期忙于生意，都不太清楚原来全球经济发生了这些事情，感觉他听后心情很沉重。您公司是做外贸，应该对这更敏感些，我也不了解这些变化会对咱们这个行业产生多大的影响，提前做有些准备总是有益的，希望我的担心是多余的。” 下面冒昧地将Gentleman的回信公布于此，希望他不会因此责怪我。 “谢谢你的关心！非常感谢，真的。我每天都在关注这些事情。一句话，冬天快要来了！ 1929年美国发生了大萧条，称为GREAT DEPRESSION.最近2－3年内，极有可能会发生GREATER DEPRESSION. 格林斯潘说，美国遭遇百年不遇的金融危机，并没有夸张－－虽然这是他一系列政策埋下的种子。 对于我们生意的影响有多大，现在还很难说。一种可能是：覆巢之下，焉有完卵？另一种是，沧海横流，方显出英雄本色。 （这话说的有点大了，我并没有把握。勉励自己而已。）谢谢！” 这封Email之后，我能明显感觉出我们的关系更亲近了，已经超出项目范畴了。一个人的成功不可能是偶然的，Gentleman身上有很多值得我学习的地方，在后续的Email中我直言，项目的收入对于我来说是次要的，能跟着成功男士学习优秀的品质对我来说更为宝贵。 正文：（十六）数据同步1 系统从一开始设计的时候，就有数据同步的需求，即公司局域网的电脑都访问中心服务器的数据库，而各台笔记本都访问本机上的分数据库，两者是完全同构的数据库。 由于在接这个项目之前，我没做过任何数据同步的项目。因此，一开始我还设想着自己写程序来实现数据同步功能，即设定时间点，然后通过程序导出每个数据库某段时间内的数据（新建、修改、删除），然后再将导出的数据进行比较，最终求出数据合集。可稍微考虑点详细的实现过程就觉得头大，情况太复杂了。如果要实现到应用的程度，可能单写数据同步程序所花费的精力，就远远超过了写业务程序，所以，最终放弃了这种不现实的想法。 （在校时，我的一位同学接了个进销存项目，可当时我们所掌握的技术主要集中在C++操作文件上，即所有的数据都是存储在二进制文件中。这老兄完成这个项目，楞是没有用数据库。所有的数据全用二进制文件来操作，读写删查都是自己写代码，没有用一句SQL。用他的话说，简直就是自己写了个数据库啊，累得快吐血，效果还很一般。） 同样的道理，如果我自己去写数据同步程序的话，我估计效果肯定和我那位同学当年一样。所以断然不能自己去写数据同步，即便我真有这能力写出来，那也不能这样做。因为如果业务发生变化或系统扩展，需要对数据库表进行调整（新增表或字段），那我的数据同步程序还要自己去重新完善，我想那一定是个场灾难。 数据对于任何公司来说，都是最宝贵的，所以我要选用成熟而安全的方式来实现数据同步。 正文：（十七）数据同步2 确定选用数据库同步工具来实现数据同步后，我就开始Google数据库同步工具，其中Sybase Mobilink进入了我的视线，它的主要功能介绍如下： “MobiLink 同步允许在符合 ODBC 标准的统一数据库和 Adaptive Server Anywhere 或 UltraLite 远程数据库之间进行复制。在本教程中使用的是 Adaptive Server Anywhere 远程数据库。统一数据库能够是使用 Sybase Adaptive Server Anywhere、Sybase Adaptive Server Enterprise、Oracle、Microsoft SQL Server 或 IBM DB2 生成的数据库。 MobiLink 适用于将一个统一数据服务器和大量远程数据库进行同步（通常包含多个移动数据库）。远程站点的管理和资源需要已降到了最低限度。此系统是基于偶连接的，并且远程站点可随时进行连接。在每次进行连接之后，数据库是完全同步的。 MobiLink 的工作方式是：将远程数据库上的多个事务的结果合并成一个更改集，然后应用到统一数据库中。因为同步始终在事务边界进行的，所以保持了参照完整性。不保留在组件事务过程中所做的各个更改的顺序：因为从不复制未提交的数据，所以保留了数据完整性。” 乍看到这些介绍的时候，我简直是喜出望外，这些同步功能简直就是为本项目需求所设计的啊。 我赶忙连夜下载了一套 Sql Anywhere 9 开发版（其中包含Mobilink同步工具），依据一些文档资料，我开始测试起数据同步功能来。先新建好一个中心数据库和两个远程数据库，然后按照文档中提供的例子，启动同步服务器和同步客户端。没想到进行得异常顺利，远程数据库和中心数据库的数据很快就实现了同步，我有点找不到北了，心想原本以为麻烦的问题，原来就是层窗户纸啊！ 可高兴劲还来得及过去，就发现一个问题，其他所有的同步都正常，就是删除操作的同步出来点问题。远程数据库中的删除可以正常同步到中心数据库上，但远程数据库之间却无法同步删除操作。具体情况的描述如下： 中心服务器取名CenterDB(Server)，两个远程数据库分别取名RemoteDB1(Client1)和RemoteDB2(Client2)，当你在RemoteDB1(Client1)中删除某条记录后，Clinet1执行同步语句后，能同步到CenterDB(Server)上，即CenterDB中也删除了这条记录。接着在Client2上执行同步语句后，却发现这条记录依然存在于RemoteDB2(Client2)中。 这是我在MobiLink使用过程中遇到的第一个麻烦。 正文：（十八）数据同步3 为了删除无法同步的问题，我到处Google解决方法，可网上几乎没有什么讨论MobiLink的文章，仅有的几篇都是介绍性的文章，逐渐地我开始有点毛爪了。可Gentleman在得知这个问题后，确表现得非常大度，他对我说，如果实在解决不了删除同步的问题，那系统在使用的过程中，就采取行政手段来同步。即需要数据删除的时候，大家就记录下来，然后互相发Email通知。 我很难想象在系统使用过程中，大家互相发Email通知删除的时候，会顺便暗自问候我这个程序开发者多少次。我没得选择，必须找出办法来。在翻了很多资料和搜索大量网页后，终于在Sybase网站上一个英文的帮助文件上，找到了这个问题的解决方法。 原来MobiLink在实现数据同步的过程中，中心数据库的删除就是无法同步到远程数据库上，而远程数据库的删除可以同步到中心数据库上。如果想实现这种删除的数据同步，有两种解决办法。第一种方法是建立影子表，即对每个表都新建一个影子表，某条记录删除的时候，都在其对应的影子表中记录下删除行的主键；第二种方法是逻辑删除，即在每个表中建一个删除标识字段。 考虑到实现的复杂度，我最终选用了逻辑删除的方法。但紧接着另一个问题又来了，此时的程序编码工作差不多完成了70%左右，现在把程序中所有的真实删除都改成逻辑删除，源代码中需要修改很多的地方。如何以最快最全的方法实现逻辑删除？我整整思索了半天，突然灵光一闪，想到了一个最佳方法。即从数据交互的父类中修改真实删除所调用的函数，把真实删除改的SQL语句改为逻辑删除所对应的SQL语句。这样只修改一处代码，即把系统中所有的真是删除都搞定。 我暗自夸奖自己：你怎么这么聪明啊！ 正文：（十九）数据同步4 在解决了MobiLink数据同步的中心数据库与远程数据库的删除同步问题后，我又开始测试数据同步的速度问题。发现局域网内和Internet网上MobiLink的数据同步速度差不多，这让我很是高兴，可接着另外一个问题又开始困扰我了。 开始做数据同步测试的时候，由于数据库中的数据量很小，每次数据同步的时间大概在2-5分钟。而随着数据库中的数据逐步增加，发现同步所需的时间越来越长。MobiLink资料上，都说数据同步的原理是依据日志文件中的数据库操作语句，对数据进行增量同步，即第二次同步的数据是第一次同步后的数据修改。这就让我很不理解了，为什么随着数据库的增大，同步的速度越来越慢，而且从同步服务器的滚屏显示上，明显是在扫描第一次同步以前的数据。 Google了N多的地方，都没有发现有讨论这个问题的地方，我又得自己摸黑前进了。凭借以往的经验初步推断，有两种可能原因，第一种是数据库的日志出来问题，第二种是数据库的MobiLink同步设置出来问题。 首先从第一种可能性考虑，我把ASA数据库的日志删除掉，重新构建日志。希望全新的日志能给我解决这个问题，可发现同步速度依然是老牛拉车。重构的新日志不行，我又遍查方法，希望能有日志整理的方法，把原先的日志重新整理。光折腾日志就花了我一个多星期，头也大了两圈，最终自认为是进来死胡同。 然后又考虑Mobilink同步设置的问题，把《Mobilink同步用户指南》《Mobilink同步参考手册》都翻了个遍，还查几乎所有能找到的资料，也都没查出所以然来。光前面两本书加起来就一千五百来页，真是郁闷得够呛。此时的Gentleman又给了我鼓励，说现在也能将就着用，无非就是速度慢些而已。可我心中明白啊，系统正式上线后，数据库会迅速加大，如果每次同步都是全扫描，那真是慢得跟头驴一样。 经过半个多月的查找，就在我几乎快绝望的时候，一次随意翻查《MobiLink Developer Resource Kit》的时候，居然发现里面有一篇“Mobilink数据分区”，详细地记载了如何设置实现数据的增量同步。这真是踏遍铁鞋无觅处，得来全不费功夫啊。我都感动得想喊出来，按照里面的设置方法，对数据库进行了相应的调整后，一测试，OK, No Problem。 那天，我感受到久违了的胜利喜悦，似乎一下子把我拉回到了读书时代。 正文：（二十）最后一次大考1 经过多次的数据库同步测试，我自认为已经大体上掌握了MobiLink的数据同步方法；同时，系统程序经过营销部的实际测试也日趋完善。与Gentleman商量后，决定系统在秋季广交会前全公司范围内上线。 由于前面的系统测试工作做得非常充分，所以系统上线后并未遇到任何技术上的问题，仅是某些部门和个人提出了一些小的功能修改意见。至此系统算是基本上线成功，但还有最后一次大考，那就是秋季广交会。 Gentleman和他的同事们，非常重视广交会，他们会在此前做好最细致的准备，其中包括参展的样品、名片的准备、笔记本、业务系统、打印机的调试等等。给我感觉就像上前线打仗一样，这比喻一点都不夸张。Gentleman说他们在以往的广交会上就是神经一直紧绷，来了客户以后，需要迅速给客户报出各种产品（或依据客户的需求组合的产品）的价格。其中容不得半点差错，价格报高了，会让客户失去兴趣，价格报低了，则公司蒙受损失。所以广交会期间，只要客户一来询价，大家就处于紧张状态，需要反复核算价格。 当然Gentleman这次去参加广交会是准备好了两套方案的，他们分别在新老两套系统中都输入好了参加广交会的新货号，如果新系统在广交会期间出现问题，他们就马上切换到老系统下使用。（这些是我事后从其他员工那儿得知的） 此次广交会，Gentleman他们租用来两个展厅，所以带去的六台笔记本组成2个局域网，分别在两处使用。整个广交会参展期间（大约10天时间），新系统不负众望，运行高效稳定，报价准确迅速，极大地减轻了Gentleman他们的工作量和精神压力。看着大家回来时对系统满意的神情，我心中甚是开心，说明新系统完全达到了预期的目的。 可就在广交会回来后的数据库同步过程中，我又挨了一记‘闷棍’——其中一台笔记本上的数据库与中心服务器数据库的同步过程中，出现了只下载数据不上传数据的奇怪现象。 正文：（二十一）最后一次大考2 由于全球金融危机的原因，今年的秋季广交会市场比较清淡，珠江三角洲附近以出口为主的家具和玩具企业纷纷倒闭。但从Gentleman那了解到，今年他们公司的情况还算不错，虽然比春季广交会的成交量差一些，但已经比预期的状况好多了。加之此次广交会上，由于新系统非常好用，所以在现场感觉工作比较轻松，并未出现手忙脚乱的现象。在此次广交会临近结束的时候，他们还特意举行了一场小型的庆功宴会。 大家从广交会上回来后，纷纷说新系统非常好用。得知这些喜人的消息，我自然也是非常高兴，在他们回来的第二天，我就去Gentleman公司那，帮他们把笔记本上的数据同步到服务器上。我原本预计最多一两个小时就能搞定的事情，可没想到居然整整耗了近十个小时（16:00 - 02:00 晚饭也没吃）。 因为出现了一个奇怪的现象，即其中一台笔记本与中心数据库同步的时候，只能下载数据，却无法上传数据，这让我一头雾水。因为这台笔记本上的同步语句和其他的都是一样的，MobiLink中的确提供了单向同步的设置，可我并未加上这个参数啊。问题出在什么地方呢？ 我仔细梳理着每一步环节，回想起来这台笔记本上的数据库与其他数据库不同在于，它的数据库是从另外一台笔记本上复制过来的。因为在广交会上，Gentleman是分两个展区的，而这第二个展区的开展时间比第一个展区晚两天，所以Gentleman当时在得到我的许可后，就把第一个展区用的数据库复制到了这台笔记本上。 而MobiLink数据同步的原理是，每个远程数据库都对应一个同步用户的，即每台笔记本都需要对应一个不同的同步用户。最初我认为MobiLink的数据同步过程，只要我不设置单向同步，即肯定是即上传又下载的。可那天经过我反复测试，发现对于一个新的同步用户，在初次与中心服务器做同步的时候，数据是只下载不上传的。 一开始，我以为是设置出来问题，可反复检查设置，并未查出问题。我再仔细琢磨MobiLink为什么这样处理？虽然我并未在任何MobiLink资料中印证我的猜测，但我最终认为这是MobiLink特意这样处理的。即对于一个全新同步用户，初次同步过程中，MobiLink的执行方法是只下载不上传的。其实这也很好理解，因在一个中心数据库和多个远程数据库发布的时候，只有默认这种方式才能最快完成同步，否则数据只有轮询同步两遍之后才能实现完全一致。在想明白了这一点后，我赶紧改变了方法，即采取手工SQL语句导出的方法，将那台无法上传数据的笔记本中的数据导出到文件中，然后再将这些文件数据导入到中心服务器内。 那晚，就这样琢磨后测试，测试后又琢磨，一直折腾到凌晨2点才把数据全部导入到中心服务器中。因为我清楚，如果不把数据整理好，Gentleman的公司明天就无法正常工作，所以一定要在那晚把数据整理好。 正文：（二十二）煮酒论英雄 那天为了将笔记本数据导入到中心服务器，我工作到凌晨两点，Gentleman为此深受感动。但我认为，一个值得我尊敬的合作伙伴，我就应该尽我全部的能量，将系统功能开发好，将数据同步完善好。 在这近一年的交往过程中，我深感Gentleman身上有太多值得学习的地方。所以每次Gentleman回国的时候，都是我抓紧学习的机会。为了有更好的交流时间，我迫不及待地在秋季广交会之前，就邀请Gentleman单独庆贺一翻。 Genteleman是个非常理性的人，在他的思想中，开发一套系统，无论投入多大精力和财力，只要系统能创造出更多的效益，那所有的投入都是非常值得的。而对于我来说，当前的新系统仅仅是第一步，只是简单地提升了业务的执行效率，并未给公司带来更多的利益。在我的头脑中，正在思索下一步的工作重点，如何能从繁琐的工作中解放出更多的人员？如何能让Gentleman站在全局的高度上，分析出公司的利润发展点和成本控制点？如何能有效地将营销部、海运操作部、财务部等各职能部门更有效得协同工作？我相信，心有多大，舞台就有多大。 借单独与Gentleman庆功的机会，我将自己成熟的与不成熟的想法都抛出来了。我们边饮酒边畅谈，对于新系统的下一步建设做了总体的规划，从这个规划中可见在Gentleman的心中，有更宏伟的蓝图，他希望建设的不仅仅是一个单纯的贸易公司，而是一个既有活力又有深度的集团性公司。   BEST PARTNER 全剧终

500年前，高层建筑，如同行式数据库一般，由墙壁提供水平支撑。由于当时钢铁数量有限、价格昂贵，如此大型的建筑物在高度上受到限制。美国最早期的高层建筑之一就是纽约市摩天大楼“世界大楼”，它高309英尺，共20层，建于1890年。台湾的台北101楼高1474英尺，共101层。诸如此类的现代摩天大楼则是垂直支撑在钢骨架上。目前，台北101是世界上最高的建筑物。但第一的地位很快将被取代。迪拜目前正在建造更高的建筑。这些现代摩天大楼如同列式数据仓库一般，它们的楼高可以并且也将越来越高。   “列式数据仓库以更低成本提供更佳性能，而且所用空间比传统行式关系型数据仓库更小——因此，很难理解为什么那些特别关注查询性能的公司不考虑采纳列式解决方案。”Philip Howard在他洋洋洒洒的报告《“列”酷在哪里?(What's Cool About Columns)》的结尾处写道。该报告发表于2008年3月，是专门提供给欧洲主要信息技术分析组织Bloor研究公司的。   不断成长   事实上，列式数据仓库——Sybase IQ分析服务器——是由其与Sun SPARC Enterprise M9000 Server和BMMsoft Server共同打造而成的全球最大的数据仓库的核心。这一开创纪录的成就涉及1PB(即1035 TB)的原始数据。(详情请见《2009 年吉尼斯世界记录》第 144 页)   我们知道列式数据仓库其实是由Sybase于1993年首创、并在1996年发布的，但近期发生的众多列式数据仓库的相关事件却才刚刚吸引人们的广泛关注。这或许会让人感到困惑，因为在其经过12年发展的今天，Sybase IQ才逐渐赢得主流市场的认同，列式数据仓库的竞争也开始表现得十分活跃。或许，正是上述表现，加上Sybase自身致力于向市场宣传其卓越的分析服务器，以及商业环境的变化(如人们要求在保持性能的同时降低成本)才是根源所在。   Bloor的Howard似乎同意这一观点：“在过去十年里，列式方法的使用在很大程度上一直是一个小众事件。”Howard注意到，近期有8个供应商进入到这个曾是Sybase独享的领域，且全球2000强公司越来越关注该领域，“我们相信，是时候让‘列’走出阴霾，成为数据仓库和相关市场的主要力量了。”他补充。   Sybase IQ目前约有1300名用户，由此可以说，如今的列式数据仓库已经走出了阴霾。在Bloor 13页的报告中，Bloor 详细说明了列式关系型数据库“可能曾经是什么”，和它们的作用、工作方法以及与传统关系型数据库相比的优势。早在2001年，Geoffrey Moore就评价说：它们是最根本、最前沿的技术。   当时，硅谷最优秀的技术大师之一、影响深远的商业书《跨越鸿沟》(Crossing the Chasm)一书的作者Moore认为，Sybase已经将经典的数据库行式架构模式“完全”改变为列式架构，提取数据的速度比传统数据库快100倍，而且支持与多人实时共享。“这是一种全新的模式，由此可以创造无限的市场机遇。”Moore特别强调了该产品的特点，“了解列式数据库对分析的含义。”优势所在  来自全球最大的数据库专家Winter公司的Richard Winter在《新时代的高效数据仓储》白皮书 (http://www.wintercorp.com) 中如此解释Sybase IQ的架构：“它旨在支持大量用户的并发运行特别是查询。因此，该设计和工程过程……首先关注的是查询性能，其次是完成批量数据更新的速度，再次是小数据更新的性能。这一优先排序与通用引擎截然不同，后者用于在线交易处理和数据仓储(实际上，这通常更强调交易处理)。这样的引擎必须尝试同时实现复杂查询的交互性能和高容量在线更新。由于Sybase IQ的设计目标严格以数据仓储为主，其架构和性能特征相当明显，这有利于数据仓库用户。”  例如，拥有数百万用户的在线购物服务可能需要基本的查询功能。问题可能是：随着圣诞节的来临，过去3年有多少纽约人购买了珠宝?为了回答这一问题，行式数据库将需要50万次输入/输出(I/O)重新定向。因为，行式流程将需要处理大量不相关的数据。在Sybase IQ的列式操作中，要回答此问题则只需要234次I/O。这些数字是利用1600万行、在一个表格上进行计算而获得的。事实上，要进行适当的查询，从每一列获取的数据应始终小于从传统数据库获取的数据。这意味着I/O次数减少，因此列式数据库的性能更佳。行式数据库管理员试图通过构建数据的摘要、聚合和索引，解决与行相关的问题，但是优先采用列式数据库便可解决所有问题。  上述就是Sybase IQ的设计与传统数据库的不同之所在：前者专门定向，提供分析用商业情报仓库，而后者主要用于完善交易——两者的任务不同。  “与行式架构相比，‘将数据储存在列中’采纳压缩算法，提供了大量提高性能的机会。”来自麻省理工学院的三位作者在2006年的一份报告《列式数据库系统集成压缩和执行》中如此描述。三位作者分别是Daniel J Abati、Samuel R. Madden 和 Miguel C. Ferreira。他们在报告中指出，在列式数据库中，采用一次性对多个值进行编码的压缩方案很自然。“而在行式数据库中，此类方案效果不佳，因为属性储存为整体元组(元素集)的一部分，因此将不同元组的相同属性，结合到一个值中将需要采取措施‘混合’元组。”他们解释。  来自Bloor的Howard写道：“从行到列的变化看起来微不足道，实际上意义深远。”正是由于人们越发认识到其意义深远，Sybase IQ的特殊分析列式存储才激发了如此大的热情。在业务环境下，任何人在开发数据价值的同时都随处面临数据超载的问题，他们也致力于寻求控制方法。此时，Sybase IQ的一个优势在于，其数据处理速度比传统方法快 100 倍。Sybase IQ的高速分析能力可几乎实时处理大量的特定查询。另一个优势在于，它仅处理可以回答这些查询的列，而不是分类整理与特定查询无关的数据行。这自然加快了流程。  此外，列式方法应用优化的压缩——效率高达 10:1 以上，同时，每个列的数据保持一致(种类、采购日期和地点)。这意味着可以使用更少的磁盘空间存储更多信息，从而提供更多可供分析的历史数据。  在Sybase IQ众多客户中，法国Prémalliance公司是法国国内主要的社会福利提供商。凭借Sybase IQ，该公司的技术成就脱颖而出，并荣获2008Computerworld Honors(2008 年计算机世界荣誉)的桂冠奖。  Premalliance需要整合和分析全球数据图表，展示其核心业务的福利合约所取得的商业、财务和技术成果。采用Sybase IQ的结果之一就是帮助Prémalliance完成其整合过程，并在不到5秒钟的时间内至少汇总3000万个数据行，而且不会对服务器造成巨大负荷。Prémalliance过去曾说，即使是为董事会董事准备报告也要求大量的IT资源投入，通常可以获得所需信息——但需要花2至3周才能将这些信息集合与组织起来。当然，今非昔比，Prémalliance仍有很多潜力可以挖掘，其发展可谓前程似锦。尾声..转点论坛个人热论已普及一下sybase IQ 的新鲜玩意提到发展方向，个人认为列式数据库在今后的发展中，应该考虑以下几个方向： 1，分布式计算：可能和楼上提的分布式列式数据库类似，希望看到可能是分步走的过程，先做CPU上面的分布；再做主机层面的分布；最后是存储层面的分布。这样可以更大地打开计算能力的瓶颈。列式数据库的列式存储的优势配合上分布式计算的优势，应该是未来的一个大方向。至于说叫不叫云计算都不重要。 2，进一步的索引优化：可能以新的索引的方式，可能以索引对查询/分析的使用方式等 3，分久必合，合久必分，我想行式数据库必定会有压力去突破，等行式数据库也慢慢地接受列式数据库带来的的技术冲击，最终我们会发现行式和列式其实在某一个层面上并没有那么大的差别，会某种意义上再合并起来，共同解决数据存储/使用的问题。个人观点： 行式数据库存储的时候大部分是采用堆表的方式，随机插入优势明显，列式数据库如果数据即索引，则随机插入的开销要大。每一列都有次定位和插入的动作，索引本身的维护量不会少。列式数据库本身还有其它形式索引，和行式相似。 大量的修改（varchar）时行式存储难免产生行漂移。这点恐怕对行数据库不利。 大量随机删除时堆表的维护应该是好于索引的维护的。 所以OLTP上行式数据库肯定优于列式数据库。 目前IQ上的索引基本也就改良B树和改良位图两类。全文检索应该是不太合适的。 查询特别是大范围查询，列式数据库因为是压缩存放的，所以IO上优势应该是明显的， 但牵涉到多表关联时更多取决于连接的join算法问题、统计结果的存放问题。现在市面上的OLAP产品也多， MOLAP的产品在这方面的优势明显，ROLAP在一定程度上处于劣势，虽然IQ增加了join index但该索引的维护很夸张。如果不能再做到分布式的数据分布，后期的扩展就有问题了。 分布式列式数据库在ROLAP上应该是发展方向。很好的讨论，坐等各位高手的意见。 关于列式数据库你知道多少？存储结构不同，使用场景不同，老牌的数据库厂商目前只有sybase有很成熟的产品，并且有些成功案例。 你知道列式数据仓库是谁首创的吗？目前声音最响的是sybase，谁首创真还不知道。 你知道全球有多少家列式数据库厂商？Sybase是目前最大的一家，还有一些小的列式数据库厂商。 你知道列式数据库与传统行式数据库有什么不同吗？主要是存储模式不同而导致查询效率、存储效率、索引模式等等方面都和传统行式数据库有很大差异。从列式数据库的实现Sybase IQ而言，相同的地方在于标准的借口和对SQL标准的支持。 你对列式数据库持什么样的看法呢？目前主要应用于OLAP领域，包括查询、统计、报表、分析、历史数据存储等等方面，OLTP领域不适合。列式数据库应该是一个方向吧，目前Sybase IQ是一个影响最大的实现产品，期待其它DB巨头的表态，好像Oracle新版本也在准备支持，如果这样的话，应该是一个方向。在BI系统中，一般批量ETL只是准备数据阶段， 在数据展现阶段还是会有大量的读操作。 当然，你也可以把数据展现交给OLAP SERVER去做，比如ESSBASE等。 但这样存在大量数据导入导出，构造CUBE等操作。 IQ当初的设计理念是 写节点处理批量ETL，读节点代替OLAP SERVER，直接支持各种报表类、分析类查询及ad-hoc查询。 因此，写节点需要高配置实现资源集中化，而读节点实现可扩展应付并发查询。 而且用读写节点物理分离的方式解决批处理与查询的资源竞争问题。找了几条比较好的扫扫自己的盲点      本文转自My_King1 51CTO博客，原文链接：http://blog.51cto.com/apprentice/1360626，如需转载请自行联系原作者

原文地址：http://www.oschina.net/news/58437/top-10-erp-software 如今，企业资源规划（ERP）和客户关系管理（CRM）系统的必要性已经被各种组织和企业所认可：ERP和CRM能够直接为企业的业务效率和利润做出贡献。 但 是随着今天企业商业形态的日趋多样化，互联网新经济的蓬勃发展，不同行业的企业都面临颠覆性技术和市场转型的挑战，这导致企业对ERP系统的需求日趋多样 化，而传统ERP系统往往无法满足企业的个性化需求。为了追求更高的业务灵活性、可扩展性和独特的信息技术竞争力，同时又不被传统ERP产品“锁定”，企 业往往会将目光投向开源ERP软件，基于开源代码定制满足自身需求的ERP系统。 今天，对于包括中国在内的新兴市场的中小型企业来说（SMBs）开源ERP系统的吸引力越来越大，因为开源ERP系统可以帮助他们升级或自定义自己的ERP系统，同时又无需支付大量的许可和支持的费用。 在2015年初始，作为送给那些走入创新深水区的中小企业和创业企业CIO们的一份礼物，我们将国外企业信息系统技术专家Steve Floyd一年前推荐的十大开源ERP软件根据最新发展动态重新整理如下： 1.  OpenERP ：提供全面的ERP和CRM模块 最 为开源ERP中的重量级产品，OpenERP对于大多数企业来说都提供了足够的可扩展性，同时还提供了销售管理、销售点管理、采购、库存管理、财务管理、 项目管理、制造、人力资源等等功能模块。OpenERP开发的初衷是为了提供SAP、Microsoft Dynamics等、CRM、人力资源管理、销售点管理、项目管理等众多方面。 OpenERP使用Python开发，数据库采用开源的PostgreSQL，它的核心和所有模块都是开放源代码的，采用GNU GPL开源协议。你可以自由使用、修改和发布，只要你也保证开源即可。 任何有一定技术基础的专业人员都可以下载和安装OpenERP，每月的订阅费只要39美元，任何企业都可以承担得起。订阅费包括安装包、自动升级和bug修复、在线托管和2小时的技术支持。 2.  Openbravo：功能极大丰富，但近年发展势头呈下降趋势 Openbravo的产品理念基于强调业务灵活性，是一个基于web的可扩展ERP系统，可以在任何网页浏览器中运行，目前在各行业已经拥有超过6000家企业用户。Openbravo ERP系统所包括的功能可实现生产管理、仓库管理、销售管理、财务管理。同时内置CRM（客户关系管理）和BI（商业智能）。 3.  ERP5:面向行业用户和政府部门关键任务的可靠性和成熟度 ERP5是一个基于web的全功能的ERP系统，采用了最新的软件技术开发，其面向文档的技术方法独特且富有创新性，其功能包括客户关系管理、生产管理、供应链管理、产品设计管理、财务管理、人力资源管理、电子商务等多个模块。 ERP5 开源ERP项目的创始者和推动者——法国Nexedi公司在不同领域有效的展开了ERP5的应用，比如航空，服装，银行，医疗及政府机构。ERP5被应用 于非洲，亚洲，欧洲，南美及北美的不同规模的企业。 ERP5的开源特质不仅削减了软件许可证费用， 并提供了完全自由的软件更新，而且可以根据客户的商业需求进行独立于销售方的系统定制。 值得注意的是，2013年11月Nexedi在上海外高桥自由贸易区投资成立了“纳宇软件科技”公司，成为第一个正式进入中国市场的Top10开源ERP厂商。 4.  Apache OFBiz：全面的企业软件框架 OFBiz是Apache的顶级开源项目，提供了创建基于最新JavaEE/XML规范和技术标准，构建大中型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类Web应用系统的框架。 OFBiz不仅是一个产品及订单管理系统，它还提供了一整套功能，涵盖企业所需的方方面面。除了管理产品及其相关内容（如电子商店）外，Apache OFBiz还能履行许多其它重要角色，包括客户关系管理、项目进度、计费管理、人力资源管理以及订单管理。 5.  Compiere：面向中小企业的ERP&CRM“云ERP” Compiere的开发者Consona自夸Compiere是当今最实施成本最低、适用性最强和最现代化的ERP系统。通过Compiere，你只需短短几小时就可以使用申购-采购-发票-付款、报价-订单-发票-收款、产品与定价、资产管理、客户关系、供应商关系、员工关系、财务管理、经营业绩分析等强大功能了。 值得注意的是，Compiere可以托管在亚马逊EC2云端运行，这也是首个支持云端部署的ERP系统。 6.  webERP：完全基于web的中小企业财务&ERP系统 顾名思义，WebERP是完全在线运行的ERP系统，可以在包括IE、火狐、Chrome等各种浏览器中运行。WebERP的开发者表示WebERP最适合的行业是制造业和经销商，零售业使用WebERP需要与第三方POS软件集成。 WebERP 是一套ERP与财务管理软件，它支持多公司、多币种、多税种、多库存管理；权限角色管理便于员工、客户和供应商使用；订单管理支持发 票的跟踪与管理；销售费用管理及强大的销售分析功能，为管理者提供决策支持；提供全面的财务特性包括总帐、应收/应付帐目等，且拥有简单易于操作的Web 界面。 中小企业会发现WebERP非常简单高效，但对于大型企业来说WebERP的功能还不够强大。WebERP目前可以从Sourceforge下载。 7.  opentaps:电商和零售的最爱 Opentaps全面集成了ERP和CRM套件功能，支持电商、库存管理、供应链管理和财务管理。此外Opentaps还提供可靠的业务报告和商业智能系统，而且还原生支持移动设备访问。 OpenTaps是在OFBiz基础上开发的开源的ERP及CRM企业级应用平台，其包含一个完整的应用程序套件，可与移动、商业集成。它支持客户关系管理、订单管理、存活和仓库、购买和支持链自动化、在线和卖点存储、帐户和财务管理等。 OpenTaps基于Java开发，支持大部分主流关系型数据，包括MySQL、PostgreSQL、Oracle、Sybase与Microsoft SQL Server等。 Opentaps的价格为600美元/用户，最低起售为10用户版本。 8.  Dolibarr：用户社区活跃的免费开源ERP系统 Dolibarr的特点是拥有一个活跃的用户社区，其商业模式类似苹果iTunes应用商店：Dolibarr系统本身完全免费，但是一些流行的模块或插件如项目管理、数字文档等则需要用户从从Dolibarr应用商店下载。 9.  ADempiere：回归纯粹的开源社区模式，近年发展势头呈现上升态势，值得关注 2006年，一些Compiere ERP的开发者不满公司主导的商业模式，另起炉灶成立了ADempiere。 ADempiere是一个由开源社区所领导的ERP 项目。由于Compiere是由公司为主导，虽然开放源码，但是在语言本地化以及文件数据都需要透过商业服务付费取得。而 ADempiere 的整个项目（包括源码、说明文件）都以开放的方式发布。 10.  PostBooks：商业ERP的孪生兄弟 PostBooks 是xTuple公司推出的一套开源ERP软件，简单易用，适合各种规模企业，尤其是中小企业。Postbooks最初是为制造业编写的应用，但随着时间推 移逐渐增加了CRM和财务等模块。PostBooks是xTuple商业ERP产品的开源版本，xTuple的多个商业产品都与开源版本共享相同的源码， 例如xTuple Standard、xTuple Manufacturing和xTuple Enterprise。 Postbooks 的可视化客户端可运行于Linux、MAC和Windows上（基于Qt组件库），使用的是PostgreSQL数据库，支持国际化。 PostBooks包含了会计、销售、CRM、购买、产品定义、清单、OpenRPT（一个强大的开源报告撰写工具）等模块。

什么是CMS 1CMS是Content Management System的缩写，意为“内容管理系统”。    CMS具有许多基于模板的优秀设计，可以加快网站开发的速度和减少开发的成本。    CMS的功能并不只限于文本处理，它也可以处理图片、Flash动画、声像流、图像甚至电子邮件档案。CMS还分各个平台脚本种类的。内容管理系统是企业信息化建设和电子政务的新宠，也是一个相对较新的市场，对于内容管理，业界还没有一个统一的定义，不同的机构有不同的理解：Gartner Group认为内容管理从内涵上应该包括企业内部内容管理、Web内容管理、电子商务交易内容管理和企业外部网(Extranet)信息共享内容管理（如CRM和SCM等），Web内容管理是当前的重点，e-business和XML是推动内容管理发展的源动力。Merrill Lynch的分析师认为内容管理侧重于企业员工、企业用户、合作伙伴和供应商方便获得非结构化信息的处理过程。内容管理的目的是把非结构化信息出版到intranets, extranets和ITE(Internet　 Trading Exchanges), 从而使用户可以检索、使用、分析和共享。商业智能系统(BI)侧重于结构化数据的价值提取，而内容管理则侧重于企业内部和外部非结构化资源的战略价值提取。 Giga Group 认为作为电子商务引擎，内容管理解决方案必须和电子商务服务器紧密集成，从而形成内容生产(Production)、传递(Delivery)以及电子商务端到端系统。我们认为内容管理系统是一种位于WEB前端（Web 服务器）和后端办公系统或流程（内容创作、编辑）之间的软件系统。内容管理解决方案重点解决各种非结构化或半结构化的数字资源的采集、管理、利用、传递和增值，并能有机集成到结构化数据的商业智能环境中，如OA,CRM等。内容的创作人员、编辑人员、发布人员使用内容管理系统来提交、修改、审批、发布内容。这里指的“内容”可能包括文件、表格、图片、数据库中的数据甚至视频等一切你想要发布到Internet、Intranet以及Extranet网站的信息。 CMS是如何应运而生的？随着网络应用的丰富和发展，很多网站往往不能迅速跟进大量信息衍生及业务模式变革的脚步，常常需要花费许多时间、人力和物力来处理信息更新和维护工作；遇到网站扩充的时候，整合内外网及分支网站的工作就变得更加复杂，甚至还需重新建设网站；如此下去，用户始终在一个高成本、低效率的循环中升级、整合……于是，我们听到许多用户这样的反馈：页面制作无序，网站风格不统一，大量信息堆积，发布显得异常沉重；内容繁杂，手工管理效率低下，手工链接视音频信息经常无法实现；应用难度较高，许多工作需要技术人员配合才能完成，角色分工不明确；改版工作量大，系统扩展能力差，集成其它应用时更是降低了灵活性；对于网站建设和信息发布人员来说，他们最关注的系统的易用性和的功能的完善性，因此，这对网站建设和信息发布工具提出了一个很高的要求。首先，角色定位明确，以充分保证工作人员的工作效率；其次，功能完整，满足各门道“把关人”应用所需，使信息发布准确无误。比如，为编辑、美工、主编及运维人员设置权限和实时管理功能。此外，保障网站架构的安全性也是用户关注的焦点。能有效管理网站访问者的登陆权限，使内网数据库不受攻击，从而时刻保证网站的安全稳定，免于用户的后顾之忧。根据以上需求，一套专业的内容管理系统CMS应运而生，来有效解决用户网站建设与信息发布中常见的问题和需求。对网站内容管理是该软件的最大优势，它流程完善、功能丰富，可把稿件分门别类并授权给合法用户编辑管理，而不需要用户去理会那些难懂的SQL语法。CMS是如何发展的？内容管理从2000年开始成为一个重要的应用领域，这时.COM和B2B, B2C等经历了资本和市场的考验及洗礼，人们重新回到信息技术应用的基本面－如何提高竞争能力，而内容管理恰恰能够通过对企业各种类型的数字资产的产生、管理、增值和再利用，改善组织的运行效率和企业的竞争能力，企事业单位也开始认识到内容管理的重要性。从企事业单位信息化的观点来看，以下因素导致对内容管理软件的巨大需求：(1) 知识是企业的财富。在Internet交互过程中，只有十分之一涉及销售，其他十分之九都和信息交互有关，员工的知识获取越来越依赖于互联网，特别是在电子商务的个性化环境中，客户为了做出购买决定，需要智能化地获取信息，不仅仅是商品的数量和价格，更重要的可能是产品的手册、安全保证、技术指标、售后服务、图片文件等等。什么是CMS 2 (2) 信息的及时性和准确性。无论在企业内网还是外网，信息的更新越来越快，企事业单位的信息生产量越来越多，且呈现成倍增长的趋势，企事业单位更需要的是一个功能强大、可扩展的、灵活的内容管理技术来满足不断的信息更新、维护，这时如何保证信息的准确性和真实性将越来越显得重要。 (3) 企业内外网统一的需求增长。随着企事业单位信息化的建设，内联网和外联网之间的信息交互越来越多,优秀的内容管理系统对企业内部来说，能够很好地做到信息的收集和重复利用以及信息的增值利用, 对于外联网来说，更重要的是真正交互式和协作性的内容。 国外从事内容管理软件研发的主要厂商包括Vignette,Interwoven, BroadVision, Openmarket，ATG，Allaire, Documentum, Hummingbird等，这些公司CM产品和解决方案专业性很强，大多基于J2EE等平台，功能丰富，主要面向企业级用户，是CM市场的主要厂商。还有一些更窄的专业厂商提供内容管理某个阶段需要的功能，如Verity 提供知识检索，Micromedia 提供内容创作平台，Akamai和Inkitomi 提供内容分发管理技术等。与此相反，Microsoft, IBM, Oracle等公司提供通用平台性CM解决方案。但是目前CM市场仍有很多不完善的地方，包括： 在这个全新的市场中很难找到一个CMS满足用户的所有需求。 有些CMS只是单纯的信息发布工具而以，称不上内容的收集和再利用更谈不上知识管理的概念，最多只是一组网站建设工具软件而已。 所有产品的可视链接都非常差，只有极少数厂商能够提供可视软件，这些软件都不是交互式的，不能用作管理工具。 CMS都有可能包括些什么？ 隐藏在内容管理系统(CMS)之后的基本思想是分离内容的管理和设计。页面设计存储在模板里，而内容存储在数据库或独立的文件中。 当一个用户请求页面时，各部分联合生成一个标准的 HTML 页面。 一个内容管理系统通常有如下要素： 文档模板 脚本语言或标记语言 与数据库集成 内容的包含物由内嵌入页面的特殊标记控制。这些标记对于一个内容管理系统通常是唯一的。 这些系统通常有对较复杂的操作的语言支持，如 Python, Perl, 或 Java 等。 内容管理系统对站点管理和创造编辑都有好处。这其中最大的好处是能够使用模板和通用的设计元素以确保整个网站的协调。 作者只需在他们的文档中采用少量的模板代码，然后即可把精力集中在设计之上的内容了。要改变网站的外观， 管理员只需修改模板而不是一个个单独的页面。 内容管理系统也简化了网站的内容供给和内容管理的责任委托。很多内容管理系统允许对网站的不同层面人员赋予不同等级的访问权限， 这使得他们不必研究操作系统级的权限设置，只需用浏览器接口即可完成。 其他的特性如：搜索引擎、日历、Web 邮件等也会内置于内容管理系统 CMS 内，或允许以第三方插件的形式集成进来。 如何开发CMS 内容管理系统是一个很泛的概念：从商业门户网站的新闻系统到个人的Weblog都可以称作发布系统。 框架型：本身不包含任何应用实现，只是提供了底层框架，具体应用需要一定的二次开发，比如Cocoon，Vignette； 应用型：本身是一个面向具体类型的应用实现，已经包含了新闻/评论管理，投票，论坛，WIKI等一些子系统。比如：postNuke xoops等； 但无论如何，在发布系统选型之前，首先了解自己的实际需求是最重要的：想根据现成系统将自己的需求硬往上照搬是非常不可取的。访问量，权限控制和各种功能需求。每个模块和功能自己都比较清晰一点以后，再去网上找找类似的实现：你会发现其实每个环节到目前上都有比较成熟的实现了，而且还在不断完善和发展中，如果没有：你的需求太特殊，或者可以尝试分解成更小的系统组合实现。 内容管理系统被分离成以下几个层面：各个层面优先考虑的需求不同 1，后台业务子系统管理（管理优先：内容管理）：新闻录入系统，BBS论坛子系统，全文检索子系统等，针对不同系统的方便管理者的内容录入：所见即所得的编辑管理界面等，清晰的业务逻辑：各种子系统的权限控制机制等； 2，Portal系统（表现优先：模板管理）：大部分最终的输出页面：网站首页，子频道/专题页，新闻详情页一般就是各种后台子系统模块的各种组合，这种发布组合逻辑是非常丰富的，Portal系统就是负责以上这些后台子系统的组合表现管理； 什么是CMS 3 3，前台发布（效率优先：发布管理）：面向最终用户的缓存发布，和搜索引擎spider的URL设计等……  内容管理和表现的分离：很多成套的CMS系统没有把后台各种子系统和Portal分离开设计，以至于在Portal层的模板表现管理和新闻子系统的内容管理逻辑混合在一起，甚至和BBS等子系统的管理都耦合的非常高，整个系统会显得非常庞杂。而且这样的系统各个子系统捆绑的比较死，如果后台的模块很难改变。但是如果把后台各种子系统内容管理逻辑和前台的表现/发布分离后，Portal和后台各个子系统之间只是数据传递的关系：Portal只决定后台各个子系统数据的取舍和表现，而后台的各个子系统也都非常容易插拔。 内容管理和数据分发的分离：需要要Portal系统设计的时候注意可缓存性（Cache Friendly）性设计：CMS后台管理和发布机制，本身不要过多考虑“效率”问题，只要最终页面输出设计的比较Cacheable，效率问题可通过更前端专门的缓存服务器解决。 此外，就是除了面向最终浏览器用户外，还要注意面向搜索引擎友好(Search engine Friendly)的URL设计：通过URL REWRITE转向或基于PATH_INFO的参数解析使得动态网页在链接（URI）形式上更像静态的目录结构，方便网站内容被搜索引擎收录； 都有哪些CMS提供商 Vignette. 奥斯汀, TX Vignette公司，网站内容管理系统的领导者，今天宣布在中层楼资金上它取得了1亿4千万美元，成为奥斯汀基础软件公司中最大的私人资产投资，同时也使Vignette成为在奥斯汀发展最快的互联网软件公司。 Vignette 公司，作为全世界网站内容应用系统的领导者，为公司们提出了解决方案——在互联网上建立非常成功的商业。 Vignette的王牌产品是StoryServer 3，它能使公司以应用软件（如在线发布、知识管理和复杂电子商务系统）为基础建立、管理和发布服务，最终加速和提高客户的忠实度和持续力。 超过75个一流公司，包括Ziff-Davis' ZDNet, First Chicago NBD, Bay Networks 和 CNET ，使用StoryServer 3 ，每天提供2500万个网页浏览。 StoryServer3 获得了5个行业奖励，包括UPSIDE杂志的“网络基础组织类最活跃的私人公司” 。 它的V/5 系列是一套应用软件包，设计用来为门户、B2C 和 B2B 市场需求提供内容管理。 V/5系列具有高度的可定制化能力和广泛的功能，它包括内容和模板的开发、个性化定制和发布。但是，它的多数功能还需要开发。  Documentum. Documentum 是文档管理解决方案的长期供应商。 带着它的4i 网站内容管理（WCM）版本，公司有力地进入了CM舞台，它提供了一个解决方案来支持具有在线而动态的内容的电子商务应用软件。对大中型组织来说，它也是一个健全的可扩展的网站内容管理解决方案。  Eprise. Eprise的 Participant Server 2.6.6是该公司内容管理的产品，它为大型商务和.com提供商业应用软件，包括互联网、企业内部网和公共网站。该产品能促进内容添加、修改和全球发布。 Participant Server 的主要组件包括内容中心、操作中心、共享中心和内容分配套件。 产品为投稿和创造提供基于网络的界面，同时内容分配组件处理适于交易的内容分配。A single Web based administrative interface is a plus because administration can be distributed across the organization.单一的基于网络的管理界面是附加的，因为管理在组织范围内可以是分布式的。  Interwoven. Interwoven的 TeamSite 4.5是横向聚焦的网站内容管理解决方案，它向财富500强和全球2000个上市公司提供企业范围的网站内容管理。TeamSite的管理和组成能力通过桌面和基于Java的接口提供，这种桌面和接口作为操作系统的一部分出现。用户可以通过Windows Explorer把内容拖放到存储库中。  Xpedio. Xpedio CMS 4.0是全球 2000 B2B 和 B2E 公司所用的解决方案包，它为没有技术的用户提供了容易使用的网站建设能力。 该产品在企业内部互联网、外部互联网和电子商务网站上促进了内容的快速发展和管理。在管理和发布内容方面，它是强大的解决方案，它提供具有分布式管理能力的创作工具、安全、发布的灵活性和完全基于浏览器的界面。  什么是CMS 4 Ncompass. NCompass Labs于2001年4月通过微软成立，现在它是微软的子公司。 Resolution 3.1是Ncompass的浏览器，以网站内容管理解决方案为基础，在2001年底，它做为微软的产品（称为微软内容管理服务器）再次发布。  Open Market. Open Market的Content Server 3.1是 J2EE兼容的内容管理解决方案，它嫦虺霭妗⒚教搴徒鹑诜袷谐　pen Market 把内容服务器定位为推动以内容为中心的电子商务应用软件的产品，它处理访问者、客户和合作者之间的交互。该产品有用于管理和组织的网络界面，包括了一个个性化的引擎和用于发布的应用软件服务器。  BroadVision. BroadVision 把应用方法用于内容管理，主要目标是B2B, B2E 和 B2C 市场。 BroadVision以应用软件程序包的形式出售产品，如出售给附带商业、合作商业、市场和雇员自我服务。内容管理解决方案也独立地出售。  FileNET. FileNET是文档管理市场的传统领导者，现在它集中精力于生产电子商务应用软件的Panagon生产线。它的网站内容管理套件包括Panagon 内容服务（PCS）、Panagon 网络发布者（PWP）、Panagon 网络服务（PWS）和Panagon 电子流程。FileNET套件主要面向于金融、保险、政府、电信、公共事业和制造业。FileNET把它的网站内容管理套件定位在内容管理的全部解决方案，它贯穿内容的生命周期，从创造到审批、发布和分配。然而，在它目前的版本中，产品在核心网站内容管理的功能性上需要重大发展，如个性化和动态内容的表达。  Megellan. 2000年7月，Gauss Interprise 和美国软件开发者Magellan 合并，主要销售它的内容管理系列Versatile Internet Platform (VIP)。VIP定位于企业管理内容、网站内容和门户的平台。对于集中的环境，产品系列有适应需求的基本功能，包括基于网络的管理，单一和大批的输入、第三方厂商提供的基本库服务、以及用于分布式内容创造的模板设计工具。  InStranet. InStranet成立于1999年，总部设在纽约，并且在巴黎设有欧洲总部。 公司的王牌产品是InStranet 2000 1.5，它是一个浏览器和基于Java的网站内容管理解决方案。产品聚焦于，在B2B和雇员工作环境下，向企业内部互联网和外部互联网发布业务文件和内容。InStranet 2000 1.5在J2EE兼容的应用服务器上运行，已在BEA WebLogic, IBM WebSphere 和 iPlanet 应用服务器上经过检验。  Mediasurface. Mediasurface 的总部设在伦敦，它的美国办事处在纽约和弗朗西丝科。公司为组织提供管理内容软件，用于企业内部互联网和外部互联网。公司的核心产品是Mediasurface 3.5，它瞄准垂直市场，包括金融服务、政府、教育、卫生保健、IT服务、媒体、出版和广播、零售和消费服务。  Six Open Systems. Six Offene Systeme GmbH 在美国称为Six Open Systems (Six) ，于1991年在德国成立。Six在德国有重要的消费群，它以产品Six CMS 4.0打入美国市场。 该产品是由内到外的、以浏览器为基础的解决方案，它用来帮助媒体出版商简化和管理内容设计及网页和门户、互联网、企业内部互联网等的设计。  Starbase. Starbase 销售合作产品，该产品为电子商务应用软件创造、管理代码和内容。2001年2月, Starbase收购了worldweb.net 和它的产品Expressroom I/O 、以及基于Java 和 XML的网站内容管理解决方案。Starbase正把Expressroom I/O添加到它的代码和内容管理解决方案的协作套件中。  国内用的比较多的有Active Context、turbocms、cms4i，不过这些都是纯商业性系统，价格很高，一般个人建站，建议选取一些国外比较有名的开源系统，如Mambo、Drupal、Tikiwiki、PhpNuke、PostNuke、Xoops、Tikipro、不过这些全是基于php + mysql的，众所周知，php和mysql是免费的吗^__ 本文转自peterzb博客园博客，原文链接：http://www.cnblogs.com/peterzb/archive/2006/04/24/383679.html，如需转载请自行联系原作者。

正是由于爱德华·斯诺登对于美国国家安全局的揭露;索尼遭受到全面的黑客入侵;以及正在持续进行的存储在云中的电子邮件到底是属于发件人还是服务托管机构的法律纠纷，促使越来越多的云服务迁移到了加密数据。有些甚至更进一步，提供了带上您自己的密钥(BYOK)的选项，使得用户拥有自己的云数据的加密密钥。 去年夏天，谷歌计算引擎开始为用户自己的密钥加密的数据和计算提供预览服务，而亚马逊则同时为EC2和S3云服务实例提供软键管理和价格更高的(设置较慢)云硬件安全模块服务(Cloud HSM service)，用户的密钥被存在亚马逊的云的专用硬件安全模块。Adobe创意云现在支持用户管理的数据加密密钥，用来保护同步到创意云帐户的内容。而微软的密钥库是一个单一的、经审核的、有相应版本的安全库，结合了Azure活动目录进行身份验证。密钥库允许用户存储密码、配置细节、API密钥、证书、连接字符串、签名密钥、SSL密钥和Azure权限管理的加密密钥、SQL Server TDE、Azure存储、Azure磁盘加密、用户自己在Azure上的.NET应用程序以及使用EMC的CloudLink安全虚拟机加密的虚拟机。在密钥库的密钥要么可以作为软键存储，在一个HSM中由系统密钥加密;要么直接从用户自己的HSM加载到微软HSM(在一个选定的地理区域)，所以您可以在您企业内部创建密钥，并将他们转移到密钥库。 Dan Plastina所运行的微软信息保护组就包括密钥库。他指出了以同样的方式管理不同系统的密钥的优点。“这其中吸引人的地方就在于：如果您企业有这样一个机制，其适用于Office 365的工作负载，包括Exchange、SharePoint和OneDrive业务，那么，同样的机制也将适用于业务线应用程序，其将被用于虚拟机、将秘密填充到虚拟机、CRM、SQL Server、HD Insight，您将开始以非常相似的一种范式来管理您的微软工作负载，而其培训也是非常相似的。”他说，如果您企业因为担心失去您的密钥的危险而正在考虑BYOK是至关重要的。 “您正在寻找能够帮助您实现环绕式处理技术的东西，然后培训您的员工去这么做，因为您不想失去您的密钥，然后再失去了您的数据。”Plastina说。当您使用HSM支持的键时，就像在Azure密钥库的云HSM或BYOK一样，密钥从您的HSM直接上传，而云服务从来也看不到密钥。这意味着他们无法把您的密钥交给一个攻击者或一个政府的调查机构。但这同时也意味着他们无法将密钥交还给您。 “如果您失去了您的密钥，所有被该密钥加密的数据便永远消失一去不复返了。”Plastina说。“当密钥是从他们的基础设施转移到我们的HSM时，是以我们看不见方式完成的，因此如果某位客户回来告诉我们说，他们的办公建筑焚毁了，HSM也没有了，那么，这就意味着所有的密钥也都丢失了，一切都结束了。俗话说，能力越大责任越大。人们如果想要参与进来，就需要执行相应的任务。” 服务托管的密钥可以向您的保证，其每位租户和每个订购的密钥都是管理职责和审计职责分离的，而没有管理密钥的头疼问题。“但是，借助BYOK，我们要求客户以重要的方式参与进来。” Plastina说。“这意味着设置密钥库并管理库;在某些情况下，需要HSM支持的密钥，以便他们能够在企业内部采购一款HSM，他们必须运行他们自己法定人数的管理员的智能卡和PIN码，并且必须在正确的地方保存智能卡。这肯定增加了他们的负担。” 如果您企业正在考虑采用携带自己的密钥的政策是否适合您企业的业务的话——这也意味着确保您自己的密钥安全，您需要考虑的第一个问题便是您企业是否准备好成为一家银行。因为您企业将不得不采用同样的严格要求来运行您的关键基础设施，甚至包括考虑您企业办公人员的旅行计划。如果您企业有三名授权的人员能够使用智能卡访问您企业的密钥，您肯定不会想让他们三位都同时出现。 保护密钥的负担意味着尽管一些微软的客户，特别是在汽车制造行业的用户选择了采用BYOK政策，“有人说我们相信微软将做的是正确的事情，”Plastina说。“他们都以’我想要拥有控制权’作为他们的开场白，但当他们看到需要承担的相应责任，并了解了微软承担了相当多的责任时，他们会说’您为什么不做’。他们不想成为一个链条上较弱的一环。” 甚至一些纽约的金融机构，最初也曾想采用BYOK来帮助他们管理企业内部的HSM，而当他们考虑到哪些可能出问题的领域时，他们开始坚决反对了，Rich表示说。“一款HSM可能已经关闭，会漏出大量的用户基本信息。他们很快想到，这可能是一个潜在的巨大的拒绝服务攻击，由公司内部的恶意攻击者执行。这些都是我们最先进的高度敏感的顾客，这不仅是一个巨大的责任，同时也潜在的具有破坏的威胁，无论是意外的或是恶意的。” 一些企业认为他们需要BYOK以遵守法律要求的密钥在他们的监督下的规定。在不同的司法管辖区有一系列实际意义的解释;“我们相信我们满足了这些法律的精神和目的。”Plastina表示说。一项类似于密钥库的服务可以使得在特定的地区保管密钥更容易，特别是规对于那些规模较小的、在他们所开展业务的所有地区没有相应物理基础设施的企业。 然而，仍有一些企业想拥有携带自己的密钥的选择——或者甚至将密钥托管在一款他们运营的HSM中。在许多方面，托管自己的密钥违背了许多公司采用云服务的初衷，因为云服务的速度，简单性和节省成本的特点，使得企业不再运行自己的基础设施以提供这些服务。如果您企业想保持可接受的性能和服务水平，您将需要大量的基础设施。“那些客户将需要运行高可用性容错的数据中心分布式服务到问题密钥。”Plastina警告说。如果不是今天微软所提供的服务，那么这些行业的企业要做到像银行一样是相当重要的，因为这些银行企业已经有了流程和安全的密钥方面的专业知识，以及审查员工方面的经验 BYOK和Office 365 企业用户不必携带和管理自己的密钥，以便获得更多的控制和透明度，微软Office 365团队的Paul Rich表示说。BYOK并不是解决企业用户失去对加密的控制权与通过在将数据迁移到云服务之前对其进行加密而失去云服务的大多数好处之间紧张关系的唯一方式。 “如果您在将相关的数据迁移到云服务之前对数据进行了加密，那么这些数据就不能被推理，而简单的表格，以及诸如垃圾邮件和病毒检测之类的任务也是不可能完成的，而更高级别的功能，如符合法律监管和深入的文档发现等等功能都将需要获得上传这些内容的人员的授权。企业CIO们明白，当他们来到云服务时，他们希望具备这些功能。他们所问的问题是“我们怎样才能让您能够通过利用机器做到这一点，同时又不让您的人员看到我们的数据呢?” 另一种选择是采用新的Office Lockbox。“这一服务理念是：提供云服务的人没有权限访问您的内容。您可以确保微软不会有人访问您所存储的内容。如果有我们需要访问的一个支持的理由，我们会请求获得访问许可，并直到我们得到该许可，人为运行的服务无法访问这些内容。”客户将获得透明度和能见度，Rich说;他们可以看到有哪些访问请求，并能够控制那些业务访问请求可以被批准，并获得相关的活动日志，了解当访问发生时，哪些内容被访问了。 而如果您想知道有哪些因素可以防止微软随意宣称他们并没有访问这些内容，或者监督管理员是否执行了远远超出了日志显示的操作的话，Rich列举了微软所负责运行的政府安全计划，在该计划中，微软负责提供对于微软源代码的访问控制，而这些代码最近刚刚被北约组织进行了更新。“我们与我们的客户达成协议，我们托管负责Lockbox的代码，并使其成为一个程序的一部分，允许第三方代码审查，以显示其没有侧门或后门。” 提供Lockbox意味着重写Office服务，以便能够删除来自企业内部部署的服务器软件的默认设置，因为管理员总是对于这些数据有访问权限。这在Exchange中已经实现了，而Lockbox中的选择现也已经有了;其将在2016年第一季度成为SharePoint的一项功能选项。 Office 365也将从依靠BitLocker转为对工作负载运行在其之上的服务器的加密，当工作负载运行时不会提供保护，而是转为对应用程序层进行加密。这一功能已经在SharePoint中完成，而对于在Exchange实现这一功能也已经于2015年底准备就绪了，企业版Skype的业务则被排在此之后。“这将把数据管理员与服务管理员独立开来。”他声称。其也将是BYOK的。”我们将在应用程序层中使用密钥包装，以通过用户所拥有的Azure密钥库保护邮箱的内容。” “当服务完全释放时，我们的计划是为客户提供少量的密钥，也许10或20个，方便用户用来与您的客户通过Exchange、SharePoint和企业版Skype进行交流。大多数客户表示说他们不需要太多的密钥，例如在美国和欧洲企业一般位三个密钥，而在亚太地区，他们会将密钥存储在密钥库。 这些密钥将需要保护，但不会使得Office 365的运行更复杂，他预测说。“您企业只需要做最少量的管理工作，偶尔调整一下密钥。”Rich表示说。“您使用这些密钥的方法是作为整个服务的策略。在正常操作中，我们没有权限访问您的内容;如果一个人需要访问，那么Office Lockbox便会记录，这样用户就能够知道谁在何时进行了访问。而一旦您离开办公大楼时，在密钥库中的密钥会把所有的灯关掉。” 保护您的密钥 根据去年的一项调查显示，只有很少的企业加强了对于他们已经负责的密钥的安全保护，BYOK和HYOK将超出了许多企业的范围。据Ponemon Institute的调查发现，大约有一半的企业对于其自己的SSH密钥和许多非旋转操作器(Rotate Key)没有集中控制，这使得它们更容易受到攻击。失去云加密密钥会更麻烦，因为您可能会因此而永远失去数据。 记住，BYOK并不是您企业所需要承担的唯一与密钥管理相关的安全责任。Windows 10包括了新设备的保护选项以限制PC机只能运行那些要么来自于Windows商店或已经由ISV或由企业自己签署的使用微软认证密钥链的应用程序。ISV和微软可以签署任何企业能运行的应用程序;但这些企业组织已经经历了保护高价值的密钥的过程。 签名密钥的企业得到的是更多的限制，生产的签名应用程序只能运行在自己的领域。但这仍然意味着违背了您的签名密钥的攻击者可以产生恶意软件，以攻击您的最安全的设备。 如果您正在使用设备保护配置代码以完整您的电脑，微软的Chris Hallum指出，“确保这些访问的人员是值得信赖的人进行的是非常重要的，您企业可以使用双因素身份验证，以确保只有有限数量的、您信任的资深人员在您的企业组织才有访问权限。” 在2007年，黑客偷了诺基亚用于其塞班操作系统应用程序的数字签名的密钥，并勒索该公司交出数百万欧元。 如果您企业没有准备好处理从突发火灾事故到黑客勒索的这一系列或将潜在的对您企业的信息基础设施和公司的数据造成拒绝服务攻击的状况的话，您企业可能不会准备采用携带自己的密钥的策略。最近，在Visual Studio 2015的创建的GitHub的插件bug，意味着开发者在他们的代码中嵌入AWS凭据上传到一个私人库，却发现，黑客们利用这些密钥运行了价值数千美元的AWS实例。 本文转自d1net（转载）

CMS   　　CMS，英文全称是：Content Management System 中文名称是：网站内容管理系统。 　　CMS其实就是内容管理系统，可以理解为：CMS帮你把一个网站的程序部分的事全做完了 你要做的只是一个网站里面美工的部份。 　　CMS,大概2004以前，如果想进行网站内容管理,基本上都是靠手工维护,但千变万化的信息流，但没有好的程序支持，还继续靠手工完成是不可能的事，如果有一个好的系统来支撑你的网站，那将节省大量的人力物力，开发者就可能给客户一个软件包，可以用它定期人工修改网站。只要你配置安装好，你的编辑，在线记者，更新员只要定期更新数据，剩下的事就交给CMS去处理。 　　免费的CMS管理系统：官方CMS网站：www.php-cms.cn --------------------------------------------------------------------- 　　根据不同的需求，CMS有几种不同的分类方法。比如，根据应用层面的不同，可以被划分为： 　　○ 重视后台管理的CMS 　　○ 重视风格设计的CMS 　　○ 重视前台发布的CMS 等等。就目前已经存在的各种CMS来说，最终界面上都是大同小异，但是在编程风格与管理方式上来讲却是相差万别。 　　就CMS本身被设计出来的出发点来说，应该是方便一些对于各种网络编程语言并不是很熟悉的用户用一种比较简单的方式来管理自己的网站。这虽然是本身的出发点，但由于各个CMS系统的原创者们自己本身的背景与对“简单”这两个字的理解程度的不同，就造成了现在没有统一的标准群雄纷争的局面。 　　简而言之CMS就是可以让你不需要学习复杂的建站技术，不需要学习太多复杂的HTML语言，你就能够利用CMS构建出一个风格统一功能强大的专业网站。     　　CMS具有许多基于模板的优秀设计，可以加快网站开发的速度和减少开发的成本。 　　CMS的功能并不只限于文本处理，它也可以处理图片、Flash动画、声像流、图像甚至电子邮件档案。 　　其实，CMS是一个很广泛的称呼，从一般的博客程序，新闻发布程序，到综合性的网站管理程序都可以被称为内容管理系统。 　　CMS还分各个平台脚本种类的。 如 php asp 　　内容管理系统是企业信息化建设和电子政务的新宠，也是一个相对较新的市场，对于内容管理，业界还没有一个统一的定义，不同的机构有不同的理解：   　　Gartner Group 认为内容管理从内涵上应该包括企业内部内容管理、Web内容管理、电子商务交易内容管理和企业外部网(Extranet)信息共享内容管理（如CRM和 SCM等），Web内容管理是当前的重点，e-business和XML是推动内容管理发展的源动力。   　　Merrill Lynch的分析师认为内容管理侧重于企业员工、企业用户、合作伙伴和供应商方便获得非结构化信息的处理过程。内容管理的目的是把非结构化信息出版到intranets, extranets和ITE(Internet Trading Exchanges), 从而使用户可以检索、使用、分析和共享。商业智能系统 (BI)侧重于结构化数据的价值提取，而内容管理则侧重于企业内部和外部非结构化资源的战略价值提取。   　　Giga Group 认为作为电子商务引擎，内容管理解决方案必须和电子商务服务器紧密集成，从而形成内容生产(Production)、传递(Delivery)以及电子商务端到端系统。   　　我们认为内容管理系统是一种位于WEB前端（Web 服务器）和后端办公系统或流程（内容创作、编辑）之间的软件系统。内容管理解决方案重点解决各种非结构化或半结构化的数字资源的采集、管理、利用、传递和增值，并能有机集成到结构化数据的商业智能环境中，如OA,CRM等。内容的创作人员、编辑人员、发布人员使用内容管理系统来提交、修改、审批、发布内容。这里指的"内容"可能包括文件、表格、图片、数据库中的数据甚至视频等一切你想要发布到 Internet、Intranet以及Extranet网站的信息。     那么，CMS是如何应运而生的呢？   　　随着网络应用的丰富和发展，很多网站往往不能迅速跟进大量信息衍生及业务模式变革的脚步，常常需要花费许多时间、人力和物力来处理信息更新和维护工作；遇到网站扩充的时候，整合内外网及分支网站的工作就变得更加复杂，甚至还需重新建设网站；如此下去，用户始终在一个高成本、低效率的循环中升级、整合…… 　　于是，我们听到许多用户这样的反馈： 　　页面制作无序，网站风格不统一，大量信息堆积，发布显得异常沉重； 　　内容繁杂，手工管理效率低下，手工链接视音频信息经常无法实现； 　　应用难度较高，许多工作需要技术人员配合才能完成，角色分工不明确； 　　改版工作量大，系统扩展能力差，集成其它应用时更是降低了灵活性；   　　对于网站建设和信息发布人员来说，他们最关注的系统的易用性和的功能的完善性，因此，这对网站建设和信息发布工具提出了一个很高的要求。 　　首先，角色定位明确，以充分保证工作人员的工作效率；其次，功能完整，满足各门道"把关人"应用所需，使信息发布准确无误。比如，为编辑、美工、主编及运维人员设置权限和实时管理功能。 　　此外，保障网站架构的安全性也是用户关注的焦点。能有效管理网站访问者的登陆权限，使内网数据库不受攻击，从而时刻保证网站的安全稳定，免于用户的后顾之忧。 　　根据以上需求，一套专业的内容管理系统CMS应运而生，来有效解决用户网站建设与信息发布中常见的问题和需求。对网站内容管理是该软件的最大优势，它流程完善、功能丰富，可把稿件分门别类并授权给合法用户编辑管理，而不需要用户去理会那些难懂的SQL语法。     CMS是如何发展的？ 　　内容管理从2000年开始成为一个重要的应用领域，这时.COM和B2B, B2C等经历了资本和市场的考验及洗礼，人们重新回到信息技术应用的基本面－如何提高竞争能力，而内容管理恰恰能够通过对企业各种类型的数字资产的产生、管理、增值和再利用，改善组织的运行效率和企业的竞争能力，企事业单位也开始认识到内容管理的重要性。 　　从企事业单位信息化的观点来看，以下因素导致对内容管理软件的巨大需求：   　　(1) 知识是企业的财富。在Internet交互过程中，只有十分之一涉及销售，其他十分之九都和信息交互有关，员工的知识获取越来越依赖于互联网，特别是在电子商务的个性化环境中，客户为了做出购买决定，需要智能化地获取信息，不仅仅是商品的数量和价格，更重要的可能是产品的手册、安全保证、技术指标、售后服务、图片文件等等。   　　(2) 信息的及时性和准确性。无论在企业内网还是外网，信息的更新越来越快，企事业单位的信息生产量越来越多，且呈现成倍增长的趋势，企事业单位更需要的是一个功能强大、可扩展的、灵活的内容管理技术来满足不断的信息更新、维护，这时如何保证信息的准确性和真实性将越来越显得重要。   　　(3) 企业内外网统一的需求增长。随着企事业单位信息化的建设，内联网和外联网之间的信息交互越来越多,优秀的内容管理系统对企业内部来说，能够很好地做到信息的收集和重复利用以及信息的增值利用, 对于外联网来说，更重要的是真正交互式和协作性的内容。   　　国外从事内容管理软件研发的主要厂商包括Vignette,Interwoven, BroadVision, Openmarket，ATG， Allaire, Documentum, Hummingbird等，这些公司CM产品和解决方案专业性很强，大多基于J2EE等平台，功能丰富，主要面向企业级用户，是CM市场的主要厂商。还有一些更窄的专业厂商提供内容管理某个阶段需要的功能，如Verity 提供知识检索，Micromedia 提供内容创作平台，Akamai和Inkitomi 提供内容分发管理技术等。与此相反，Microsoft, IBM, Oracle等公司提供通用平台性CM解决方案。但是目前CM市场仍有很多不完善的地方，包括： 　　在这个全新的市场中很难找到一个CMS满足用户的所有需求。 　　有些CMS只是单纯的信息发布工具而以，称不上内容的收集和再利用更谈不上知识管理的概念，最多只是一组网站建设工具软件而已。 　　所有产品的可视链接都非常差，只有极少数厂商能够提供可视软件，这些软件都不是交互式的，不能用作管理工具。     CMS都有可能包括些什么？ 　　隐藏在内容管理系统(CMS)之后的基本思想是分离内容的管理和设计。页面设计存储在模板里，而内容存储在数据库或独立的文件中。 当一个用户请求页面时，各部分联合生成一个标准的 HTML 页面。 一个内容管理系统通常有如下要素： 　　文档模板 　　脚本语言或标记语言 　　与数据库集成 　　内容的包含物由内嵌入页面的特殊标记控制。这些标记对于一个内容管理系统通常是唯一的。 这些系统通常有对较复杂的操作的语言支持，如 Python, Perl, 或 Java 等。 　　内容管理系统对站点管理和创造编辑都有好处。这其中最大的好处是能够使用模板和通用的设计元素以确保整个网站的协调。 作者只需在他们的文档中采用少量的模板代码，然后即可把精力集中在设计之上的内容了。要改变网站的外观， 管理员只需修改模板而不是一个个单独的页面。 　　内容管理系统也简化了网站的内容供给和内容管理的责任委托。很多内容管理系统允许对网站的不同层面人员赋予不同等级的访问权限， 这使得他们不必研究操作系统级的权限设置，只需用浏览器接口即可完成。 其他的特性如：搜索引擎、日历、Web 邮件等也会内置于内容管理系统 CMS 内，或允许以第三方插件的形式集成进来。     如何开发CMS ？ 　　内容管理系统是一个很泛的概念：从商业门户网站的新闻系统到个人的Weblog都可以称作发布系统。   　　框架型：本身不包含任何应用实现，只是提供了底层框架，具体应用需要一定的二次开发，比如Cocoon，Vignette； 　　应用型：本身是一个面向具体类型的应用实现，已经包含了新闻/评论管理，投票，论坛，WIKI等一些子系统。比如：postNuke xoops等；   　　但无论如何，在发布系统选型之前，首先了解自己的实际需求是最重要的：想根据现成系统将自己的需求硬往上照搬是非常不可取的。访问量，权限控制和各种功能需求。每个模块和功能自己都比较清晰一点以后，再去网上找找类似的实现：你会发现其实每个环节到目前上都有比较成熟的实现了，而且还在不断完善和发展中，如果没有：你的需求太特殊，或者可以尝试分解成更小的系统组合实现。     　　内容管理系统被分离成以下几个层面：各个层面优先考虑的需求不同   　　1，后台业务子系统管理（管理优先：内容管理）：新闻录入系统，BBS论坛子系统，全文检索子系统等，针对不同系统的方便管理者的内容录入：所见即所得的编辑管理界面等，清晰的业务逻辑：各种子系统的权限控制机制等； 　　2，Portal系统（表现优先：模板管理）：大部分最终的输出页面：网站首页，子频道/专题页，新闻详情页一般就是各种后台子系统模块的各种组合，这种发布组合逻辑是非常丰富的，Portal系统就是负责以上这些后台子系统的组合表现管理； 　　3，前台发布（效率优先：发布管理）：面向最终用户的缓存发布，和搜索引擎spider的URL设计等…… 内容管理和表现的分离：很多成套的CMS系统没有把后台各种子系统和Portal分离开设计，以至于在Portal层的模板表现管理和新闻子系统的内容管理逻辑混合在一起，甚至和BBS等子系统的管理都耦合的非常高，整个系统会显得非常庞杂。而且这样的系统各个子系统捆绑的比较死，如果后台的模块很难改变。但是如果把后台各种子系统内容管理逻辑和前台的表现/发布分离后，Portal和后台各个子系统之间只是数据传递的关系：Portal只决定后台各个子系统数据的取舍和表现，而后台的各个子系统也都非常容易插拔。   　　内容管理和数据分发的分离：需要要Portal系统设计的时候注意可缓存性（Cache Friendly）性设计：CMS后台管理和发布机制，本身不要过多考虑"效率"问题，只要最终页面输出设计的比较Cacheable，效率问题可通过更前端专门的缓存服务器解决。 　　此外，就是除了面向最终浏览器用户外，还要注意面向搜索引擎友好(Search engine Friendly)的URL设计：通过 URL REWRITE转向或基于PATH_INFO的参数解析使得动态网页在链接（URI）形式上更像静态的目录结构，方便网站内容被搜索引擎收录；     都有哪些CMS提供商 ？ 　　Vignette. 奥斯汀, TX Vignette公司，网站内容管理系统的领导者，今天宣布在中层楼资金上它取得了1亿4千万美元，成为奥斯汀基础软件公司中最大的私人资产投资，同时也使Vignette成为在奥斯汀发展最快的互联网软件公司。 Vignette 公司，作为全世界网站内容应用系统的领导者，为公司们提出了解决方案——在互联网上建立非常成功的商业。 Vignette的王牌产品是StoryServer 3，它能使公司以应用软件（如在线发布、知识管理和复杂电子商务系统）为基础建立、管理和发布服务，最终加速和提高客户的忠实度和持续力。 超过75个一流公司，包括Ziff- Davis' ZDNet, First Chicago NBD, Bay Networks 和 CNET ，使用StoryServer 3 ，每天提供2500万个网页浏览。 StoryServer3 获得了5个行业奖励，包括UPSIDE杂志的"网络基础组织类最活跃的私人公司" 。 它的 V/5 系列是一套应用软件包，设计用来为门户、B2C 和 B2B 市场需求提供内容管理。 V/5系列具有高度的可定制化能力和广泛的功能，它包括内容和模板的开发、个性化定制和发布。但是，它的多数功能还需要开发。   　　Documentum. Documentum 是文档管理解决方案的长期供应商。 带着它的4i 网站内容管理（WCM）版本，公司有力地进入了CM舞台，它提供了一个解决方案来支持具有在线而动态的内容的电子商务应用软件。对大中型组织来说，它也是一个健全的可扩展的网站内容管理解决方案。 　　Eprise. Eprise的 Participant Server 2.6.6是该公司内容管理的产品，它为大型商务和.com提供商业应用软件，包括互联网、企业内部网和公共网站。该产品能促进内容添加、修改和全球发布。Participant Server 的主要组件包括内容中心、操作中心、共享中心和内容分配套件。 产品为投稿和创造提供基于网络的界面，同时内容分配组件处理适于交易的内容分配。 A single Web based administrative interface is a plus because administration can be distributed across the organization. 单一的基于网络的管理界面是附加的，因为管理在组织范围内可以是分布式的。 　　Interwoven. Interwoven的 TeamSite 4.5是横向聚焦的网站内容管理解决方案，它向财富500强和全球2000个上市公司提供企业范围的网站内容管理。TeamSite 的管理和组成能力通过桌面和基于Java的接口提供，这种桌面和接口作为操作系统的一部分出现。用户可以通过Windows Explorer把内容拖放到存储库中。 　　Xpedio. Xpedio CMS 4.0是全球 2000 B2B 和 B2E 公司所用的解决方案包，它为没有技术的用户提供了容易使用的网站建设能力。 该产品在企业内部互联网、外部互联网和电子商务网站上促进了内容的快速发展和管理。在管理和发布内容方面，它是强大的解决方案，它提供具有分布式管理能力的创作工具、安全、发布的灵活性和完全基于浏览器的界面。 　　Ncompass. NCompass Labs于2001年4月通过微软成立，现在它是微软的子公司。 Resolution 3.1是Ncompass的浏览器，以网站内容管理解决方案为基础，在2001年底，它做为微软的产品（称为微软内容管理服务器）再次发布。 　　Open Market. Open Market 的Content Server 3.1是 J2EE兼容的内容管理解决方案，它嫦虺霭妗⒚教搴徒鹑诜?袷谐?pen Market 把内容服务器定位为推动以内容为中心的电子商务应用软件的产品，它处理访问者、客户和合作者之间的交互。该产品有用于管理和组织的网络界面，包括了一个个性化的引擎和用于发布的应用软件服务器。 　　BroadVision. BroadVision 把应用方法用于内容管理，主要目标是B2B, B2E 和 B2C 市场。BroadVision以应用软件程序包的形式出售产品，如出售给附带商业、合作商业、市场和雇员自我服务。内容管理解决方案也独立地出售。 　　FileNET. FileNET 是文档管理市场的传统领导者，现在它集中精力于生产电子商务应用软件的Panagon生产线。它的网站内容管理套件包括Panagon 内容服务（PCS）、Panagon 网络发布者（PWP）、Panagon 网络服务（PWS）和Panagon 电子流程。FileNET套件主要面向于金融、保险、政府、电信、公共事业和制造业。FileNET把它的网站内容管理套件定位在内容管理的全部解决方案，它贯穿内容的生命周期，从创造到审批、发布和分配。然而，在它目前的版本中，产品在核心网站内容管理的功能性上需要重大发展，如个性化和动态内容的表达。 　　Megellan. 2000 年7月，Gauss Interprise 和美国软件开发者Magellan 合并，主要销售它的内容管理系列 Versatile Internet Platform (VIP)。VIP定位于企业管理内容、网站内容和门户的平台。对于集中的环境，产品系列有适应需求的基本功能，包括基于网络的管理，单一和大批的输入、第三方厂商提供的基本库服务、以及用于分布式内容创造的模板设计工具。 　　InStranet. InStranet 成立于1999年，总部设在纽约，并且在巴黎设有欧洲总部。 公司的王牌产品是InStranet 2000 1.5，它是一个浏览器和基于Java的网站内容管理解决方案。产品聚焦于，在B2B和雇员工作环境下，向企业内部互联网和外部互联网发布业务文件和内容。InStranet 2000 1.5在 J2EE兼容的应用服务器上运行，已在BEA WebLogic, IBM WebSphere 和 iPlanet 应用服务器上经过检验。 　　Mediasurface. Mediasurface 的总部设在伦敦，它的美国办事处在纽约和弗朗西丝科。公司为组织提供管理内容软件，用于企业内部互联网和外部互联网。公司的核心产品是 Mediasurface 3.5，它瞄准垂直市场，包括金融服务、政府、教育、卫生保健、IT服务、媒体、出版和广播、零售和消费服务。 　　Six Open Systems. Six Offene Systeme GmbH 在美国称为Six Open Systems (Six) ，于1991年在德国成立。Six在德国有重要的消费群，它以产品Six CMS 4.0打入美国市场。 该产品是由内到外的、以浏览器为基础的解决方案，它用来帮助媒体出版商简化和管理内容设计及网页和门户、互联网、企业内部互联网等的设计。 　　Starbase. Starbase 销售合作产品，该产品为电子商务应用软件创造、管理代码和内容。2001年2月, Starbase收购了worldweb.net 和它的产品 Expressroom I/O 、以及基于Java 和 XML的网站内容管理解决方案。Starbase正把Expressroom I/O添加到它的代码和内容管理解决方案的协作套件中。 　　国内用的比较多的有Active Context、turbocms、cms4i，不过这些都是纯商业性系统，价格很高，一般个人建站，建议选取一些国外比较有名的开源系统，如Mambo、Drupal、Tikiwiki、PhpNuke、 PostNuke、Xoops、Tikipro、不过这些全是基于php + mysql的，众所周知，php和mysql是免费的。   ^__^=============================================================