FlyAnyWhere的专栏

数据库的设计无非就是在数据的完整性、一致性和并发性之间玩平衡。在不同的业务场景下总是会或多或少的偏向其中两个方面。乍一看貌似这和数据库的架构设计密切相关，可是事实真是如此么？性能方面我们举一个耳熟能详的公认原则读写分离、分表分区为例来说，这些明显是由业务系统划分并主导的。只不过在具体的数据落盘上体现出来了而已，怎么能落到数据库架构上面呢？至于数据建模更是考验了一个系统的抽象组织方式，简单的说，如果

初识中间件是CORBA，听主席在上面吹牛，感觉除了神奇还是神奇，又是跨语言、又是跨操作系统、还能跨网络，效率还高，伸缩性还强，真是银弹啊。可是在用的过程中除了感觉难用，还是难用。后识中间件是现在的工作单位使用tuxedo来发布各式各样的服务来构建系统。可是中间件到底是啥，翻了一下维基百科，看了一下中间件的定义，真可谓是含糊不清，五花八门各种定义都有。其实就是按照其中最BT的定义来说，我早在使用CO

汗明见春申君，候闻三月，而后得见。谈卒，春中君大说之。汗明欲复谈，春申君曰：“仆已知先生，先生大蹊矣。”汗明慨焉曰：“明愿有问君而恐固。不审君之圣，孰与尧也？”春申君曰：“先生过矣，臣何足以当尧？”汗明曰：“然则君料臣孰与舜？”春申君曰：“先生即舜也。”汗明曰：“不然，臣请为君终言之。君之贤实不如尧，臣之能不及舜。夫以贤舜事圣尧，三年而后乃相知也。今君一时而知臣，是君圣于尧而臣贤于舜也。”春申君曰

从data module说开了去    Data model 的概念最早是从delphi中接触到的，算是老朋友了。可是一直对为什么delphi中会有这么一个组件弄不清楚，当然也没有追根揭底弄清楚，后来在使用EXTJS中，也有一个data model 的东西，还是没有追根揭底，问一句为什么要这么命名，原因很是简单，参见拙著《对数据库的一些偏见》里面自有答案。    不过今天有人问到了，刚好又没有

在经历了逻辑架构、物理架构、系统架构等抽象模式后，初次看到面向服务的架构时一时不知从何谈起，因为这确实是一个神一般存在的概念，“SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言”。难道当年DCOM、CORBA在制定初期不是这样定义组件模型的？更神奇的是这么一个

接着上次没有进行完毕的话题继续下去，csdn的贴图实在是非常不方便。就该用刚刚从手上滑过的两个小工程项目来讲述一下，不过实际项目开发过程中远没有理论上阐述的那么清晰，因为总是会夹杂不少其他的概念。 项目一 业务需求：  某工厂的员工，经常使用工作用手机或者pad通过链接到非指定ssid进行上网活动，厂方希望能够开发一套软件能够阻止此类事情的发生。          需求分析：