父母是孩子的同龄人第1篇(14-17)~第2篇(1-21)

第一篇:为人父母的建议之14~17

14、嘘-别让孩子听到:父母一定尽量避免在孩子面前冲突。。。和谐的环境给孩子安全和信任的感觉

15、唠叨极其有害:造成这种尴尬局面最突出的一个原因就是家长“有令不行”

16、一家两制要统一:老人的教育经验是宝贝,看你会不会用。

17、不能太心疼孩子:收起你过多的怜悯心,孩子不是天生弱者。

第二篇:亲子对话的建议:李罡(教育学博士)

1、鼓励

2、爱要表达

3、由衷的表扬

4、放手帮助孩子自己去做

5、与孩子的谈话的学问,大得很:善于理解孩子的内心,聆听者,蹲下来和孩子说话,不要说当年我怎么。。。

6、先靠近孩子后引导

7、让孩子感受每位家人对她的关爱

8、分出一点点时间和爱给孩子

9、帮助孩子摆脱消极情绪

10、你稍做让步,抵触也会温柔

11、对孩子的任性不能过左过右,既要能放手让孩子做她适合的事,又要会坚定的说“不”字;

12、拒绝孩子不合理的要求但不要伤害

13、信守诺言

14、慎重对待孩子问的每一个为什么

15、孩子让你烦的时候,把你的感受告诉她,而不是要求她怎么怎么样

16、对孩子发脾气也要讲策略,不要在众人面前对孩子发脾气,她会产生比大人还要难以忍受的“羞耻感”

17、说理是真正对待儿童的办法

18、家长要很有计巧的用“错误”达到教育目的,。。。孩子的观察力极强,能察觉到大人的喜怒哀乐。。。

19、慎重对待孩子的错误。。。要鼓励孩子说实话

20、疼爱与过分照顾,剥夺了孩子成长的机会

21、放手让孩子做她能做的事

第一本书看了一半了,从中很有启发和感悟,也系统总结了一些我原来有的一些零星的概念。

我们在孩子面前脸红了

  一天早上,我和老婆为了一个什么事争论起来,孩子听见了。把正要还嘴的老婆的嘴巴用手捂住:妈妈,不要说了。

  我突然意识到,孩子多么希望一个和睦的家庭环境呀,当然,一个家庭没有争论是很困难的。我们一定要注意,一定要给孩子营造一个好的和睦的家庭环境。一定不要在孩子面前争论。

  我们听了孩子的话,当时就谁也不好意思还嘴了。

  我们在孩子面前脸红了。

《鼹鼠的故事》真是一部好动画片

  清新,自然,无拘无束的想像力,无说教却能传递:学会感激、爱护朋友、珍爱生命、仁慈、毅力等许多人类一直称颂的美德。

比如:鼹鼠和老鹰的故事,传递了爱惜生命、知恩图报的品格;鼹鼠和汽车的故事则是说他的毅力;制作衣服的故事则是赞扬团结和友谊;而在现代社会由于能源缺乏而导致倒退的那个片子里和由于森林砍伐建设城市的两个故事中,则赞赏了回归自然;而最体现无拘无束的想像力的那个鼹鼠和绿星星的故事更是把鼹鼠的毅力写得很感人,他想把一粒在挖洞时捡到的一粒绿宝石送上天空,可是不行,最后他伤心得哭了,泪水把一个鸟窝都灌满了。最后感动了月亮,月亮下来把鼹鼠搭上夜空,一阵风吹来,吹落了一颗星星(变成了流星),鼹鼠把绿宝石送上去补在了流星的位置。。。全部故事流畅、自然、想像力无拘无束。

鼹鼠的故事,不只是小孩看的动画片,大人看了一定也会很有收获的。

我从来没有看到过这样水准的国产动画片,中国动画业的精英们哪去了?

孩子这两天有点咳嗽

  实际上,孩子一直有点容易咳嗽,这两天有点严重,尤其是昨上,她爱踢被子。往往要咳嗽。吃了一幅中药,又吃了一幅西药,打了4针,今天基本上好了。我们打算不给她吃药了。是药3分毒。

UML在关系型数据库设计中的应用(转帖)

UML在关系型数据库设计中的应用 (转自:http://edu.sdinfo.net/74596379271364608/20030822/1194035.shtml)

发布时间: 08月22日 11:34

------------------------------------------------------------------------------------------------------ 1. 介绍

  许多人认为面向对象概念和关系型数据库相互不一致,并且不能结合。事实上完全相反!经过灵活的使用,一个关系型数据库能够为面向对象(OO)模型提供一套优秀的实现。同样的模型能够用来开发编程代码和关系型数据库结构。

  关系型数据库技术是意义深远的、强大的,但它比许多开发商使你相信的要难得多。单个表是简单易懂的、直观的。但由数以百计的表组成(这是常见的)的应用要彻底了解是相当困难的。这正是OO模型有用之处。 OO模型使你深入地、连贯地思考问题。

  OO模型提供一种问题的超结构(superstructure)的思考方式,然后该方式能够用关系型数据库的更低层的组成块来实现。

  本文章综合地讨论了关系型数据库技术,而不是集中于特定的产品上。我们将不讨论物理设计细节(例如存储分配和物理聚集),因为它们是依赖于产品的。

  用关系型数据库实现UML模型有两个方面:映射结构(第2节)和映射功能(第3节)。第4节注解了面向对象到关系型数据库的扩展。第5节总结本文章。

  2. 结构映射到表

  UML对象模型在本质上只是一个扩展的实体-关系(ER)模型 。使用设计数据库的ER模型的方式受到普遍接受,而我们以一种近似的但更强大的方式-使用UML对象模型。OO模型的主要优势在于编程和数据库的相同的模型工作。而且,作为考虑功能性的一种方式(第3节),我们强调OO模型的导航。这一节显示如何实现UML对象模型的主要构造。

  2.1 标识(identity)

  实现对象模型的第一步是处理标识。我们从定义几个术语开始。

  1)候选键(candidate key)是一个或多个属性的组合,它唯一地确定某个表里的记录。一个候选键里的属性集必须是最小化的;除非破坏唯一性,否则属性不能从候选键删除。候选键里的属性不能为空。

  2)主键(primary key)是一个特定地选定的候选键,用来优先地参考记录。

  3)外键(foreign key)是一个候选键的参考。外键必须包括每个要素属性的一个值,或者它必须全部为空。外键用来实现关联和一般化。

  正常地你应该为每个表定义一个主键,尽管偶尔有例外。我们强烈建议所有的外键都只指向主键而不是其它的候选键。

  定义主键有两种基本的方法:

  1)基于存在的标识。你应该为每个类表加一个对象标识符属性,并将它设为主键。每个关联表的主键包括一个或更多的相关类的标识符。基于存在的标识符有作为单独属性的优势,占位小且大小相同。只要你的关系型数据库管理系统(RDBMS)受支持,基于存在的标识符就没有性能的劣势。(多数RDBMS提供有效的基于存在的标识符的分配顺序号码。)唯一的劣势是基于存在的标识符在维护时内没有固有的意义。

  2)基于值的标识。一些真实世界的属性的组合确定了每个对象。基于值的标识有不同的优势。主键对于用户有固有的意义,容易进行调试和数据库维护。在另一面,基于值的主键很难改变。一个主键的改变需要传播到许多外键。一些对象没有自然的真实世界里的标识符。

  我们推荐你在超过30个类的RDBMS应用里使用基于存在的标识。基于存在和基于值的标识都是所有RDBMS应用的可行选项。

  2.2 域(属性类型)

  属性类型是UML术语,对应于数据库著作里的域的术语。比起直接用数据类型,域提升到更一致的设计,并便利了应用的定位。

  简单域很容易实现。你仅仅要定义相应的数据类型和大小。并且每个用了域的属性,你都必须为每个域约束加入一条SQL查询子句。简单域的一些例子是:名字(name),长字符(longString)和电话号码(phone-Number)。

  一个枚举域把一个属性限制在一系列的值里。枚举域比简单域实现起来更复杂,图表1显示了四个方法。

 

