存档

作者存档

IntelliJ IDEA 使用总结

2010年3月6日 admin 4 条评论

一直来使用的都是Eclipse,不过现在的手上的那个项目用Eclipse开发和debug总是不爽,就有了换个IDE的想法。选择IntelliJ IDEA,也是因为之前也使用过一阵子IntelliJ IDEA。今天google了一些关于IntelliJ IDEA使用、配置方面的内容,并做个简单的记录。我使用的IntelliJ IDEA版本是8.x

性能优化

1.修改JVM参数

修改idea.exe.vmoptions配置文件调整以下内容:
-Xms256m
-Xmx384m
-XX:MaxPermSize=128m
-XX:NewRatio=4
-Xss128k
-Dsun.awt.keepWorkingSetOnMinimize=true
-server
-Xms256m设置初时的内存数,你需要设置一个合理的值, 增加该值可以提高Java程序的启动速度。如果你的内存够大,如2G,可以设置到400m。
-Xmx384m设置最大内存数,提高该值,可以减少内存Garage收集的频率,提高程序性能。
-Dsun.awt.keepWorkingSetOnMinimize=true可以让IDEA最小化到任务栏时依然保持以占有的内存,当你重新回到IDEA,能够被快速显示,而不是由灰白的界面逐渐显现整个界面,加快回复到原界面的速度。
-server控制内存garage方式,这样你无需在花一到两分钟等待内存garage的收集。

2.优化文件保存和工程加载

取消“Synchronize file on frame activation”和“Save files on framedeactivation”的选择
同时我们选择"Save files automatically", 并将其设置为30秒,这样IDEA依然可以自动保持文件,所以在每次切换时,你需要按下Ctrl+S保存文件

如何让IntelliJ IDEA动的时候不打开工程文件:Settings->General去掉Reopen last project on startup

3.用*标识编辑过的文件

Editor –> Editor Tabs
—————————————–
在IDEA中,你需要做以下设置, 这样被修改的文件会以*号标识出来,你可以及时保存相关的文件。
"Mark modifyied tabs with asterisk"

4.显示行号

如何显示行号:Settings->Editor->Appearance标签项,勾选Show line numbers

5.自定义键盘快捷方式

如果默认代码提示和补全快捷键跟输入法冲突,如何解决:Settings->Keymap

6.如何让光标不随意定位

Settings->Editor中去掉Allow placement of caret after end of line。

7.中文乱码问题

在包含中文文件名或者文件夹的时候会出现??的乱码,解决方法如下:

File菜单->Settings->Colors & Fonts->Editor Font=宋体, size=12, line spacing =1.0
File菜单->Settings->Appearance-> Font Name=Simsun,size=12

8.如何完美显示中文

Settings->Appearance中勾选Override default fonts by (not recommended),设置Name:NSimSun,Size:12

 

参考资料

Intellij idea性能优化
IntelliJ IDEA 目录技巧
IntelliJ IDEA 8性能优化
intellij idea 使用总结

分类: JAVA 标签:

代码中的Bad Smell坏味道

2010年3月6日 admin 没有评论

最近一段时间的工作都要维护一些老代码以及做一些Code Review。代码中的那些Bad Smell真的让人很抓狂,想起之前看过的Martin Fowler的《重构》,于是就整理了一些自己常能体会到的代码中的Bad Smell.

Bad Smell列举

1.重复代码

消除重复代码的基本方法是:如果是同一个类中的重复代码就把这个方法“抽取”出来;如果是两个兄弟类之间的重复代码需要把方法抽取出来,并提升到父类中;如果是两个不相关类间的代码重复,就

2.方法过大

应该更积极进取地分解函数。我们遵循这样一条原则:每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中, 并以其用途(而非实现手法)命名。我们可以对一组或甚至短短一行代码做这件事。哪怕替换后的函数调用动作比函数自身还长,只要函数名称能够解释其用途,我 们也该毫不犹豫地那么做。关键不在于函数长度,而在于函数[做什么]和[如何做]之间的语义距离。

3.类过大

类过大往往意味着想利用单一class做太多事情,其内往往就会出现太多instance变量。一旦如此,代码重复、God Object之类的问题也就是接踵而至了。

解决类过大的方法就是要思考类的定义和职责,将原本一个类中完成的功能分解到其他几个类中。

4.过长参数列

方法的参数要尽量的少,超过3个以上的参数就会直接影响方法的理解。这个可以根据参数间的关联性抽取出一个对象来。

6.多层的条件语句,循环语句嵌套.

