一  挑战 设计从来就是个挑战. 当我们第一次接触数据库,学习数据库基础理论时,都需要学习范式,老师也一再强调范式是设计的基础.范式是这门课程中的重要部分,在期末考试中也一定是个重要考点.如果我们当年大学挂科了,说不定就是范式这道题没有做好.毕业后,当我们面试时,往往也有关于表设计方面拷问. 很多时候,我们错误地认为,花费大量时间用在设计上,问题根源在于关系数据库(RDBMS),在于二维表及其之间的联系组成的一个数据组织.而真实的环境中,我们正在大量使用noSQL或者NewSQL,按照目前的趋势…

原文链接:http://www.mongoing.com/mongodb-advanced-pattern-design 12月12日上午,TJ在开源中国的年终盛典会上分享了文档模型设计的进阶技巧,就让我们来回顾一下吧: —————————————————————————————————————————————————————————- 从很久以前,我就开始接触开源产品:从最开始的使用.受益者到后来的贡献者,到现在的热情推广者.现在,我是MongoDB的技术顾问.我的职责是为MongoDB的客户…

MongoDb 相比于传统的 SQL 关系型数据库,最大的不同在于它们的模式设计( Schema Design )上的差别,正是由于这一层次的差别衍生出其它各方面的不同. 我们可以简单的认为关系型数据库由数据库.表(table).记录(record)三个层次概念组成,而在构建一个关系型数据库的时候,工作重点和难点都在数据库表的划分与组织上.一般而言,为了平衡提高存取效率与减少数据冗余之间的矛盾,设计的数据库表都会尽量满足所谓的第三范式.相对的,可以认为MongoDb由数据库.集合(collect…

持续关注MongoDB博客(https://www.mongodb.com/blog)的同学一定会留意到,技术大牛Daniel Coupal 和 Ken W. Alger ,从 今年 2月17 号开始,在博客上持续发表了 如何在MongoDB中设计数据库模式的方法.截止到今日(4月20号),12种模式设计的方法已全部与读者见面.本人认为,此系列文章,总结的非常全面,很多地方有首创性,涵盖的场景也很多,并且有理论总结,也有案例分析.文中分享的很多知识使人"如听仙乐耳暂明",开卷受益,常读…

这是我写的<php模式设计>的第五篇.前面的四篇在不断学习不断加深认识,到了今天再看观察者模式,觉得非常容易理解.这也许就是我们积少成多的结果吧.希望还是能够不断进步. 开篇还是从名字说起,“观察者模式”的观察者三个字信息量很大.玩过很多网络游戏的童鞋们应该知道,即便是斗地主,除了玩家,还有一个角色叫“观察者".在我们今天他谈论的模式设计中,观察者也是如此.首先,要有一个“主题”.只有有了一个主题,观察者才能搬着小板凳儿聚在一堆.其次,观察者还必须要有自己的操作.否则你聚在一堆儿没事…

在这个有没有对象都要高呼“面向对象”的年代,掌握面向对象会给我们带来意想不到的方便.学编程的小伙伴从开始能写几行代码实现简单功能到后来懂得将一些重复的操作组合起来形成一个“函数”,再到后来将“函数”和属性组合起来形成一个“类”.一步步走来,我们在考虑着机器运行代码效率的提高的同时也在考虑减轻程序员的工作量. 那么我们今天讲到的适配器模型更着重考虑的是什么呢?是程序员工作量. 什么时候会用到适配器模式? 其实最简单的例子是当我们引用一个第三方类库.这个类库随着版本的改变,它提供的API也可能会改变…

在前两篇单例模式和工厂模式后,终于迎来了最后一个基础的设计模式--注册树模式. 什么是注册树模式? 注册树模式当然也叫注册模式,注册器模式.之所以我在这里矫情一下它的名称,是因为我感觉注册树这个名称更容易让人理解.像前两篇一样,我们这篇依旧是从名字入手.注册树模式通过将对象实例注册到一棵全局的对象树上,需要的时候从对象树上采摘的模式设计方法.   这让我想起了小时候买糖葫芦,卖糖葫芦的将糖葫芦插在一个大的杆子上,人们买的时候就取下来.不同的是,注册树模式摘下来还会有,能摘很多次,糖葫芦摘一次就没…

承接上篇php模式设计之 单例模式,(虽然好像关系不大).今天讲述第二种基础的模式设计——工厂模式. 那么何为工厂模式? 从名字来看,似乎看不出什么端倪.工厂模式,和生产有关?还是和生产流程有关?难道还和工厂领导有关?和领导秘书有关?秘书...     好了不卖关子了,所谓工厂模式还真和生产有关.生产什么呢?生产出来的是一个实例对象.通过什么设备生产?通过一个工厂类生产.怎么生产呢?工厂类调用自身静态方法来生产对象实例. 工厂模式有一个关键的构造,根据一般原则命名为Factory的静态方法,然而…

模式设计是什么?初学者一开始会被这高大上的名称给唬住.而对于有丰富编程经验的老鸟来说,模式设计又是无处不在.很多接触的框架就是基于各种模式设计形成的. 简单说,在写代码的过程中一开始往往接触的是面向过程的,简单的基础的编程.这个时候我们往往追求的是代码能够实现某项功能就万事大吉.管他代码多么冗余,管他代码是否可重用,管他效率如何,能实现功能就好.但是,真正应用于实际的,更被大家采纳的是那些高效的,可重用的,便于团队开发的代码.基于这些因素,你不能像练手一样,随便命名函数名,随便放置脚本.模式设计…

门面模式 两个作用: 1.简化类的接口 2.消除类与使用它的客户代码之间的耦合 门面模式常常是开发人员最亲密的朋友.它几乎是所有javascript库的核心原则 门面模式的目的是为了让开发人员用更简单的方法调用一些相对复杂或组合的方法,主要就是简化开发的复杂性,提供一个相对容易的API去调用内部的方法供外界去使用,这样程序员开发会变得轻松些,编写一次组合代码后可以反复的去使用它,有助于节省时间和精力 注意: 不要滥用门面模式,所以使用你心仪的门面之前一定要三思而定,搞不好你就会小题大做 引入概念…