图表1:枚举的实现方法

 

  2.3类

  正常情况下,我们把每个类映射为一个表,每个属性映射为一个列。你可能因一个已产生的标识符(基于存在的标识符)、隐藏的关联(第2.4节)和通用鉴别器(第2.5节)需要一些另外的列。

  2.4关联

  现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射(我们正常使用的映射),可选的映射(我们偶尔使用的映射)和不鼓励的映射(我们遇到的应该避免的错误)。我们所有的例子都采用基于存在的标识。

  2.4.1 建议的映射

  多对多关联。用一个特别的表(图表2)来实现一个多对多关联。关联的主键是每个类的主键的合并。那些省略号(...)表示在模型里没有显示出来的属性。主键用黑体字体显示。

  一对多关联。把一个外键隐藏在“多”表(图表3)。角色名字成为外键属性名字的一部分。

  零或一对一关联。把外键隐藏在“零或一”表(图表4)。

  其它一对一关联。把外键隐藏在任一表里。

 

图表2:建议的实现:特殊的多对多关联表

 

图表3:建议的实现:隐藏的一对多关联

 

图表4:建议的实现:隐藏的零或一对一关联

  可选的映射 正常情况下我们使用建议的映射。但有些偶尔的情况,可选的映射更合适。

  特别的表。你也可以用特别的表(图表5)来实现一对多和一对一关联。特别的表给了你更统一的设计和更大的扩展性。无论如何,特别的关联表打碎了数据库,并增加了表的数量。此外,特别的关联表不能强迫一个更低的多重性限度为“一”。

 

图表5:可选的实现:特别的一对x关联表

  不鼓励的映射 我们已经注意到有些开发者选择有缺陷的映射。我们要注意这些映射以便可以避免。 合并。不要合并多个类,不要把关联强制成为一个单独的表(图表6)。这样减少了表的数量,但会干扰第三范式。

  两次隐藏一对一关联。不要把一个一对一关联隐藏两次,每次隐藏在一个类里(图表7)。这是多余的,无助于性能。

  相同的属性。不要用相同的属性来实现多个关联角色(图表8)。相同的属性使编程复杂,降低了扩展性。 泛化 现在我们讨论泛化。我们这里只论述单个继承。 建议的映射 最简单的方法是只映射超类和每个子类为一个表。所有的表共享一个共同的主键。应用必须执行子类的划分,因为RDBMS支持。(关于后者的详尽的描述,请参阅第4节。)

  特别的表。映射超类和每个子类为一个表(图表9)。所有的表共享一个共同的主键。鉴别器指出每个子类记录的适当的超类表。

 

图表9:建议的实现:分开的超类和子类表

  可选的映射 泛化有几个可选的映射。 消除。你可以优化除去那些除了主键外没有别的属性的类(图表10)。这样减少了表的数量,但提供更少的正规实现。

  减少超类属性。你可以除去超类表并把超类属性复制到每个子类(图表11)。这样可以有描述每个对象为一个表的优势。无论如何,它将引起数据库结构的冗余,你查找一个对象时可能需要搜索多个子类表。

  增加子类属性。作为第三个可选项,你可以除去子类表并存储所有的子类属性到超类表里(图表12)。这样用一个表描述每个对象,但干扰了第二范式。

 

图表10:可选的实现:消除不必的子类表

 

图表11:可选的实现:减少超类属性

  

 

图表12:可选的实现:增加子类属性

 

  参考完整性 一旦你已经建立了表,你就应该定义参考完整性动作来明确对象模型的意义。(不要使用SQL触发器来实现参考完整性!)如果你使用基于存在的标识,你将不需要传播更新的结果。我们建议以下对删除的参考完整性方针: 泛化。级联从泛化实现中产生的外键的删除。

  隐藏的关联,最小化多样性为零。正常地把外键设为空,但有时候你可能要禁止删除。

  隐藏的关联,最小化多样性为空。你可以级联一个删除的结果或者禁止该删除。

  关联表。正常地我们级联关联表里对记录的删除。可是,有时候我们禁止一个删除。

  我们已经简要地论及参考完整性,因为它是个高级话题。参考有更多的解释z和例子。 索引 实现数据库结构的最后的一步是加入索引来调整数据库性能。正常地,你应该为每个主键和候选键定义一个唯一的索引。(多数RDBMS作为SQL主键和候选键约束的副作用来建立唯一的索引。)你也应该为每个被主键或候选键所约束的外键建立一个索引。

  我们强调索引的重要性。外键和主键的索引使在对象模型里能快速地遍历是不容怀疑的。你必须包括这些索引否则你将使用户感到灰心。你应该在你的数据库开始设计阶段里加入索引,因为它们很容易加入并且也没有什么好理由推迟加入。

  数据库管理员(DBA)可能为经常请求的查询定义了额外的索引。DBA也可能采用产品相关的调整性能的机制。 范式 范式是关系型数据库设计的提高数据一致性的有效方法。我们的书3讨论了范式,但我们关于这个问题却言过甚微。我们将利用这篇文章的机会来澄清我们的观点。如果你不熟悉范式你可以跳过这节。我们的说明是针对关系型设计人员,他们正在尝试用面向对象适应他们原有的技能。

  范式是正确设计关系型数据库的精确的原则。同样地,它们与使用了什么开发技术是无关的 - 基于属性的设计、基于实体的设计、面向对象设计或其它什么。 过去使用基于属性设计的方法,开发人员不得不非常注意范式;范式提供了分组数据的根据。相反地,范式对于基于面向对象(或基于实体)的开发不是很重要。如果你采用OO方法并且你的模型经过很好的构思,那你就正在把数据组织成为有意义的单位,也在本质上满足了范式的规定。如果你愿意,你仍能够检查范式,但这样的检查是不必要的。 摘要 图表13总结了我们已经陈述的映射规则。这些映射规则的完整例子,包括一个UML对象模型,能够在这篇完整的扩展版本里找到(Adobe Acrobat PDF文件)。

 

图表13:推荐的映射规则的摘要

  

  把功能映射到SQL命令 对象模型为数据库应用提供三种主要的用途。 结构。对象模型指明数据库结构。我们已经在第二节探讨了这个方面。

  约束。对象模型也指明了能存储的数据上的重要的约束。相匹配的实现必须为迎合这些约束而努力。我们的映射规则的处理方法以及第二节里的参考完整性指出了许多约束。(本文没有论及的另外的UML构造,能获取更多的约束。)

  潜在估算。一个对象模型指明潜在估算;它是关于引起哪些查询和如何公式化的蓝图。第三节将简要地阐明第三个目的。

  对象模型不仅仅是被动的数据结构,相反它们能够帮助你思考一个应用的功能。你可以根据遍历一个对象模型说出它的许多功能。例如,根据我们对一个模型检查用例时的遍历,我们进行思索。这强调对象模型的估算能力对于RDBMS应用是特别重要的,因为遍历表达式可以直接映射到SQL代码。

  UML对象约束语言(Object Constraint Language,OCL)有助于表达遍历。点符号导航从对象到对象和对象到属性。方括号表示对象集合的过滤器。我们加入冒号(:)操作符来表示泛化的遍历;因为我们正常地用多个表来实现一个泛化继承,清楚的遍历很有用。

  图表14里的遍历表达式例子是基于我们创建的UML对象模型上的(请参阅本文的扩展版本(Adobe Acrobat PDF文件)),我们把它们映射为SQL代码。我们用冒号开始SQL编程变量。

 

图表14:对象模型遍历和SQL代码的例子

  到RDBMS的OO扩展 数据库团体对RDBMS的OO扩展有兴趣。产品和SQL标准正尝试加入到OO扩展里。我们将简要地陈述一下这个技术的方向。 抽象数据类型(ADT)。这是个好主意,扩展RDBMS的能力。开发商为这个技术使用了许多名字,例如Oracle cartridge和Informix data blades。ADT的缺点是它们把你紧紧绑在特定的一个开发商上;ADT的范畴超越了SQL标准。因此,你应该只在ADT的好处很明显的时候才使用。

  在关于ADT如何适合数据库开发的著作里有一些混乱。如果你使用OMT开发过程,你能够用属性实现简单域,用ADT实现复杂域。你仍应该用表实现类。 SQL3指针。最新的SQL标准的版本,SQL3,加入了作为一种数据类型的指针符号。显然,其意图是支持导航和面向对象。我们对于SQL3指针最友善的评语是,它们是嫁接的,是可以忽略的。更深入的批评是,指针在理论上是荒谬的,增加了复杂性,又没有扩展SQL的表达能力。CJ Date在上次的九月对象/关系型会议上雄辩地讨论了这一点。

  好了,那么我们冷淡地对待抽象数据类型和SQL指针的指责。但我们相当喜欢面向对象技术和关系型数据库。有两个为RDBMS的扩展可以使它们更容易用于OO技术。我们将很乐意看到RDBMS开发商把这些能力加入到他们的产品中。 扩展的参考完整性动作来支持泛化。当前的参考完整性机制是单向的。为了完全支持泛化,我们需要一个双向的机制。这样,一条超类记录就可以依赖一条子类记录。并且,一条子类记录就可以依赖一条超类记录。我们通过例子可以最好地解释这点。

  图表15摘录于我们的在3的财务案例学习。我们用资产超类来统一某些没有显示在摘录里的通用的数据和功能。一项资产可以是一只股票或股票特权。一只股票可以有许多它的股票特权。例如,IBM股票可以有许多达到价格和过期日期的写下的放或叫特权。

 