If里面嵌套If,for里面继续循环for。这种情况可以适当的将嵌套的内容抽取出来。

7.变量名不具备说明性。

变量名应该具有足够的说明性。除了常用的i,j作为循环变量。通常一些全局变量和实例变量的变量名应该足够长,并具有足够的说明性,并保证不易跟其他变量混淆。

10.方法和类的职责要具有单一性,并且名称能够具备说明性。

 

参考资料

代码的坏味道,重构,模式
refactoring-从地狱中重生
God Object
Code Smell

对象健身操

分类: 软件设计 标签:

转载:Facebook的成功之道

2010年2月28日 admin 1 条评论

原文地址:http://news.csdn.net/a/20100222/217118.html

【总编观察】Facebook的成功之道

美国知名媒体《Fast Company》日前评出2010年度世界最具创新力公司榜,社会化网站的世界霸主Facebook成为世界最具创新力公司,而去年它还排在第15位。

2009年,成立才不到6年、CEO Mark Zuckerberg只有26岁、员工仅1200多人的Facebook,用户翻了一番,增加了2亿,将MySpace等竞争对手远远甩在身后,成功压制住了Twitter等新贵的挑战,巩固了自己社会化网络的霸主地位,而且表现出难得的稳健和成熟。业界普遍认为,Facebook是目前最有可能超越Google的互联网公司,成长为微软、Intel、Google那样的伟大公司也没有太多悬念。

那么,Facebook的成功之道是什么呢?

Facebook的可贵之处,是在经济大环境不佳的情况下,实现了快速成长,并在很好地控制了成本(目前公司仍然只有一个专职的人力资源职员)的同时,专注于锐意创新,不断改善产品,快速变化,而且敢于冒险。也在于在公司快速变大的同时保留了小型创业公司的基本特质,很好地兼顾了工程师文化和社会化(推荐阅读:Facebook的社会化基因)。

Zuckerberg在哈佛大学人工智能课程的老师、曾在微软任职的Andrew "Boz" Bosworth说,他加入Facebook后在公司里听到的最多的话,是进取、奋斗、激情和影响世界,人人都争着提出新想法,并说服别人,争取实现的机会,如果你没有想法,很容易被淘汰。与只是接规格说明然后提交代码的微软相比,这里的环境完全不同。

与Google相比,Facebook在创新力方面的优势也显而易见。Gmail创始人、现在Facebook开发下一代基础平台的传奇人物Paul Buchheit说,自己离开Google的时候产品发布周期已经非常长,如果现在提交代码,三个月之后它才会上线。而在Facebook,每周都会发布新产品,如果想进行测试,每天都可以让代码上线,让特定的真实用户组试用。这背后的理念是hacking文化,就是不断精益求精,而且不怕为此打破陈规。

Facebook大约每两个月都会举行著名的Hackathon活动,由公司创业者们早期的围炉夜话发展而来。参加Hackathon的人包括律师有时候也 包括Mark Zuckerberg,都会把自己的新点子、新项目提出来讨论,如果你能经过众人严苛的考察,能打动一些人跟你干,那就去干吧,公司提供后勤保障。

2010年,Zuckerberg关注的重点仍然是新想法、更好的产品和更多的用户,当然,还有正在进行中的整个网站基础平台的重构。对于用户数,Zuckerberg不愿设定具体目标,但他提到了自己一直崇拜的Google的用户数是8亿人。不过,他也自豪地表示,Facebook每个工程师所支持的用户数超过了100万,这比Google要多得多。

而Facebook的一位员工则不那么隐讳了,他说,我们总是有大龙要杀,今年这条大龙将是Google。对于Facebook来说,一切仿佛才刚刚开始。

刘江CSDN暨《程序员》总编

博客:http://blog.csdn.net/liujiangCE

新浪微博:http://t.sina.com.cn/turingbook,Twitter:@turingbook

 

最后总结一下中国公司在这个榜单中的成绩

华为,排名5

比亚迪,排名16

阿里巴巴,排名29

宏达电子, 排名31

华宜兄弟,排名42

软件开发沉思录阅读笔记二

2010年2月18日 admin 1 条评论

这是《软件开发沉思录》这本书阅读笔记的第二篇,第一篇是软件开发沉思录阅读笔记一是对第六章——对象健身操的阅读笔迹。

第七章——迭代经理是什么角色

什么是迭代经理?

ThoughtWorks的高级架构师Fred George把迭代经理描述成“面向内部的管理角色。迭代经理负责保证故事在团队中流动的顺畅,这牵涉到合理分配任务、在技能需要改变的时候建议更换团队成员。”