图表15:参考完整性和泛化的例子

  我们推荐的泛化实现是特别的表 - 映射该超类和每个子类为一个表。然后,我们就可以使用参考完整性使股票特权和股票的记录依赖于资产。一个资产记录的删除级联到相应的子类记录、股票特权或股票的删除上。我们也能够定义一个参考完整性动作,这样一个股票的删除就级联到关联的股票特权记录的删除。

  现在问题如下。如果我们删除的一项资产是一只股票,资产记录的删除级联到引起股票记录的删除。随后,股票记录的删除级联引起所有股票特权记录的删除。但现在参考完整性使我们失败了:一个股票特权记录的删除并不引起一项资产记录的删除。删除级联只能从超类走到子类。为了完全的行为,级联应该双向地走下去。

  当前有用的参考完整性的工作是做更多的编程(也即做更多的工作和风险更多故障)。在我们的用例学习的实现里,用户随时要删除一项是股票的资产,我们不得不书写额外的代码来首先检查关联股票特权的存在性,然后删除它们。 支持交叉表的记录划分。单独继承(泛化的最常见方式)的含义是一个超类的每个实例都是用多数只有一个子类来例示。现在的RDBMS不能容易地加强这个约束。例如,没有什么防止下面的情形。一只股票可以用ID18加入到资产表,用ID18加入到股票表,并且也可以用ID18加入到股票特权表。再一次地,我们为了确信行为的完整,不得不作额外的编程,而不是写一个简单的声明的约束 

  结论

  本文陈述了用关系型数据库实现UML模型的快速的概观。我们希望本文向你演示的技术是足够适宜的。一个训练有素的开发人员能够用关系型数据库准备一套优秀的OO模型的实现。如果你要关于实现机制的更多的细节,参考3有另外的信息,并且也覆盖了我们没有在这里讨论的一些高级模型建模结构。

文章出处:《中国电脑教育报》