怎样成为好的迭代经理?

每天,迭代经理都必须倾听团队的需要并且作出回应。其主要职责就是培养一台润滑良好的“机器”,并依据要求的质量在项目范微内交付功能。

迭代经理应该在技术熟练度和业务知识之间达到一个平衡。敏捷领袖应该“同时对客户和技术都由深刻的理解,这样才能赢得开发团队的尊重。”良好的沟通技巧是必须的。迭代经理的职责之一就是维护开团队与客户,以及与管理阶层之间的关系。

同时,迭代经理必须推动、主张和保障团队成员的权利。

迭代经理不做什么?

与项目经理不同,迭代经理需要在工作第一线,与团队成员一起面对每日的工作活动。

迭代经理与项目

作为次要目标,我期望看到因为迭代经理的工作,团队成员在项目结束的时候变得更为优秀。团队内充满信任,持续提高技能——这是迭代经理的工作。

迭代经理要争取把团队拧成一根绳,让所有的成员能同舟共济。

第十章——领域标注

在过去十年里,众多软件开发者意识到:软件应用程序中最大的复杂度来自于软件要处理的实际问题领域。正因为如此,所谓“领域驱动设计”有两个前提:

  • 大部分软件项目关注的焦点是业务领域和领域逻辑;
  • 复杂的领域设计应该基于模型来进行。

换句话说,领域驱动设计将用业务领域术语表述的业务领域的面向对象模型置于软件系统的核心。数据通常保存在关系数据库里,但看待数据的主视角是领域对象,而不是数据库表和存储过程。核心业务逻辑集中保存在领域模型中,而不是散步在用户界面和应用程序的服务层里。

如果遵循领域驱动设计方法,得到的软件系统就会清晰地区分出领域模型和基础设施(及界面):前者通常较为稳定、生命周期较长;后者通常生命周期较短,并且与具体的技术(例如O/R映射或者WEB框架)相关。这里的挑战在于如何保持两者之间的分野,从而使两者能够各自保持可复用性:一方面,领域模型应该能够在不同的应用程序、不同的服务中使用,或是在技术升级以后继续使用;另一方面,基础设施应该能用于支撑各种领域模型。当然最终的目标是实现基础设施的行业标准化(无论是采用商用软件还是开源软件),从而使应用程序开发者能专注于问题领域。

分类: 敏捷, 软件设计, 阅读 标签: ,

Daniel-Journey Daily Dose-2010/2/18

2010年2月18日 admin 没有评论

敏捷

敏捷估计和规划的12条指导原则

  • 让整个小组参与。
  • 在不同层次上进行规划。
  • 使用不同度量单位,让对规模和持续时间的估计保持独立。
  • 用功能或者日期来体现不确定性。
  • 经常重规划。
  • 跟踪进度并沟通
  • 承认学习的重要性。
  • 规划具有适当规模的功能。
  • 确定功能优先级。
  • 把估计和计划建立在事实上
  • 保留一些松弛度。
  • 通过前瞻规划协调做个小组。

Bob大叔关于Scrum和敏捷的7条缺陷

  • 缺乏技术实践:Scrum是一个项目管理框架,在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括:TDD、持续集成、验收测试、结对编程、重构。”
  • 30天的冲刺周期太长:多数讲师现在建议冲刺周期1-2周,大多数团队采用的是2周。
  • Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题,而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
  • 对产品Backlog的指导太少:“经过多年实践,我们知道了backlogs有很多分层次的实体,包括史诗、主题、故事等等。我们学会了怎么对它们估计;学会了怎么把高层次的实体拆解成低层次:史诗->主题->故事->任务。”
  • Scrum暗中包含反管理:“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性…Scrum的描述并没有给与很好的平衡。”
  • 自动化测试:没有高质量的自动化测试,很难以短的迭代周期工作,很难知道故事是否真的做完了。
  • 多团队:Scrum和通用的敏捷方法很少谈及怎样扩展,虽然很多实践者有一些想法,但是还没有达成广泛的一致。

Agile Methodology Mashups

  • Pair Programming
  • Daily Scrum/Standing Meeting
  • Kanban/Burn Down Charts
  • Test First Development

敏捷开发中高质量 Java 代码开发实践

OOD & OOP