mysql数据库优化 及MySQL服务维护笔记 (Linux下)(转帖2

(转自:http://spaces.msn.com/lzhuacuo/PersonalSpace.aspx?_c11_blogpart_blogpart=blogview&_c=blogpart&partqs=cat%3dOpen%2bSource)

mysql数据库优化

 

添加:2005-9-4 6:43:26 来源: 作者:

 

 

首先,为了使一个系统更快,最重要的部分就是基础设计,不过有些东西是现有情况下无法逾越的,比如说系统常见的瓶颈.

我所能想到的:

1:磁盘寻道能力,以高速硬盘(7200转/秒),理论上每秒寻道7200次.这是没有办法改变的,优化的方法是----用多个硬盘,或者把数据分散存储.

2:硬盘的读写速度,这个速度非常的快(限于本人的知识所限,只知道在每秒几十甚至上百MB).这个更容易解决--可以从多个硬盘上并行读写.

3:cpu.cpu处理内存中的数据,当有相对内存较小的表时,这是最常见的限制因素.

4:内存的限制.当cpu需要超出适合cpu缓存的数据时,缓存的带宽就成了内存的一个瓶颈---不过现在内存大的惊人,一般不会出现这个问题.

第二步:

(本人使用的是学校网站的linux平台(Linux ADVX.Mandrakesoft.com 2.4.3-19mdk ))

1:调节服务器参数

用shell>mysqld-help这个命令声厂一张所有mysql选项和可配置变量的表.输出以下信息:

possible variables for option--set-variable(-o) are:

back_log current value:5 //要求mysql能有的连接数量.back_log指出在mysql暂停接受连接的时间内有多少个连接请求可以被存在堆栈中

connect_timeout current value:5 //mysql服务器在用bad handshake(不好翻译)应答前等待一个连接的时间

delayed_insert_timeout current value:200 //一个insert delayed在终止前等待insert的时间

delayed_insert_limit current value:50 //insert delayed处理器将检查是否有任何select语句未执行,如果有,继续前执行这些语句

delayed_queue_size current value:1000 //为insert delayed分配多大的队

flush_time current value:0 //如果被设置为非0,那么每个flush_time 时间,所有表都被关闭

interactive_timeout current value:28800 //服务器在关上它之前在洋交互连接上等待的时间

join_buffer_size current value:131072 //用与全部连接的缓冲区大小

key_buffer_size current value:1048540 //用语索引块的缓冲区的大小,增加它可以更好的处理索引

lower_case_table_names current value:0 //

long_query_time current value:10 //如果一个查询所用时间大于此时间,slow_queried计数将增加

max_allowed_packet current value:1048576 //一个包的大小

max_connections current value:300 //允许同时连接的数量

max_connect_errors current value:10 //如果有多于该数量的中断连接,将阻止进一步的连接,可以用flush hosts来解决

max_delayed_threads current value:15 //可以启动的处理insert delayed的数量

max_heap_table_size current value:16777216 //

max_join_size current value:4294967295 //允许读取的连接的数量

max_sort_length current value:1024 //在排序blob或者text时使用的字节数量

max_tmp_tables current value:32 //一个连接同时打开的临时表的数量

max_write_lock_count current value:4294967295 //指定一个值(通常很小)来启动mysqld,使得在一定数量的write锁定之后出现read锁定

net_buffer_length current value:16384 //通信缓冲区的大小--在查询时被重置为该大小

query_buffer_size current value:0 //查询时缓冲区大小

record_buffer current value:131072 //每个顺序扫描的连接为其扫描的每张表分配的缓冲区的大小

sort_buffer current value:2097116 //每个进行排序的连接分配的缓冲区的大小

table_cache current value:64 //为所有连接打开的表的数量

thread_concurrency current value:10 //

tmp_table_size current value:1048576 //临时表的大小

thread_stack current value:131072 //每个线程的大小

wait_timeout current value:28800 //服务器在关闭它3之前的一个连接上等待的时间

根据自己的需要配置以上信息会对你帮助.

 

 

 

 

添加评论 | 阅读评论 (1)

9:46  |  固定链接 | 引用通告 (0) | 记录它 | Open Source

 

 

固定链接  关闭

 

http://spaces.msn.com/lzhuacuo/blog/cns!18730E989D068035!473.entry

 

 

 

 

 

 

 

MySQL服务维护笔记

 

MySQL服务维护笔记

作者: 车东 Email: chedongATbigfoot.com/chedongATchedong.com

写于:2002/07 最后更新: 03/16/2005 16:28:35

Feed Back >> (Read this before you ask question)

版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明

http://www.chedong.com/tech/mysql.html

内容摘要:使用MySQL服务的一些经验,主要从以下几个方面考虑的MySQL服务规划设计。对于高负载站点来说PHP和MySQL运行在一起(或者说任何应用和数据库运行在一起的规划)都是性能最大的瓶颈,这样的设计有如让人一手画圆一手画方,这样2个人的工作效率肯定不如让一个人专门画圆一个人专门画方效率高,让应用和数据库都跑在一台高性能服务器上说不定还不如跑在2台普通服务器上快。

以下就是针对MySQL作为专门的数据库服务器的优化建议:

MySQL服务的安装/配置的通用性;

系统的升级和数据迁移方便性;

备份和系统快速恢复;

数据库应用的设计要点;

一次应用优化实战;

MySQL服务器的规划

=================

为了以后维护,升级备份的方便和数据的安全性,最好将MySQL程序文件和数据分别安装在“不同的硬件”上。

         /   /         |    /usr                     <== 操作系统                 |    /home/mysql              <== mysql主目录,为了方便升级,这只是一个最新版本目录的链接 硬盘1==>|    /home/mysql-3.23.54/     <== 最新版本的mysql /home/mysql链接到这里         \   /home/mysql-old/         <== 以前运行的旧版本的mysql         /   /data/app_1/             <== 应用数据和启动脚本等硬盘2==>|    /data/app_2/         \   /data/app_3/

MySQL服务的安装和服务的启动:

MySQL一般使用当前STABLE的版本:

尽量不使用--with-charset=选项,我感觉with-charset只在按字母排序的时候才有用,这些选项会对数据的迁移带来很多麻烦。

尽量不使用innodb,innodb主要用于需要外键,事务等企业级支持,代价是速度比MYISAM有数量级的下降。

./configure --prefix=/home/mysql --without-innodb

make

make install

服务的启动和停止

================

1 复制缺省的mysql/var/mysql到 /data/app_1/目录下,

2 MySQLD的启动脚本:start_mysql.sh

#!/bin/sh

rundir=`dirname "$0"`

echo "$rundir"

/home/mysql/bin/safe_mysqld --user=mysql --pid-file="$rundir"/mysql.pid --datadir="$rundir"/var "$@"\

-O max_connections=500 -O wait_timeout=600 -O key_buffer=32M --port=3402 --socket="$rundir"/mysql.sock &

注释:

--pid-file="$rundir"/mysql.pid --socket="$rundir"/mysql.sock --datadir="$rundir"/var

目的都是将相应数据和应用临时文件放在一起;

-O 后面一般是服务器启动全局变量优化参数,有时候需要根据具体应用调整;

--port: 不同的应用使用PORT参数分布到不同的服务上去,一个服务可以提供的连接数一般是MySQL服务的主要瓶颈;

修改不同的服务到不同的端口后,在rc.local文件中加入:

/data/app_1/start_mysql.sh

/data/app_2/start_mysql.sh

/data/app_3/start_mysql.sh

注意:必须写全路径

3 MySQLD的停止脚本:stop_mysql.sh

#!/bin/sh

rundir=`dirname "$0"`

echo "$rundir"

/home/mysql/bin/mysqladmin -u mysql -S"$rundir"/mysql.sock shutdown

使用这个脚本的好处在于:

1 多个服务启动:对于不同服务只需要修改脚本中的--port[=端口号]参数。单个目录下的数据和服务脚本都是可以独立打包的。

2 所有服务相应文件都位于/data/app_1/目录下:比如:mysql.pid mysql.sock,当一台服务器上启动多个服务时,多个服务不会互相影响。但都放到缺省的/tmp/下则有可能被其他应用误删。

3 当硬盘1出问题以后,直接将硬盘2放到一台装好MySQL的服务器上就可以立刻恢复服务(如果放到my.cnf里则还需要备份相应的配置文件)。

服务启动后/data/app_1/下相应的文件和目录分布如下:

/data/app_1/

    start_mysql.sh 服务启动脚本

    stop_mysql.sh 服务停止脚本

    mysql.pid 服务的进程ID

    mysql.sock 服务的SOCK

    var/ 数据区

       mysql/ 用户库

       app_1_db_1/ 应用库

       app_1_db_2/

...

/data/app_2/

...

查看所有的应用进程ID:

cat /data/*/mysql.pid

查看所有数据库的错误日志:

cat /data/*/var/*.err

个人建议:MySQL的主要瓶颈在PORT的连接数上,因此,将表结构优化好以后,相应单个MySQL服务的CPU占用仍然在10%以上,就要考虑将服务拆分到多个PORT上运行了。

服务的备份

==========

尽量使用MySQL DUMP而不是直接备份数据文件,以下是一个按weekday将数据轮循备份的脚本:备份的间隔和周期可以根据备份的需求确定

/home/mysql/bin/mysqldump -S/data/app_1/mysql.sock -umysql db_name | gzip -f>/path/to/backup/db_name.`data +%w`.dump.gz

因此写在CRONTAB中一般是:

15 4 * * * /home/mysql/bin/mysqldump -S/data/app_1/mysql.sock -umysql db_name | gzip -f>/path/to/backup/db_name.`data +\%w`.dump.gz

注意:

1 在crontab中'%'需要转义成'\%'

2 根据日志统计,应用负载最低的时候一般是在早上4-6点

先备份在本地然后传到远程的备份服务器上,或者直接建立一个数据库备份帐号,直接在远程的服务器上备份,远程备份只需要将以上脚本中的-S /path/to/msyql.sock改成-h IP.ADDRESS即可。

数据的恢复和系统的升级

======================

日常维护和数据迁移:在数据盘没有被破坏的情况下

硬盘一般是系统中寿命最低的硬件。而系统(包括操作系统和MySQL应用)的升级和硬件升级,都会遇到数据迁移的问题。

只要数据不变,先装好服务器,然后直接将数据盘(硬盘2)安装上,只需要将启动脚本重新加入到rc.local文件中,系统就算是很好的恢复了。

灾难恢复:数据库数据本身被破坏的情况下

确定破坏的时间点,然后从备份数据中恢复。

应用的设计要点

==============

如果MySQL应用占用的CPU超过10%就应该考虑优化了。

如果这个服务可以被其他非数据库应用代替(比如很多基于数据库的计数器完全可以用WEB日志统计代替)最好将其禁用:

非用数据库不可吗?虽然数据库的确可以简化很多应用的结构设计,但本身也是一个系统资源消耗比较大的应用。在某些情况下文本,DBM比数据库是更好的选择,比如:很多应用如果没有很高的实时统计需求的话,完全可以先记录到文件日志中,定期的导入到数据库中做后续统计分析。如果还是需要记录简单的2维键-值对应结构的话可以使用类似于DBM的HEAP类型表。因为HEAP表全部在内存中存取,效率非常高,但服务器突然断电时有可能出现数据丢失,所以非常适合存储在线用户信息,日志等临时数据。即使需要使用数据库的,应用如果没有太复杂的数据完整性需求的化,完全可以不使用那些支持外键的商业数据库,比如MySQL。只有非常需要完整的商业逻辑和事务完整性的时候才需要Oracle这样的大型数据库。对于高负载应用来说完全可以把日志文件,DBM,MySQL等轻量级方式做前端数据采集格式,然后用Oracle MSSQL DB2 Sybase等做数据库仓库以完成复杂的数据库挖掘分析工作。

有朋友和我说用标准的MyISAM表代替了InnoDB表以后,数据库性能提高了20倍。

数据库服务的主要瓶颈:单个服务的连接数

对于一个应用来说,如果数据库表结构的设计能够按照数据库原理的范式来设计的话,并且已经使用了最新版本的MySQL,并且按照比较优化的方式运行了,那么最后的主要瓶颈一般在于单个服务的连接数,即使一个数据库可以支持并发500个连接,最好也不要把应用用到这个地步,因为并发连接数过多数据库服务本身用于调度的线程的开销也会非常大了。所以如果应用允许的话:让一台机器多跑几个MySQL服务分担。将服务均衡的规划到多个MySQL服务端口上:比如app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309。一个1G内存的机器跑上10个MySQL是很正常的。让10个MySQLD承担1000个并发连接效率要比让2个MySQLD承担1000个效率高的多。当然,这样也会带来一些应用编程上的复杂度;

使用单独的数据库服务器(不要让数据库和前台WEB服务抢内存),MySQL拥有更多的内存就可能能有效的进行结果集的缓存;在前面的启动脚本中有一个-O key_buffer=32M参数就是用于将缺省的8M索引缓存增加到32M(当然对于)

应用尽量使用PCONNECT和polling机制,用于节省MySQL服务建立连接的开销,但也会造成MySQL并发链接数过多(每个HTTPD都会对应一个MySQL线程);

表的横向拆分:让最常被访问的10%的数据放在一个小表里,90%的历史数据放在一个归档表里(所谓:快慢表),数据中间通过定期“搬家”和定期删除无效数据来节省,毕竟大部分应用(比如论坛)访问2个月前数据的几率会非常少,而且价值也不是很高。这样对于应用来说总是在一个比较小的结果级中进行数据选择,比较有利于数据的缓存,不要指望MySQL中对单表记录条数在10万级以上还有比较高的效率。而且有时候数据没有必要做那么精确,比如一个快表中查到了某个人发表的文章有60条结果,快表和慢表的比例是1:20,那么就可以简单的估计这个人一共发表了1200篇。Google的搜索结果数也是一样:对于很多上十万的结果数,后面很多的数字都是通过一定的算法估计出来的。

数据库字段设计:表的纵向拆分(过渡范化):将所有的定长字段(char, int等)放在一个表里,所有的变长字段(varchar,text,blob等)放在另外一个表里,2个表之间通过主键关联,这样,定长字段表可以得到很大的优化(这样可以使用HEAP表类型,数据完全在内存中存取),这里也说明另外一个原则,对于我们来说,尽量使用定长字段可以通过空间的损失换取访问效率的提高。在MySQL4中也出现了支持外键和事务的InnoDB类型表,标准的MyISAM格式表和基于HASH结构的HEAP内存表,MySQL之所以支持多种表类型,实际上是针对不同应用提供了不同的优化方式;

仔细的检查应用的索引设计:可以在服务启动参数中加入 --log-slow-queries[=file]用于跟踪分析应用瓶颈,对于跟踪服务瓶颈最简单的方法就是用MySQL的status查看MySQL服务的运行统计和show processlist来查看当前服务中正在运行的SQL,如果某个SQL经常出现在PROCESS LIST中,一。有可能被查询的此时非常多,二,里面有影响查询的字段没有索引,三,返回的结果数过多数据库正在排序(SORTING);所以做一个脚本:比如每2秒运行以下show processlist;把结果输出到文件中,看到底是什么查询在吃CPU。

全文检索:如果相应字段没有做全文索引的话,全文检索将是一个非常消耗CPU的功能,因为全文检索是用不上一般数据库的索引的,所以要进行相应字段记录遍历。关于全文索引可以参考一下基于Java的全文索引引擎lucene的介绍。

前台应用的记录缓存:比如一个经常使用数据库认证,如果需要有更新用户最后登陆时间的操作,最好记录更新后就把用户放到一个缓存中(设置2个小时后过期),这样如果用户在2个小时内再次使用到登陆,就直接从缓存里认证,避免了过于频繁的数据库操作。

查询优先的表应该尽可能为where和order by字句中的字段加上索引,数据库更新插入优先的应用索引越少越好。

总之:对于任何数据库单表记录超过100万条优化都是比较困难的,关键是要把应用能够转化成数据库比较擅长的数据上限内。也就是把复杂需求简化成比较成熟的解决方案内。

一次优化实战

============

以下例子是对一个论坛应用进行的优化:

用Webalizer代替了原来的通过数据库的统计。

首先通过TOP命令查看MySQL服务的CPU占用左右80%和内存占用:10M,说明数据库的索引缓存已经用完了,修改启动参数,增加了-O key_buffer=32M,过一段时间等数据库稳定后看的内存占用是否达到上限。最后将缓存一直增加到64M,数据库缓存才基本能充分使用。对于一个数据库应用来说,把内存给数据库比给WEB服务实用的多,因为MySQL查询速度的提高能加快web应用从而节省并发的WEB服务所占用的内存资源。

用show processlist;统计经常出现的SQL:

每分钟运行一次show processlist并记录日志:

* * * * * (/home/mysql/bin/mysql -uuser -ppassword < /home/chedong/show_processlist.sql >>  /home/chedong/mysql_processlist.log)

show_processlist.sql里就一句:

show processlist;

比如可以从日志中将包含where的字句过滤出来:

grep where mysql_processlist.log

如果发现有死锁,一定要重新审视一下数据库设计了,对于一般情况:查询速度很慢,就将SQL where字句中没有索引的字段加上索引,如果是排序慢就将order by字句中没有索引的字段加上。对于有%like%的查询,考虑以后禁用和使用全文索引加速。

还是根据show processlist;看经常有那些数据库被频繁使用,考虑将数据库拆分到其他服务端口上。

MSSQL到MySQL的数据迁移:ACCESS+MySQL ODBC Driver

在以前的几次数据迁移实践过程中,我发现最简便的数据迁移过程并不是通过专业的数据库迁移工具,也不是MSSQL自身的DTS进行数据迁移(迁移过程中间会有很多表出错误警告),但通过将MSSQL数据库通过ACCESS获取外部数据导入到数据库中,然后用ACCESS的表==>右键==>导出,制定ODBC,通过MySQL的DSN将数据导出。这样迁移大部分数据都会非常顺利,如果导出的表有索引问题,还会出添加索引提示(DTS就不行),然后剩余的工作就是在MySQL中设计字段对应的SQL脚本了。

参考文档:

MySQL的参考:

http://www.mysql.com/documentation/mysql/bychapter/

原文出处:<a href="http://www.chedong.com/tech/mysql.html">http://www.chedong.com/tech/mysql.html</a>

<<返回

 

XML-RPC 之 Apache XML-RPC 实例 及规范(转帖2篇)

XML-RPC 之 Apache XML-RPC 实例 (转自:http://spaces.msn.com/lzhuacuo/blog/cns!18730E989D068035!507.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink)

 

XML-RPC 之 Apache XML-RPC 实例

作者:王恩建 来源:http://www.sentom.net

XML-RPC 是工作在 Internet 上的远程过程调用协议。通俗点讲,就是使用 HTTP 协议交互,交互的载体是 XML 文件。XML-RPC 具体的规范说 明请参考这里。

图片来自XML-RPC官方网站

XML-RPC 规范定义了六种数据类型,下表是这六种数据类型与 Java 的数据类型对应表。

XML-RPC Java

<i4> 或 <int> int

<boolean> boolean

<string> java.lang.String

<double> double

<dateTime.iso8601> java.util.Date

<struct> java.util.Hashtable

<array> java.util.Vector

<base64> byte[ ]

XML-RPC 规范的各种平台都有具体实现,XML-RPC 规范的 Java 实现都有好几种,这里我们选择了 Apache XML-RPC。

XML-RPC 服务端实现

先定义一个简单业务对象 MyHandler,远程客户端将调用该对象的方法,具体代码如下:

package net.sentom.xmlrpc;

public class MyHandler {

public String sayHello(String str){

return "Hello," + str;

}

}

然后定义一个 Servlet 名叫 MyXmlRpcServer,远程客户端通过 HTTP-POST 访问该 Servlet。

package net.sentom.xmlrpc;

import java.io.IOException;

import java.io.OutputStream;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import org.apache.xmlrpc.XmlRpcServer;

public class MyXmlRpcServer extends HttpServlet {

public void doPost(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

XmlRpcServer xmlrpc = new XmlRpcServer();

xmlrpc.addHandler("myHandler", new MyHandler());

byte[] result = xmlrpc.execute(request.getInputStream());

response.setContentType("text/xml");

response.setContentLength(result.length);

OutputStream out = response.getOutputStream();

out.write(result);

out.flush();

}

}

需要特别说明是:

xmlrpc.addHandler("myHandler", new MyHandler());

为了便于理解,这里可以看成普通的:

MyHandler myHandler = new MyHandler();

最后在web.xml文件中加入以下几行:

<servlet>

    <servlet-name>MyXmlRpcServer</servlet-name>

    <servlet-class>net.sentom.xmlrpc.MyXmlRpcServer</servlet-class>

</servlet>

<servlet-mapping>

    <servlet-name>MyXmlRpcServer</servlet-name>

    <url-pattern>/MyXmlRpcServer</url-pattern>

</servlet-mapping>

XML-RPC 客户端实现

客户端相对简单一些,先来一个 Java 客户端实现 MyXmlRpcClient:

package net.sentom.xmlrpc;

import java.io.IOException;

import java.net.MalformedURLException;

import java.util.Vector;

import org.apache.xmlrpc.XmlRpcClient;

import org.apache.xmlrpc.XmlRpcException;

public class MyXmlRpcClient {

public static void main(String[] args) {

try {

XmlRpcClient xmlrpc = new XmlRpcClient("http://localhost:8080/XMLRPC/MyXmlRpcServer");

Vector params = new Vector();

params.addElement("Tom");

String result = (String) xmlrpc.execute("myHandler.sayHello",params);

System.out.println(result);

} catch (MalformedURLException e) {

System.out.println(e.toString());

} catch (XmlRpcException e) {

System.out.println(e.toString());

} catch (IOException e) {

e.printStackTrace();

}

}

http://localhost:8080/XMLRPC/MyXmlRpcServer 为 MyXmlRpcServer 的访问URL。

String result = (String) xmlrpc.execute("myHandler.sayHello",params);

再来一个 Python 客户端实现

import xmlrpclib

url = 'http://localhost:8080/XMLRPC/MyXmlRpcServer';

server = xmlrpclib.Server(url);

print server.myHandler.sayHello('Tom');

 

 

 

添加评论

9:12  |  固定链接 | 引用通告 (0) | 记录它 | Open Source

 

 

固定链接  关闭

 

http://spaces.msn.com/lzhuacuo/blog/cns!18730E989D068035!507.entry

 

 

 

 

 

 

 

XML-RPC规范(中文版) (转自:http://spaces.msn.com/lzhuacuo/blog/cns!18730E989D068035!504.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink)

 

XML-RPC规范(中文版)

把这篇文章转到blog里,希望rainbowsoft能看见有朝一日给blog写支持客户端post的功能时能用上

 

Tue, Jun 15, 1999; by Dave Winer. (翻译:滴水 最后修改时间:2005-3-15 后续完善)

更新 6/30/03 DW

更新 10/16/99 DW

更新 1/21/99 DW

本规范说明的XML-RPC协议实现UserLand Frontier 5.1。

关于非技术性说明,请访问XML-RPC for Newbies。

文档提供了实现XML-RPC所需要的所有信息。

前言

XML-RPC是一种基于Internet的远程函数调用协议。

XML-RPC消息都是HTTP-POST请求。请求的主要部分的XML。服务器端执行后的返回结果同样也是XML格式。

函数调用的参数可以是scalars, numbers, strings, dates等等;也可以是混合型的记录和结构体。

Request请求样式

下面是一个XML-RPC请求的例子:

POST /RPC2 HTTP/1.0

User-Agent: Frontier/5.1.2 (WinNT)

Host: betty.userland.com

Content-Type: text/xml

Content-length: 181

<?xml version="1.0"?>

<methodCall>

   <methodName>examples.getStateName</methodName>

   <params>

      <param>

         <value><i4>41</i4></value>

         </param>

      </params>

   </methodCall>

关于请求头

第一行的URI格式不是特定的。可以为空,如果服务器只处理XML-RPC请求甚至可以只是简单的一个斜线。可是,如果服务器除了XML-RPC外还提供其他的HTTP请求,URI可以帮助我们把请求指向特定的XML-RPC服务。

User-Agent和Host项是必须的。

Content-Type的值必须是text/xml.

Content-Length必须指定,而且必须是正确的值。

有效的格式

XML-RPC具有和XML一样的有效格式,并且是一个<methodCall>结构。

<methodCall>必须包含一个值为字符型的<methodName>子元素,用来表明被调用的方法。这个字符必须符合以下规定:大小写字母、数字0-9、下划线、点、冒号和斜线。至于怎么解释这个字符串将有服务器端来决定。

例如,methodName可以是一个包含执行request请求的文件的名字,可以是数据表中列的名字,还可以是表示目录和文件结构的路径。

如果远程调用接受参数,<methodCall>就必须包含<params>子元素。<params>可以包含任意个<param>元素,每个<param>包含一个<value>子元素。

Scalar <value>s <value>

<value>值被嵌入类型标签中,支持的类型如下表:

Tag Type Example

<i4> or <int> four-byte signed integer -12

<boolean> 0 (false) or 1 (true) 1

<string> string hello world

<double> double-precision signed floating point number -12.214

<dateTime.iso8601> date/time 19980717T14:08:55

<base64> base64-encoded binary eW91IGNhbid0IHJlYWQgdGhpcyE=

如果没有指定类型,默认为字符串。

<struct>s

参数值可以是<struct>。

每个<struct>包含若干<member>,每个<member>包含一个<name>和一个<value>.

如果所示为包含两个值的<struct>

<struct>

   <member>

      <name>lowerBound</name>

      <value><i4>18</i4></value>

      </member>

   <member>

      <name>upperBound</name>

      <value><i4>139</i4></value>

      </member>

   </struct>

<struct>是可以递归使用的,任何<value>都里还可以<struct>或其他任何类型,包括后面将要说明的<array>。

<array>s

值可以个<array>

一个<array>简单的有一个<data>元素。<data>可以是任何合法类型。

下面是一个有4个值的array:

<array>

   <data>

      <value><i4>12</i4></value>

      <value><string>Egypt</string></value>

      <value><boolean>0</boolean></value>

      <value><i4>-31</i4></value>

      </data>

   </array>

<array> elements do not have names.

<array> 元素没有名字。

你可以混合使用上面列出的几种类型。

<arrays>可以递归使用,其值可以是<array>或其他类型,包括上面说明的<strut>。

Response应答样式

下面是一个 XML-RPC请求:

HTTP/1.1 200 OK

Connection: close

Content-Length: 158

Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:08 GMT

Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?>

<methodResponse>

   <params>

      <param>

         <value><string>South Dakota</string></value>

         </param>

      </params>

   </methodResponse>

Respnse应答格式

除非底层操作出现错,否则总是返回200 OK.

Content-Type是text/xml。必须设置Content-Length,并且必须是正确的值。

应到内容是一个简单的XML,可是是<methodResponse>包含一个<params>,<params>包含一个<param>,<param>包含一个<value>。

<methodResponse>可能含有一个<fault>标签。<fault>的值为<struct>类型,<struct>有两个元素,值为<int>的<faultCode>和值为<string>的<faultString>。

<methodResponse>不能既有<fault>又有<params>。

Fault example

HTTP/1.1 200 OK

Connection: close

Content-Length: 426

Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:02 GMT

Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?>

<methodResponse>

   <fault>

      <value>

         <struct>

            <member>

               <name>faultCode</name>

               <value><int>4</int></value>

               </member>

            <member>

               <name>faultString</name>

               <value><string>Too many parameters.</string></value>

               </member>

            </struct>

         </value>

      </fault>

   </methodResponse>

Strategies/Goals

Firewalls. The goal of this protocol is to lay a compatible foundation across different environments, no new power is provided beyond the capabilities of the CGI interface. Firewall software can watch for POSTs whose Content-Type is text/xml.

Discoverability. We wanted a clean, extensible format that's very simple. It should be possible for an HTML coder to be able to look at a file containing an XML-RPC procedure call, understand what it's doing, and be able to modify it and have it work on the first or second try.

Easy to implement. We also wanted it to be an easy to implement protocol that could quickly be adapted to run in other environments or on other operating systems.

Updated 1/21/99 DW

The following questions came up on the UserLand discussion group as XML-RPC was being implemented in Python.

The Response Format section says "The body of the response is a single XML structure, a <methodResponse>, which can contain a single <params>..." This is confusing. Can we leave out the <params>?

No you cannot leave it out if the procedure executed successfully. There are only two options, either a response contains a <params> structure or it contains a <fault> structure. That's why we used the word "can" in that sentence.

Is "boolean" a distinct data type, or can boolean values be interchanged with integers (e.g. zero=false, non-zero=true)?

Yes, boolean is a distinct data type. Some languages/environments allow for an easy coercion from zero to false and one to true, but if you mean true, send a boolean type with the value true, so your intent can't possibly be misunderstood.

What is the legal syntax (and range) for integers? How to deal with leading zeros? Is a leading plus sign allowed? How to deal with whitespace?

An integer is a 32-bit signed number. You can include a plus or minus at the beginning of a string of numeric characters. Leading zeros are collapsed. Whitespace is not permitted. Just numeric characters preceeded by a plus or minus.

What is the legal syntax (and range) for floating point values (doubles)? How is the exponent represented? How to deal with whitespace? Can infinity and "not a number" be represented?

There is no representation for infinity or negative infinity or "not a number". At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified.

What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data?

Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.

Does the "struct" element keep the order of keys. Or in other words, is the struct "foo=1, bar=2" equivalent to "bar=2, foo=1" or not?

The struct element does not preserve the order of the keys. The two structs are equivalent.

Can the <fault> struct contain other members than <faultCode> and <faultString>? Is there a global list of faultCodes? (so they can be mapped to distinct exceptions for languages like Python and Java)?

A <fault> struct may not contain members other than those specified. This is true for all other structures. We believe the specification is flexible enough so that all reasonable data-transfer needs can be accomodated within the specified structures. If you believe strongly that this is not true, please post a message on the discussion group.

There is no global list of fault codes. It is up to the server implementer, or higher-level standards to specify fault codes.

What timezone should be assumed for the dateTime.iso8601 type? UTC? localtime?

Don't assume a timezone. It should be specified by the server in its documentation what assumptions it makes about timezones.

Additions

<base64> type. 1/21/99 DW.

Updated 6/30/03 DW

Removed "ASCII" from definition of string.

Changed copyright dates, below, to 1999-2003 from 1998-99.

Copyright and disclaimer

? Copyright 1998-2003 UserLand Software. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and these paragraphs are included on all such copies and derivative works.

This document may not be modified in any way, such as by removing the copyright notice or references to UserLand or other organizations. Further, while these copyright restrictions apply to the written XML-RPC specification, no claim of ownership is made by UserLand to the protocol it describes. Any party may, for commercial or non-commercial purposes, implement this protocol without royalty or license fee to UserLand. The limited permissions granted herein are perpetual and will not be revoked by UserLand or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and USERLAND DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 

 

 

添加评论

9:09  |  固定链接 | 引用通告 (0) | 记录它 | Open Source

 

 

固定链接  关闭

 

http://spaces.msn.com/lzhuacuo/blog/cns!18730E989D068035!506.entry

 

 

 

 

 

 

 

XML-RPC

 

XML-RPC

 

 

 

\

http://www.xmlrpc.com/

Java Technology and Web Services

http://java.sun.com/webservices/index.jsp

Web services are Web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients. Java 2 Platform, Enterprise Edition (J2EE) provides the APIs and tools you need to create and deploy interoperable Web services and clients.

Java Technology and Web Services is organized into these subcategories:

Java Web Services Developer Pack (Java WSDP)

Java API for XML-Based RPC (JAX-RPC)

Java API for XML Registries (JAXR)

Java API for XML Processing (JAXP)

Java Architecture for XML Binding (JAXB)

SOAP with Attachments API for Java (SAAJ)

XML and Web Services Security

Java API for XML-Based RPC >

http://java.sun.com/xml/downloads/jaxrpc.html#jaxrpcspec10

Java API for XML-Based RPC (JAX-RPC) Specification 2.0

 

 

 

添加评论

8:35  |  固定链接 | 引用通告 (0) | 记录它 | Open Source

 

记录一个好像还不错的uml模型到代码的code generator (AndroMDA

  一直知道ArgoUML在进行与androMDA的配套工作,昨天第一次上这个AndroMDA浏览了一下。好像还不错,以后可以实践一下。

  下面是它的定义:

What is AndroMDA?       

AndroMDA (pronounced "Andromeda") is an extensible generator framework that adheres to the Model Driven Architecture (MDA) paradigm. Models from UML tools will be transformed into deployable components for your favorite platform (J2EE, Spring, .NET). Unlike other MDA toolkits, AndroMDA comes with a host of ready-made cartridges that target today's development toolkits like Axis, jBPM, Struts, JSF, Spring and Hibernate. AndroMDA also contains a toolkit for building your own cartridges or customize existing ones - the meta cartridge. Using it, you can build a custom code generator using your favorite UML tool. 

  

Core Features       

AndroMDA currently comes with the following features:

Modular design: all major building blocks of AndroMDA are pluggable and can be exchanged to meet your needs

Support for major UML tools like MagicDraw, Poseidon, Enterprise Architect and more

Comes with the complete UML 1.4 metamodel (support for UML 2.0 is currently being developed) - alternatively, you can bring your own metamodel in MOF XMI and generate code from models based on it

Validates the input models using OCL constraints which are related to the metamodel classes. Comes with pre-configured constraints that protect you against the most common modeling mistakes - add your own project-specific constraints, too.

Model-to-model transformations help to raise abstraction level. Write your own transformations, currently in Java, or in any transformation language, e.g. the QVT-like Atlas Transformation Language (ATL), in the next major AndroMDA release.

Can generate any kind of text output using templates (source code, database scripts, web pages, O/R mapping configuration files, etc.) -  you teach it, AndroMDA does it!

Templates are based on well-known template engines. Currently, Velocity and FreeMarker are supported

Ready-to-use cartridges for common enterprise architectures (EJB, Spring, Hibernate, Struts, JSF, Axis, jBPM)

Support around the clock by team members around the globe: Measure the response time for questions in forum.andromda.org and be amazed by it! The forum already contains more than 10.000 articles.

 

  

Cartridges       

Very much like Eclipse, AndroMDA features a plug-in architecture. AndroMDA itself basically is a transformation engine. To support arbitrary target architectures, you can plug-in custom transformations. These transformations are packaged as so-called cartridges.

AndroMDA comes with a host of ready-to-use cartridges such as:

Spring

EJB 2 / 3

Webservices

Hibernate

Struts

JSF

Java

XSD

You can also write your own cartridge to support your own architecture or framework. AndroMDA can produce output for any architecture and computer language you might imagine. Courses for cartridge writing are available at AndroMDA.com.

 

 

 

一个关于w3c的非赢利组织www.w3china.org(中国万维网联盟)

  旗下有丰富的w3c相关的子站点,比如:有个xml.org.cn是专门讨论xml的,还有blog,翻译wiki,论坛等。记录在此备查。

  

关于中国万维网联盟(W3CHINA) 

2003-06-20: 中国万维网联盟(W3CHINA)是一个致力于研究、传播、讨论W3C标准的开放组织,成立于二零零三年六月二十日。作为一个开放组织,各界人士均可申请加入中国万维网联盟(W3CHINA)。中国万维网联盟(W3CHINA)旨在为Web应用开发者、研究者提供一个学习、研究、讨论W3C与Web技术的平台。我们欢迎各界人士的加入。

RSS 会否冲击网站流量(转帖)

(转自:http://in.comengo.net/archives/rss-usage-and-pv/)

RSS无庸置疑已经成为一个潮流,下面这篇blog讨论这个问题比较热烈,于是,保存在这里欣赏与思考,等有点心得也来评论两句。

×××××××××××××××××××××××××××××××××××××××××××××××××××××××××

RSS 会否冲击网站流量

RSS的流行对于国内的门户都是不小的冲击,因为大家都在考虑的一个问题是RSS是否会冲击PV?但毕竟RSS的普及还是不可逆转的趋势,所以新浪与搜狐还是陆续推出自己的RSS服务。

新浪与搜狐都没有公开表示过推出RSS服务后对网站流量的影响到底是正面的还是负面的(估计RSS用户的比例还太少,基本不构成什么影响),纽约时报倒是曾经公布RSS带来的流量比一年前大幅增长三倍多。Nielsen前两天发表的一份统计数据似乎也可以看出RSS对网络媒体的一些影响(via here)。

根据Nielsen的统计,RSS的订阅用户访问网站的次数是非RSS用户访问的次数的三到四倍,这似乎可以说明RSS订阅用户是网站最忠诚的一批用户,网站推出RSS服务有助于拉拢这些忠诚用户,而且RSS这种有效的信息推送与提醒方式可以更进一步促进他们访问网站的次数。尽管由于缺乏用户使用RSS前后的浏览行为变化的统计,无法确切了解RSS的作用,但RSS的应用至少是留住用户并提升忠诚度的一种好方式。

RSS用户不仅仅访问网站的次数增加,而且访问的网站数量也比非RSS用户多两倍,可见RSS的确是一种更加方便的获取信息的方式,可以提高我们的信息获取与处理的能力。(不过同样由于缺乏历史行为的比较,我们无法知道是否RSS用户在未使用RSS之前也浏览更多的网站)

Nielsen调查中另一个有趣的数据是,在RSS用户中有83%的用户并不知道自己在使用RSS服务,调查认为原因可能在于用户使用了My Yahoo这种不表现为RSS阅读器的工具。RSS这个橙红色的图标的确让很多普通用户迷惑,但如果能够有服务商像My Yahoo一样忽略RSS这种令人困惑的技术词汇,而将其包装成为用户更容易理解的个性新闻的方式,用RSS自动发现的技术让一个完全不理解RSS的用户都可以只通过输入想订阅的网站和Blog的网址等最简单的方式就可以方便地使用,这是否会极大地促进国内RSS用户的发展呢?毕竟用户不需要知道什么是RSS,他们要知道的只是你如何从他们的角度考虑为他们提供服务。

« 从2.0开始起步 - 简评新版Feedsky与UUzoneweb2.0与Web1.0的区别是什么? »

相关文章:Around the Web, RSS, portal;

Trackback:Trackback地址

本文写于 Wednesday, September 21st, 2005 21:51 您可以查看同类别Around the Web的其他文章,或者阅读与RSS, portal这些方面相关的其他文章。 您可以订阅本文的评论. 留言, 或trackback本文.

 

“RSS 会否冲击网站流量”有 15 条留言;

IUSR

September 21st, 2005 22:57 1“根据Nielsen的统计,RSS的订阅用户访问网站的次数是非RSS用户访问的次数的三到四倍,这似乎可以说明RSS订阅用户是网站最忠诚的一批用户”,这个我觉得不够准确,毕竟很多人用在线的或者桌面的聚合器订阅RSS时,大部分聚合器一般都去自动访问RSS,好像不好根据这个考证哪种用户的访问量更大一些。

Tangos

September 22nd, 2005 09:02 2统计的数据似乎考虑的是对网站的访问而非对网站RSS的访问,所以我觉得你考虑的因素应该不构成影响。

小朱子

September 22nd, 2005 13:49 3国外的经验并不代表中国国情,我觉得过分强调RSS反而会失败。中国人缺的不是效率,而是钞票。如果有样东西能解决后者,不用整天写文章,马上流行。

IUSR

September 22nd, 2005 13:54 4哦~也是:P

很好奇这个统计是怎么完成的呢?调查问卷还是自动完成?如果用客户端聚合器的话该怎么统计?

bslgw

September 22nd, 2005 16:06 5RSS是阅读习惯的改变。这片文章最关键的部分要看到

“在RSS用户中有83%的用户并不知道自己在使用RSS服务,调查认为原因可能在于用户使用了My Yahoo这种不表现为RSS阅读器的工具。”这才是真正的关键不要就单纯技术层面去讨论RSS

因为RSS没有什么技术含量

欢迎交流:msn:bslgw@0412.net

GTALK:bslgwpro@gmail.com

ocde

September 22nd, 2005 19:18 6我的切身体会告诉我是这样的,Rss让我更关注某网站,比如这里。首先一个人订阅了某网站,本身就证明他认为这个网站有价值。RSS能定时的通知我有新内容,他是个事件提醒,让我在本身有兴趣的同时更频繁的关注。当用RSS时,因为不能commment,浏览的不好看,我还是喜欢点击到网站上。但若我订阅的 RSS后续没有好东西,则我的关注将可能降低。

所以我认为:

1,RSS比PV对一个网站更有价值。RSS甚至就想是以前的用户注册样的价值,RSS的订阅量将在一定程度上反映一个网站的价值。

2,RSS也是读者的监督器,来督促网站做的更好的内容而不是形式。

黄靖昀

September 22nd, 2005 19:25 7PV的历史使命是与广告息息相关的,cookie在客户端对我们的阅读行为进行总结,再把相关数据返回到服务器端。这样一来,客户满意了,毕竟在衡量指标上,其随意性远较低于点击率和点进率,更好地反映了用户沾性。曾经在几年前看过一篇文章提到:PV是对传统广告到达率的一种革命。

在我看来,RSS的出现,一方面使得我的 JCM(及时知识管理)变得更加有条理了,我可以挑我自己喜欢吃的菜慢慢品尝,不必一定要看别人喜欢什么。久而久之,看了那么多订阅历史,我不免陶醉起来,呵呵,我也几个月的尝鲜了这么久。另一方面我也变得对下一次RSS推送的东西有所期待,那种感觉不是成就,恰似是初恋的男子,总想着自己女友那高挑的眉毛后面是否那样最神情的观望。他会失望的,如果下次你不冷不热,但他会给你机会,愿意留出时间让你忏悔。把所有的思绪猛然间断掉,难度几乎不可能。这就是RSS 的希望,只要不要太过分,在一见钟情上作好文章,不时哄哄读者。而web浏览就不然了,我看到那些大大的充满快感的富媒体,是的,我会喊的,但是喊出的是永远不来了。门户店大欺客,我拿你没招,但小店铺你也要开黑店,你就会永远见不着我了。

不管是从培养用户忠诚度还是从浏览行为上,PV都是没有前途的快要没落的概念。

1.推送给网站一大堆的数据,单是处理就不好办,好看而不实用。你不能从中了解看你的人是谁,IP记录是不够的。而rss环境下的统计,那是一个个泡你的人啊,认同你欣赏你(个人博客而言),为了更便利地了解咨讯(对新闻站点),为了更好地完成这一任务,他们才选择了RSS,也就是说他们是自愿的。

2。商业化方面,rss方式显然更有吸引力,从长期来说,你的读者杂质比较少,很吻合商家针对特定细分市场进行广告营销的需要,至于怎么套入广告,这个先不说。而PV思维造成了大量富余信息的堆砌,而实际真正需要的信息又无从寻觅。这或许就是搜索引擎能够起家的缘故吧

3。rss的交互远比单纯的 web阅读后提供了论坛啊,留言版更加人性化,那是一种真正的人性化交流。透过文章你灰认识一个人,他真实,没有被包装。这与网易商业报道的主编直评(http://biz.163.com/special/p/00021JLK/postzb_more.html)是不一样的,谁规定他的水平比我们高啊,这种故作的平民之舞还是少一点比较好。不知不觉中,商业影响了博客,也就影响了rss的那一端的读者。只是个中的微妙会是一门大学问

4。PV还会继续存续下去,很简单,我们还需要在读者输入你的网址,想看点什么的时候给他一个交代。读者的习惯也是一个问题,这问题因为门户的存在而加剧。商家的网络投放得看他们,他们主导了所谓的先发标准

letsgocn

September 22nd, 2005 19:56 8傻,也不想想中国菜鸟这么多,有几个会用RSS订阅啊?

keso

September 23rd, 2005 21:08 9昨日新闻 - RSS 会否冲击网站流量

根据Nielsen的统计,RSS的订阅用户访问网站的次数是非RSS用户访问的次数的三到四倍,这似乎可以说明RSS订阅用户是网站最忠诚的一批用户,网站推出RSS服务有助于拉拢这些忠诚用户,而且RSS…

hhm

September 24th, 2005 03:10 10学习学习

bolaa

September 25th, 2005 17:27 11呵呵,您的文章越来越有见地了!!我常在思考精彩的博客作品如何能够从海量信息中脱颖而出,被更多的人所知晓,能听到发自内心的喝彩声,而不会再被时间蒙上灰尘。并且在这个过程中能拥有越来越多志同道合的朋友,营造一个良好的沟通和交流的氛围。前几天我发现了一个不错的博客作品推荐和交流的好地方,博啦!BLOG互动平台www.bolaa.com,推荐您也去瞧瞧,让你的站点和作品人气更旺!

oii

September 29th, 2005 21:57 12seen

签名:My Blog

http://xiangtool.nease.net

Rss加油站 » 谁会是RSS在线阅读市场的赢家

October 9th, 2005 11:40 13[…] RSS显然是个过于技术化而难于推广的术语,已经有很多次的RSS调查数据(1、2)显示有不少实际在使用RSS进行阅读的用户并不知道RSS为何物,估计很大比例的这类用户来自于使用My Yahoo这种并非将自己定位为RSS阅读器的用户。多份RSS调查报告都显示公众对于RSS的认知程度还很低,如果他们连什么是RSS都不知道,怎么还会产生使用RSS阅读器的需求呢,通过重新定位和包装RSS阅读工具,让普通公众根本不需要去了解什么是RSS就可以享受RSS阅读的便利和好处,无疑会是吸引大量不了解RSS的普通用户的竞争关键。其实在这个领域,传统的门户网站似乎占据着竞争优势,比如Yahoo和MSN,国内的门户呢? […]

t2

November 9th, 2005 13:03 14kankan

17Vogue | 致力于珠宝品牌网络营销研究 » Blog Archive » 谁会是RSS在线阅读市场的赢家

December 6th, 2005 15:57 15[…]   RSS显然是个过于技术化而难于推广的术语,已经有很多次的RSS调查数据(1、2)显示有不少实际在使用RSS进行阅读的用户并不知道RSS为何物,估计很大比例的这类用户来自于使用My Yahoo这种并非将自己定位为RSS阅读器的用户。多份RSS调查报告都显示公众对于RSS的认知程度还很低,如果他们连什么是RSS都不知道,怎么还会产生使用RSS阅读器的需求呢,通过重新定位和包装RSS阅读工具,让普通公众根本不需要去了解什么是RSS就可以享受RSS阅读的便利和好处,无疑会是吸引大量不了解RSS的普通用户的竞争关键。其实在这个领域,传统的门户网站似乎占据着竞争优势,比如Yahoo和MSN,国内的门户呢? […]