Composition versus Inheritance

  • Programming to an Interface, Not an Implementation

  • Creational Patterns Considered Obsolete

  • Inversion of Control Containers

  • Composition Realized
         [Inheritance] can cause problems when you’re trying to reuse a subclass.  Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate.  This dependency limits flexibility and ultimately reusability.

         Object composition is defined dynamically at run-time (at startup, config-time in most IoC containers –Chad) through objects acquiring references to other objects.  Composition requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others.  But there is a payoff.  Because objects are accessed solely through their interfaces, we don’t break encapsulation.  Any object can be replaced at run-time by another as long as it has the same type.  Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies (!!! Very important –Chad)

        Object composition has another effect on system design.  Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task.  Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters.  On the other hand, a design based on object composition will have more objects (if fewer classes), and the system’s behavior will depend on their interrelationships instead of being defined in one class (configured and managed by the IoC container –Chad).

其他

Tags,无序,分类和家族相似

看似普通的Tag其实有着丰富的哲学含义

分类: 阅读 标签: , ,

数据库的反范式化(Denormalization)设计

2010年2月15日 admin 1 条评论

转载:数据库范式1NF 2NF 3NF BCNF实例分解这篇博文中,介绍了数据库范式设计方面的内容。

范式化设计目标的主要目的就是“减少不必要的更新”。但事事都具有两面性,在对数据库进行范式话设计的时候也不可避免的带来了一些副作用。一个完全范式化设计的数据库经常会面临“查询缓慢”这个问题。数据库越范式化,就需要Join越多的表。例如,把用户地址用独立的一张表来存储,在需要显示用户地址的时候就需要去join用户地址表。

数据库的范式设计其中的一些优点可能并不这么值得称道:

范式化节省了存储空间,但存储空间却很便宜

范式化简化了更新,但读更普遍

反范式化设计

对不可改变数据的反模式设计。也就是说对不可改变的数据无需模式化设计。例如,用户信息中要记录该用户的国籍,由于国家信息(国家代码、简称都是不可改变的数据或者说改变的机率很小),所以无需在用户信息表中新增列来关联国家信息表,可以直接将相关的国家信息列作为用户信息表中的列。

将多张表合并成一张。下面举一个这样的例子,范式化的数据库设计如下。

user table用户基本信息表
user_id first_name last_name sex hometown relationship_status
12345 John Doe Male Atlanta, GA married
user_phone_numbers table用户电话信息表
user_id (foreign_key) phone_number phone_type
12345 425-555-1203 Home
12345 425-555-6161 Work
12345 206-555-0932 Cell
user_screen_names table用户IM信息表
user_id (foreign_key) screen_name im_service
12345 geeknproud@example.com AIM
12345 voip4life@example.org Skype

对这样的表设计进行反模式就可以将user_phone_numbers table,user_screen_names table都并入user table中。

user_table用户IM信息表
列名 说明
user_id
first_name
last_name
sex
hometown
relationship_status
phone_type_home
phone_type_work
phone_type_cell
im_service_aim

 

在提升数据库性能的时候我们可以考虑索引、物化视图、缓存等技术,但反范式设计的确是很重要的一种手段。看一下Flickr的这组数据吧。

total stored unique data : 935 GB
total stored duplicated data : ~3TB

参考资料

Why too much Database Normalization can be a Bad Thing

Normalization is for Sissies

Database War Stories #3: Flickr

Denormalization Patterns

分类: 数据库 标签:

转载:数据库范式1NF 2NF 3NF BCNF实例分解

2010年2月15日 admin 没有评论

本文转载至Everyday NetLog数据库范式1NF 2NF 3NF BCNF实例分解

设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。

关系数据库中的关系必须满足一定的要求,即满足不同的范式。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。下面我们举例介绍第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
在创建一个数据库的过程中,范化是将其转化为一些表的过程,这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据,从而导致创建多余的表。范化是在识别数据库中的数据元素、关系,以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。
下面是范化的一个例子
Customer Item purchased  Purchase price Thomas Shirt $40 Maria Tennis shoes  $35 Evelyn  Shirt $40Pajaro Trousers $25
如果上面这个表用于保存物品的价格,而你想要删除其中的一个顾客,这时你就必须同时删除一个价格。范化就是要解决这个问题,你可以将这个表化为两个表,一个用于存储每个顾客和他所买物品的信息,另一个用于存储每件产品和其价格的信息,这样对其中一个表做添加或删除操作就不会影响另一个表。
关系数据库的几种设计范式介绍
1 第一范式(1NF)
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。简而言之,第一范式就是无重复的列。
2 第二范式(2NF)
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。
3 第三范式(3NF)
满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。
数据库设计三大范式应用实例剖析
数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。
设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。
实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。
范式说明
第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。
例如,如下的数据库表是符合第一范式的:
字段1  字段2  字段3  字段4  
而这样的数据库表是不符合第一范式的:
字段1  字段2  字段3  字段4  
      字段3.1  字段3.2     
很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系:
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式,因为存在如下决定关系:
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF,这个选课关系表会存在如下问题:
(1) 数据冗余:
同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。
(2) 更新异常:
若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。
(3) 插入异常:
假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。
(4) 删除异常:
假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表:
学生:Student(学号, 姓名, 年龄);
课程:Course(课程名称, 学分);
选课关系:SelectCourse(学号, 课程名称, 成绩)。
这样的数据库表是符合第二范式的, 消除了数据冗余、更新异常、插入异常和删除异常。
另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。
第三范式(3NF):在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:
关键字段 → 非关键字段x → 非关键字段y
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系:
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。
把学生关系表分为如下两个表:
学生:(学号, 姓名, 年龄, 所在学院);
学院:(学院, 地点, 电话)。
这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。
鲍依斯-科得范式(BCNF):在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:
(1) 删除异常:
当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常:
当仓库没有存储任何物品时,无法给仓库分配管理员。
(3) 更新异常:
如果仓库换了管理员,则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表:
仓库管理:StorehouseManage(仓库ID, 管理员ID);
仓库:Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。
范式应用
我们来逐步搞定一个论坛的数据库,有如下信息:
(1) 用户:用户名,email,主页,电话,联系地址
(2) 帖子:发帖标题,发帖内容,回复标题,回复内容
第一次我们将数据库设计为仅仅存在表:
用户名  email  主页  电话  联系地址  发帖标题  发帖内容  回复标题  回复内容  
这个数据库表符合第一范式,但是没有任何一组候选关键字能决定数据库表的整行,唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段,即将表修改为:
用户名  email  主页  电话  联系地址  发帖ID  发帖标题  发帖内容  回复ID  回复标题  回复内容  
这样数据表中的关键字(用户名,发帖ID,回复ID)能决定整行:
(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)
但是,这样的设计不符合第二范式,因为存在如下决定关系:
(用户名) → (email,主页,电话,联系地址)
(发帖ID) → (发帖标题,发帖内容)
(回复ID) → (回复标题,回复内容)
即非关键字段部分函数依赖于候选关键字段,很明显,这个设计会导致大量的数据冗余和操作异常。
我们将数据库表分解为(带下划线的为关键字):
(1) 用户信息:用户名,email,主页,电话,联系地址
(2) 帖子信息:发帖ID,标题,内容
(3) 回复信息:回复ID,标题,内容
(4) 发贴:用户名,发帖ID
(5) 回复:发帖ID,回复ID
这样的设计是满足第1、2、3范式和BCNF范式要求的,但是这样的设计是不是最好的呢?
不一定。
观察可知,第4项"发帖"中的"用户名"和"发帖ID"之间是1:N的关系,因此我们可以把"发帖"合并到第2项的"帖子信息"中;第5项"回复"中的" 发帖ID"和"回复ID"之间也是1:N的关系,因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余,新的设计为:
(1) 用户信息:用户名,email,主页,电话,联系地址
(2) 帖子信息:用户名,发帖ID,标题,内容
(3) 回复信息:发帖ID,回复ID,标题,内容
数据库表1显然满足所有范式的要求;
数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖,即不满足第二范式的要求,但是这一设计并不会导致数据冗余和操作异常;
数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖,也不满足第二范式的要求,但是与数据库表2相似,这一设计也不会导致数据冗余和操作异常。
由此可以看出,并不一定要强行满足范式的要求,对于1:N关系,当1的一边合并到N的那边后,N的那边就不再满足第二范式了,但是这种设计反而比较好!
对于M:N的关系,不能将M一边或N一边合并到另一边去,这样会导致不符合范式要求,同时导致操作异常和数据冗余。
对于1:1的关系,我们可以将左边的1或者右边的1合并到另一边去,设计导致不符合范式要求,但是并不会导致操作异常和数据冗余。
结论
满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的,在数据库表中存在1:1或1:N关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。

分类: 数据库 标签:

Did you know? 3.0 中英对照版

2010年2月15日 admin 没有评论

分类: 互联网, 胡言乱语 标签:

Trees In SQL

2010年2月15日 admin 没有评论

    Tree关系或者说层次结构是开发过程中遇到的普遍的问题,如何把这种关系持久化到数据库中,并能支持高效的SQL查询,这方面有不少讨论和解决方案,这边文章是对这主题相关内容的总结,介绍的比较肤浅,有兴趣的同学可以阅读一下我在参考资料中列举的文章和书籍。

Adjacency List Model(邻接列表模式)

样例表结构和数据准备SQLimage
CREATE TABLE category(
category_id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(20) NOT NULL,
parent INT DEFAULT NULL);
INSERT INTO category
VALUES(1,'ELECTRONICS',NULL),(2,'TELEVISIONS',1),(3,'TUBE',2),
(4,'LCD',2),(5,'PLASMA',2),(6,'PORTABLE ELECTRONICS',1),
(7,'MP3 PLAYERS',6),(8,'FLASH',7),
(9,'CD PLAYERS',6),(10,'2 WAY RADIOS',6);
SELECT * FROM category ORDER BY category_id;

+-------------+----------------------+--------+
| category_id | name                 | parent |
+-------------+----------------------+--------+
|           1 | ELECTRONICS          |   NULL |
|           2 | TELEVISIONS          |      1 |
|           3 | TUBE                 |      2 |
|           4 | LCD                  |      2 |
|           5 | PLASMA               |      2 |
|           6 | PORTABLE ELECTRONICS |      1 |
|           7 | MP3 PLAYERS          |      6 |
|           8 | FLASH                |      7 |
|           9 | CD PLAYERS           |      6 |
|          10 | 2 WAY RADIOS         |      6 |
+-------------+----------------------+--------+

    在Adjacency List Model中,每一项都要保留一个指针指向它的父项,最顶层的用NULL或者其他的特殊值来表示。
下面我们来看看Adjacency List Model中主要其中应用场景下SQL的写法:
获取整棵树
SELECT t1.name AS lev1, t2.name as lev2, t3.name as lev3, t4.name as lev4
FROM category AS t1
LEFT JOIN category AS t2 ON t2.parent = t1.category_id
LEFT JOIN category AS t3 ON t3.parent = t2.category_id
LEFT JOIN category AS t4 ON t4.parent = t3.category_id
WHERE t1.name = 'ELECTRONICS';

+-------------+----------------------+--------------+-------+
| lev1        | lev2                 | lev3         | lev4  |
+-------------+----------------------+--------------+-------+
| ELECTRONICS | TELEVISIONS          | TUBE         | NULL  |
| ELECTRONICS | TELEVISIONS          | LCD          | NULL  |
| ELECTRONICS | TELEVISIONS          | PLASMA       | NULL  |
| ELECTRONICS | PORTABLE ELECTRONICS | MP3 PLAYERS  | FLASH |
| ELECTRONICS | PORTABLE ELECTRONICS | CD PLAYERS   | NULL  |
| ELECTRONICS | PORTABLE ELECTRONICS | 2 WAY RADIOS | NULL  |
+-------------+----------------------+--------------+-------+
6 rows in set (0.00 sec)
查找树中的全部叶子节点
SELECT t1.name FROM
category AS t1 LEFT JOIN category as t2
ON t1.category_id = t2.parent
WHERE t2.category_id IS NULL;

+--------------+
| name         |
+--------------+
| TUBE         |
| LCD          |
| PLASMA       |
| FLASH        |
| CD PLAYERS   |
| 2 WAY RADIOS |
+--------------+
获取单一路径
SELECT t1.name AS lev1, t2.name as lev2, t3.name as lev3, t4.name as lev4
FROM category AS t1
LEFT JOIN category AS t2 ON t2.parent = t1.category_id
LEFT JOIN category AS t3 ON t3.parent = t2.category_id
LEFT JOIN category AS t4 ON t4.parent = t3.category_id
WHERE t1.name = 'ELECTRONICS' AND t4.name = 'FLASH';

+-------------+----------------------+-------------+-------+
| lev1        | lev2                 | lev3        | lev4  |
+-------------+----------------------+-------------+-------+
| ELECTRONICS | PORTABLE ELECTRONICS | MP3 PLAYERS | FLASH |
+-------------+----------------------+-------------+-------+
1 row in set (0.01 sec)
Adjacency List Model的局限性
  • 普通的SQL很难处理Adjacency List Model,例如想要获取某个目录的全路径就必须知道目录所在的目录层级。
  • 另外,删除某个节点的时候也必须要小心,否则容易造成该节点的子节点成为孤儿节点。
  • 通过客户端代码或者存储过程可以解决其中的一些问题。通过过程语句,我们可以从顶层迭代从而获取整个树路径和单一路径;也可以在删除节点的时候,重置子节点的父节点值。

路径实体化(Materialized Path)模式

                  这种方式用的也很多,就是将节点的层次路径加以保存。

ENAME PATH
KING  1
JONES 1.1
SCOTT 1.1.1
ADAMS 1.1.1.1
FORD 1.1.2
SMITH 1.1.2.1
BLAKE 1.2
ALLEN 1.2.1
WARD 1.2.2
CLARK 1.3
MILLER 1.3.1

各种查询通过借助PATH值来实现,例如

获取某个节点的全部父节点

 

 

Nested Set Model(嵌套集合)模式

在嵌套集合模式父节点会包含它的子节点,这种层次关系通过节点的左、右值来体现的,如下图。

image

CREATE TABLE nested_category (
 category_id INT AUTO_INCREMENT PRIMARY KEY,
 name VARCHAR(20) NOT NULL,
 lft INT NOT NULL,
 rgt INT NOT NULL
);

INSERT INTO nested_category
VALUES(1,'ELECTRONICS',1,20),(2,'TELEVISIONS',2,9),(3,'TUBE',3,4),
(4,'LCD',5,6),(5,'PLASMA',7,8),(6,'PORTABLE ELECTRONICS',10,19),
(7,'MP3 PLAYERS',11,14),(8,'FLASH',12,13),
(9,'CD PLAYERS',15,16),(10,'2 WAY RADIOS',17,18);

SELECT * FROM nested_category ORDER BY category_id;

+-------------+----------------------+-----+-----+
| category_id | name                 | lft | rgt |
+-------------+----------------------+-----+-----+
|           1 | ELECTRONICS          |   1 |  20 |
|           2 | TELEVISIONS          |   2 |   9 |
|           3 | TUBE                 |   3 |   4 |
|           4 | LCD                  |   5 |   6 |
|           5 | PLASMA               |   7 |   8 |
|           6 | PORTABLE ELECTRONICS |  10 |  19 |
|           7 | MP3 PLAYERS          |  11 |  14 |
|           8 | FLASH                |  12 |  13 |
|           9 | CD PLAYERS           |  15 |  16 |
|          10 | 2 WAY RADIOS         |  17 |  18 |
+-------------+----------------------+-----+-----+

树状的显示如下图

image

左、右值的赋值逻辑是“When working with a tree, we work from left to right, one layer at a time, descending to each node’s children before assigning a right-hand number and moving on to the right. This approach is called the modified preorder tree traversal algorithm.”

在给某个节点右值进行赋值之前,先降低到该节点的子节点,

获取整棵树
SELECT node.name
FROM nested_category AS node,
nested_category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
AND parent.name = 'ELECTRONICS'
ORDER BY node.lft;

+----------------------+
| name                 |
+----------------------+
| ELECTRONICS          |
| TELEVISIONS          |
| TUBE                 |
| LCD                  |
| PLASMA               |
| PORTABLE ELECTRONICS |
| MP3 PLAYERS          |
| FLASH                |
| CD PLAYERS           |
| 2 WAY RADIOS         |
+----------------------+
跟Adjacency List Model的不同之处是查询不需要关注树的深度
查找树中的全部叶子节点
SELECT name
FROM nested_category
WHERE rgt = lft + 1;

+--------------+
| name         |
+--------------+
| TUBE         |
| LCD          |
| PLASMA       |
| FLASH        |
| CD PLAYERS   |
| 2 WAY RADIOS |
+--------------+
获取单一路径
SELECT parent.name
FROM nested_category AS node,
nested_category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
AND node.name = 'FLASH'
ORDER BY parent.lft;

+----------------------+
| name                 |
+----------------------+
| ELECTRONICS          |
| PORTABLE ELECTRONICS |
| MP3 PLAYERS          |
| FLASH                |
+----------------------+
获取节点深度
SELECT node.name, (COUNT(parent.name) - 1) AS depth
FROM nested_category AS node,
nested_category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
GROUP BY node.name
ORDER BY node.lft;

+----------------------+-------+
| name                 | depth |
+----------------------+-------+
| ELECTRONICS          |     0 |
| TELEVISIONS          |     1 |
| TUBE                 |     2 |
| LCD                  |     2 |
| PLASMA               |     2 |
| PORTABLE ELECTRONICS |     1 |
| MP3 PLAYERS          |     2 |
| FLASH                |     3 |
| CD PLAYERS           |     2 |
| 2 WAY RADIOS         |     2 |
+----------------------+-------+
如果新增节点

如果想要在“TELEVISIONS”和“PORTABLE ELECTRONICS”节点间新增一个节点,新节点的左、右值就是10和11,该节点右边节点的左、右值都要加2,MYSQL 4.x的实现如下!

LOCK TABLE nested_category WRITE;

SELECT @myRight := rgt FROM nested_category
WHERE name = 'TELEVISIONS';

UPDATE nested_category SET rgt = rgt + 2 WHERE rgt > @myRight;
UPDATE nested_category SET lft = lft + 2 WHERE lft > @myRight;

INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES', @myRight + 1, @myRight + 2);

UNLOCK TABLES;
如果要给一个没有子节点的节点增加一个子节点,上面的SQL要稍作调整。
LOCK TABLE nested_category WRITE;

SELECT @myLeft := lft FROM nested_category

WHERE name = '2 WAY RADIOS';

UPDATE nested_category SET rgt = rgt + 2 WHERE rgt > @myLeft;
UPDATE nested_category SET lft = lft + 2 WHERE lft > @myLeft;

INSERT INTO nested_category(name, lft, rgt) VALUES('FRS', @myLeft + 1, @myLeft + 2);

UNLOCK TABLES;
删除节点

如果删除的是一个叶子节点,除了删除节点本身,还要修改该节点右边节点的左、右值。SQL如下

LOCK TABLE nested_category WRITE;

SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1
FROM nested_category
WHERE name = 'GAME CONSOLES';

DELETE FROM nested_category WHERE lft BETWEEN @myLeft AND @myRight;

UPDATE nested_category SET rgt = rgt - @myWidth WHERE rgt > @myRight;
UPDATE nested_category SET lft = lft - @myWidth WHERE lft > @myRight;

UNLOCK TABLES;
       如果要删除某个节点以及它的子节点。SQL如下
 
LOCK TABLE nested_category WRITE;

SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1
FROM nested_category
WHERE name = 'MP3 PLAYERS';

DELETE FROM nested_category WHERE lft BETWEEN @myLeft AND @myRight;

UPDATE nested_category SET rgt = rgt - @myWidth WHERE rgt > @myRight;
UPDATE nested_category SET lft = lft - @myWidth WHERE lft > @myRight;

UNLOCK TABLES;
如果删除父节点的时候,不要求删除子节点,而是将子节点提升到删除节点的级别。SQL如下
LOCK TABLE nested_category WRITE;

SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1
FROM nested_category
WHERE name = 'PORTABLE ELECTRONICS';

DELETE FROM nested_category WHERE lft = @myLeft;

UPDATE nested_category SET rgt = rgt - 1, lft = lft - 1 WHERE lft BETWEEN @myLeft AND @myRight;
UPDATE nested_category SET rgt = rgt - 2 WHERE rgt > @myRight;
UPDATE nested_category SET lft = lft - 2 WHERE lft > @myRight;

UNLOCK TABLES;

 

参考资料

Storing Hierarchical Data in a Database

Managing Hierarchical Data in MySQL

一种理想的在关系数据库中存储树型结构数据的方法

Joe Celko’s Trees and Hierarchies in SQL for Smarties

A Nested Set Implementation in Java and PostgreSQL

Text Based Nested Set Implementation

Trees in SQL: Nested Sets and Materialized Path

分类: 数据库 标签:

Daniel-Journey Daily Dose-2010/2/12

2010年2月12日 admin 没有评论

Agile

Agile: The New Era

The study found that iterative and agile practices have a significant impact on defect and productivity factors, as indicated by the following points.

  • Releasing a system with 20% of the functionality complete is associated with a decrease in the defect rate of 10 defects per month per million lines of code as compared to waiting to release a product until 40% of the functionality is complete, and an increase in productivity of eight more lines of source code per person-day.
  • Continuous Integration, the idea of integrating and testing code as it is released to your source code repository, resulted in a decrease in the defect rate of 13 defects per month per million lines of code, and an increase in productivity of 17 lines of source code per person-day.

The first two are deeply embedded in the ideals of agile software development.

  • Releasing early and often to project stakeholders, using an iterative lifecycle.
  • Continuous integration, with daily builds including regression testing.
  • Teams with broad experience delivering multiple projects.
  • Careful attention to modular and loosely coupled, componentized architectures.

OOD and OOP

An (Overlooked?) Use Case for the Strategy Pattern

SOA

Enterprise Service Bus (ESB): a critical part of SOA

分类: 阅读 标签: , ,