JYun

因为要将客户机的ACCESS数据库中的刷卡记录导入SQL中,ACCESS的数据库采用的是目录共享方式共享的,但是包执行几次都错误,了解到是SQLAGENT的帐户问题,因此解决方法如下:

客户机加入域的情况:
 在SQL-SERVER服务器上，在服务中将SQLANGENT服务的登录帐户，设置为域管理员帐户，同时该帐户要能够登录客户机，这样包执行就正确。

客户机没有加入域而且是Win98:
 在SQL-SERVER服务器上，在服务中将SQLANGENT服务的登录帐户，设置为本地管理员或系统帐户，在WIN98的机器上建立一个SYSTEM的帐户，密码为空，这样包就可以正确执行了。

　　David Heinemeier Hansson 受雇与 37 Signal ，但是仍然可以自己选择建立自己的 Rails 框架来完成项目，他应该算是个"主动程序员"。Firebird 数据库的领导者同时也是 Interbase 数据库的创始人 Jim Starkey 将自己的公司卖给了 Mysql AB 而不得不给 Mysql 干活，从某方面说，他应该是个"被动程序员"。大多数第三世界国家的程序员应该属于"被动程序员"，他们编程只是为了一份养家糊口的工作，他们无权选择自 己喜欢的编程语言或者框架，因为这是公司给他选择的，因为如果选了其他，他可能就找不到工作了。曾经有个即将离职的同事让我给他推荐一个比较好的编程框 架，可以很容易完成一个网站的制作，我给他推荐了 Zope, 还有 Rails, 他听我的介绍觉得不错 ，当我告诉他必须学习 python 和 Ruby 编程语言时，他显得很惊愕，"那能找到工作吗?"。这话其实也表达了大多数国内程序员的想法。看看招聘网站就知道，现在最需要的程序员是 Java 程序员，最需要了解的框架是 Struts。如果不会你很难得到面试的机会，所以就算你不会也要在自己的简历中"修饰"一下。

　 　有些自己创业的人可以自己选择喜欢的编程语言和框架，当然那毕竟是少数。如果我能够选择的话，我肯定不用 Java 来做网站应用。因为它完成一个简单的工作太麻烦了，很难快速适应需求的变化。当然我也不会去用 PHP ，因为我已经习惯了面向对象的编程方式了。 我发现一个奇怪的现象:大多数转向学习 Ruby on rails 框架的人都是来自 Java 阵营的程序员，而转向Python 框架Zope，django 的程序员大多有 ASP,PHP 背景。因为 Ruby 是一个真正的面向对象的语言， 它同时具备了脚本语言的特点，而 Python 首先是一个脚本语言，它具备了一些 OO 的特征。Java 程序员 很难忍受走回头路，所以他们选择了一个比Java更面向对象的语言 Ruby ，而PHP,ASP程序员没有那么重的思想负担，他们选择 Python 可能是因为它的代码更 Beauty ，远比他们以前写的"意大利面条"式的PHP,ASP 代码要干净的多。

　　无论是 python, 还是 Ruby 这些非主流程序语言开发的框架，使用起来都异常的简便，他们可谓是真正从程序员角度考虑的框架。为什么 Ruby 一出，搅的 Java 的世界一片混乱，我想原因还是出在 Java 这里，当 Java 程序员想当然地认为程序开发应该如此麻烦的时候，Rails 的出现让他们立刻觉得被这些所谓的 Java 流行框架和 Sun 给欺骗了，这种欺骗是如此之深，以至于他们中间有的人"头也不回"的离开了 Java, 转而攻击 Java 的种种不是。这其中比较有名的人就是 Bruce Tate ，这位老兄写了两本轰动 Java 世界的书，Spring: A Developer's Notebook 和 Better, Faster, Lighter Java (该书可是获得 Jolt 大奖的，恰好我还都读过)，随着 Rails 的流行，这位仁兄立刻叛逃出 Java 阵营，写了 Beyond Java 一书，着重介绍了一些非Java 框架，比如 Smalltalk 的Seaside, 和 Rails。

　　Java 为什么这么复杂，我想了很久，得出这么个结论:这是因为 Sun 希望它那么复杂。为什么这么说呢?Sun 不是一个好的软件公司，它最擅长做的是制定规范，这很类似Java 编程中的 Interface, 经常编写 Java 程序的人，会发现 Interface 可能是出现最多的一个词汇了，任何框架中都充满了Interface —接口，大多数编程书都推荐面向接口编程(当然这不是Java的错，是设计模式要求的，不过 Java 将此发挥的最好)。首先定义接口，然后针对接口编写不同的实现，至少提供默认的实现。Sun 也是如此，看看 J2ee 的规范包含了多少 J 打头的技术， JDBC,JNI,JCA,JDO,JPA .... ，现在的 JCP 组织更加如此，每隔一段时间，就有大量的规范问世，Draft 的，还是 Final 的，充斥着Java 世界，这是 Sun 希望的， 每定义一个规范，就会有很多厂商来实现它，Java 的软件市场就做大了，这样 Sun 就可以靠授权，认证拿更多的钱，你看 Sun 的股票那么低迷，而却拥有那么雄厚的流动资金，原因再明白不过了，只要 Sun 还拥有 Java ，它就拥有了一切。

　　Sun 希望 Java 变得复杂，就如同程序员希望 Perl 代码难看一样，这样做是可以带来好处的。Java 的复杂性也带来了产业链上其他行业的繁荣，比如咨询，在 Php ，Perl 流行 Internet 的年代，网站开发似乎还不需要咨询师，包括 C/S 盛行的时候，企业开发也不需要咨询师，然而随着 J2EE 逐步主宰企业级开发，咨询行业也开始兴旺起来。企业大把大把的把钱投入到开发咨询中，究竟效果如何，不得而知。我想对大多数程序员，尤其是那些有自己想法 的程序员来说，请求咨询公司，还不如自己去了解来得清楚。软件开发咨询师在我看来，有点象是"律师"—"代表贪婪的公司，让这个世界变得更糟糕一些"(中 Alex 的对白)。如果说国外的咨询师是希望通过主观的努力来解决客观存在的开发复杂性的话，那么国内的咨询行业可能把原本复杂的软件开发变得更加复杂了。我不相 信他们，我宁可选择某个软件的培训，而不希望有人来从头到尾指点你如何开发，因为国内咨询师的水平比你从书本上了解的高不到哪里去，公司又何必花费这笔冤 枉钱呢。

　　那么如果你是个"主动程序员"，你会跟着 Sun 的指挥棒走吗? 我想离开 Java 世界，你选择的机会应该很多，但是前提是:你愿不愿意离开 Java 。因为大多数人觉得改变现状其实并不是个好事情，学习一个新语言和框架意为着你过去所有的经验就消失了，这其中有风险。对大多数程序员 来说，编程其实就是份工作，跟卖盒饭，装机器没什么区别，只要搞好本职工作就可以。试图改变现状的人很痛苦，了解差异的人也是如此，就如同 Neo 在接受红药丸和蓝药丸。

　　我在当年学习 Perl 的时候曾经买过一本《Learning perl》，书的作者曾经这么说，学习 Perl 是为了让自己把更多的时间用在去滑雪， PHP 的创始人 Rasmus Lerdorf 也曾经这样表示过，他希望自己能够减少盯着电脑的时间，可是这么多年过去了，他发现自己还是要继续盯着该死的电脑。其实我对选择框架语言也并没什么兴趣， 我只是希望能够以简单的方式完成工作，而把时间省下来去听听音乐，看看电影。实际上我跟不希望改变现状的人没什么不同，他们不希望学习新的东西，因为现有 的东西很熟悉了，学习新框架，还不如把时间放到玩上去，我的目的一样，我学习只是希望自己的工作更轻松一点，这样可以用更多的时间来玩。所以每当我看到各 种技术论坛上充斥着Java, .net , ROR ，Python 之类的争吵，我都觉得很好笑。其实为了维护一个语言而争吵最没有意义。编程语言就和英语，计算机一样，就是个工具，选择它们只是为了尽可能简单地完成工 作，提高生活质量。为了语言而语言，为了框架而框架都是没必要的。"主动程序员"可以选择自己的方式来工作，这是大多数人做不到的。如果有可能，我也希望 做一个"主动程序员"。

原贴 http://www.cnblogs.com/Barton131420/archive/2007/01/07/613955.html
园子里有些人，他们真以为自己明白了面向对象，然后装着满腹经纶，侃侃而谈，一篇接一篇，不厌其烦地喊着ORM如何如何。你以为他真的明白“面向对象”么？其实，他对面向对象的理解仅限于教科书中的封装、继承和多态，或者再知道一点面向对象的若干原则但其实并不真正理解。
笔者愚钝，入行多年尚不懂面向对象，只懂得用其形而不懂用其实。五年后的某一天终于开窍，明白了面向对象之实，也仅仅是一个开始而已。当又经历了另一个五年的倦怠，发现并理解了设计模式、面向方面等技术作为面向对象的必要补充后，才算是彻悟！所以当我见过一个同学，尚未出校门已然彻悟，真是羞愧！
有一天面试的时候，我问一位同学，Framework和Library的区别是什么？他答不上来。而另一个同学略一思考就告诉我，你的程序会调用Library，而Framework会调用你的程序。虽然精辟，但我还是要补充：Framework通常也会提供一个Library，所以，Library是水平的，而Framework是垂直的，此处的“水平”和“垂直”是相对应用系统的层次设计而言的。如果没有层次，其实Framework其实就是Library。Microsoft的Enterprise Library当然就是一个Library，无法代替Framework。
如果让那位已经彻悟的同学舍弃ORM来实现复杂的业务功能，他当然无法接受。相反，如果让一位抱着《Thinking in Java》似懂非懂的同学用ORM来实现同样的功能，他也一样无法接受。其中的一些同学非常擅于“鸡蛋里挑骨头”，于是园子里有了这样一堆垃圾文章或者垃圾跟贴。另外一些同学不精于这样的能力，所以仍在徬徨之中。

此乃ORM惟一之硬伤也！如果你不理解面向对象思想，就先试着去理解，然后再来讨论ORM这个话题，并发表你的高见。

再说性能
ORM提供了所有SQL语句的生成，代码人员远离了数据库概念。从一个概念需求(例如一个HQL)映射为一个SQL语句，并不需要什么代价，连1%的性能损失都没有。真正的性能损失在映射过程中，更具体地讲，是在对象实例化的过程中。我曾经做过一个试验，以“计算第N个素数”这样的命题。我采用Delphi写Native Win32 Console程序，又采用C#写CLR Console程序。两者相比，令我大失所望。

N	结果	耗时
		Delphi	C#
1000	7927	0ms	2ms
10000	104743	16ms	17ms
100000	1299721	438ms	324ms
1000000	15485867	11437ms	7823ms

该命题采用的算法是找出第N个素数以前的所有素数，开辟一个内存区存贮这些素数。在Delphi中我用链表，在C#中我用List<int>。实际的结论是：当列表足够大时，链表的性能远不及List<int>。当然，如果每个链表节点只装一个元素，这种差异会更明显。事实上，我测试过每个链表节点所装的元素个数做了一个阶梯试验，从30个、254个、510个、1022个到2046个，每个节点所装载的元素数越多，耗时越短，最终越来越接近C#的List<int>。
不知道各位是否已经明白了性能在哪儿损失了：内存分配。Native的内存分配与释放都是非常耗时的操作系统行为。但在托管环境下，内存的释放是GC干的事情，甚至不需要统计到耗时中，而内存的分配也是一件非常快捷的事情。当然，即使是快捷也还是需要耗时的。这让我联想到DataSet的性能。DataSet也是一种数据容器，但是却没有多少人抱怨DataSet的性能。如果你明白DataSet的机制，就会发现，DataStorage巧妙地规避了内存分配和耗时的问题。而我们的ORM无法解决每个对象实例在构造时分配内存所耗时间。我做了一个不精确的评估，相比DataSet，对象集合的性能损失大约占20%左右。
如果假定ORM并没有比传统的数据访问方式耗费额外的IO的话，除此之外，ORM再没有任何性能损失！
再回到前提条件：ORM并没有比传统的数据访问方式耗费额外的IO。这个条件成立么？
“由于ORM的实体对象定义已经固定，所以即使我不需要某些字段，也一样需要加载这些字段。”
OK，有的同学已经看出来了。额外定义一个视图的实体对象即可。定义这些视图的实体对象的确很麻烦，但是肯定比构造那些SQL并不断地维护它简单得多。
“当一张表中有1000万行数据时，实例化1000万个对象是不可能的。”
非常正确。难道你曾经成功地尝试过将1000万行数据加载到某个DataTable中并且没有性能问题？从应用的角度来说，在一个模型中包含的实例数超过500行就有设计不当的嫌疑。我对Google的抱怨是：当搜索结果超过1000个时都会令我抓狂。让我从1000行数据中找出我所需要的某一行，这是开发人员的思维，并不是用户的思维。如果能够在已有的结果中进行二次、三次或者多次进一步的筛选，可能更适合绝大多数人。我为什么不愿意在分页中花太多的精力，其原因也是如此。我认为用户的眼球只能接受100行以内的数据，超过这个行数就需要采用其它的方式，或者改善领域设计。所以，这个问题的答案是：你不可能需要一次载入1000万行。
“当应用系统整体性能欠佳时，因为隐藏了数据访问细节，从而无法找到快速优化的途径。”
不能同意。几乎每一个ORM框架都提供了非常可靠的数据库访问日志。通过这些日志分析性能损失将比直接使用SQL语句更可靠、更方便。

灵活性
ORM不够灵活？我完全不能理解，我甚至不知道这个不够灵活是与什么基准相比。相反，ORM可以让你灵活地替换数据库(当然这个优点并没有非常重要的意义)；在修改数据库以后不需要修改服务层或者只需要进行简单的修改；可以对某个服务进行单独的测试；可以对服务进行不依赖数据库的、上下文一级的扩展；可以进行更好的层次设计；......
不能实现所有的查询条件
如果是想表达“每一个Select语句可以通过面向对象的方式进行查询”的话，我觉得目前绝大部分ORM框架都已经很好地解决。我解决这一问题的基础是：我不提供超越SQL ANSI92的能力，但覆盖SQL ANSI92的所有功能。对于解决实际应用中的不足部分，采用运行时算法补充。Hibernate采用的是HQL这样的方式，基本上SQL能够做到的，HQL都无一例外可以做到。ECO采用的是OCL的方式，其功能可以完全覆盖SQL。我的框架所实现的查询目前我还没有发现无法解决并必须利用Native SQL来实现的(因此我无法理解Hibernate3为什么要提供这样的扩展)。Hibernate采用的策略是以面向对象为核心，换句话说，以持久化对象为终极目标，而以加载对象以持久化对象为前提。设计一个POJO，实例化，然后保存起来，下次使用的时候可以依样载入即可。大规模的查询并不是框架的核心目标。所以，如果你完全依赖Hibernate去持久化，我非常担心你将来是否有机会用你的数据积累去做数据仓库。而我的框架目标则不同。在持久化与加载两个目标间我没有主次之分。我也没有超前到MDA，我的对象模型仍然基于数据库的ER设计，我仍然提供一组非常清晰明了的数据库视图。
多表连接查询
如果需要将多表的连接查询结果转换成一个二维视图，显然需要你再定义另一个视图实体对象，将视图映射到对象模型。如果你仅仅是要在一个对象实例的某个属性中获得另外一个对象的集合，似乎这不是DAL方式的优势，而反而是ORM的优势。将多个对象所依赖的多个对象放到同一个上下文中，显然这是最好的一种方式。
统计查询
从理论上讲，ORM不适合做OLAP，不适合做太多统计查询。其实这一点，我的框架已经提供了非常好的解决方案，对Aggregate到面向对象的视图处理得非常好。

开发效率
提高开发效率仅仅是一个抽象的目标，具体的手段应该是两个方面：一是IDE和辅助工具；一是适合将任务分解成多个解耦的部分从而可以通过增加人员来提升总的开发效率。虽然ORM仅仅是开发环节中很小的一部分，但是却遍布应用系统中的每一角落，因而对开发效率影响较大。除了ORM，难道还有更好的选择么？
ORM后，原来精湛的SQL技能变得毫无用武之地，让人甚是失落，但这并不是ORM的过错。

本文链接地址：http://blog.csdn.net/thefirstwind/archive/2006/12/13/1440965.aspx

标题：程序员学习的革命，教你如何使用大脑
作者：邢晓宁
时间：2006年12月13日
声明：版权没有，随你任转

很多人搞技术，还有很多转行搞技术，搞了一段时间终于发现，自己不适合作技术，又退了回去。要我说其实就是用脑方式的问题，真的学会适当的用脑方式，编程编起来才得心应手，才能找到编程的快乐。

有时候，我们问到很多高手详细的技术问题，他们马上用程序给你实现出来，而且运行无误，这应该是左脑高手。左脑：是作抽象化符号处理的。

而另外一些高手，我们问他们请教设计方案的时候，简单的在纸上勾勒几笔，大致的设计方案图就呈现出来，之后的check，他多半不看你程序，只让你给他讲讲大框儿便能发现问题。这样的的应该是右脑高手，右脑：形象化分类处理，我公司以前的老板是技术出身，每次检查我的程序的时候，都要让我给他讲程序，他从来不看我的代码。人家讲话，你的程序在我这里要明来了才算通过，连你自己都想不通，那就别上手，想明白了再说。

当然，左脑和右脑结合是最好的方式，但是现代人对右脑的应用没有得到很好的开发，人刚生出来的时候就最开始发育的是右脑，之后的3年中主要也是使用右脑，然后才是逐渐德在右脑和左脑架起一个沟通的桥梁，扶助左脑的建立，随后左脑逐步的完善。随着学校的教育，左脑的使用频率越来越高，比例上成年的使用左脑远远大于右脑。但是值得注意的是，右脑的信息存储容量是左脑的100万倍，如果得不到很好的右脑利用，那么岂不是浪费了很大的资源。

另外，论坛上，有人调查过，编码人员每天要有多少代码量，剩下的时间在干什么？平均是150行左右，当然干外包的要多一点。不过，星星多的，基本每天编程的时间不超过工作时间的20%，剩下的时间在思考，或者说这些时间在大脑里面勾勒出来程序的图，也就是常说的画脑图。看来很多大牛，在用脑上，右脑的使用还是高于左脑的。

对于画脑图这个概念，又叫做思维导图、心智地图，心像图，心智图，Mind Map，Mind mapping, 可以视之为一个树状图或分类图。不要一行行地作记录，而是画脑图。用树状结构和图像再辅以颜色、符号、类型和关联来画脑图。脑图法，是由托尼·布赞发明的一种方法。在他杰出的新著《脑图之书—发散性思维》(TheMindMapBook—RadiantThinking)里，有对这种方法很好的介绍。

顺便说一句，编程中什么语言好，这是个历来已久的话题，也没有必要去深究。入门打好编程基础以一本常用语言做实现手段（一般都选C语言，当然不绝对），干活的时候，用到什么语言，拿起编程手册马上就能干，这就可以。可是，问题是，很多语言的编程思想不太一样，有些精髓还是要稍微理解以下的。这里要注意的是，不要把重心放在各种语法上，技术的核心其实是技术思想，如果建立了成型的技术思想，即使上忘记各种语法，事后稍微温习一下也很快就能上手。但是，如果不明白技术思想的话，根本不知道如何上手去干活。所以说，学编程，还首先要学编程思想，技术思想，多画脑图。

记得大学毕业设计的时候，用powerbuilder开发，当时就用了三个月，相比较几万行的代码来说，家里更多是堆积如山的设计图纸，当时根本不懂得什么这个图那个图，也没有个设计标准，脑子里面想什么就画出来什么。短短三个月，最后被评为校优秀毕业设计，还不错，小吹一下。因为那个毕竟是我入门的第一大笔，终身受益。

其实，有些时候，我们在程序设计之前，做的各种图，用利图，框架图，流程图，系统功能图，等等等，无非也就是脑图的各种形式，只不过是不同时期的不同的形式而已。（可能理解得不太深入，别喷我）

对于国人来说，技术始终不是问题，更重要的是设计思想，好的设计决定项目的生命周期，好的设计决定代码人员的劳动强度，决定后期维护的费用。而这个好的设计来源就是大脑中对项目大致的勾勒，这几笔简单的勾勒，可不是谁都能画好的。

在这里就是想说说无论是编程还是其他工作，以及平时的学习，画一张张好而有效的脑图是多末重要啊。

那么如何画脑图，以下介绍两种方式：

（一）托尼．巴赞的脑图规则

1，首先在纸的中心画一个彩图，这个彩图往往胜过千言万语，明确主题，并且刺激创意性思维，同时会强化记忆。

2，多用图画

（二）另一样式：台湾高美士中葡中学校长梁佑澄的脑图的方法及法则

1．工具方面, 只要可画图之纸张(一般A4或B4纸) 及方便使用之颜色笔即可; 若你懂得用计算机, 这也是一种极方便的工具。

2．一开始就把主题摆在中央。向外扩张分枝, 近中央的分枝较粗, 相关的主题可用箭头号连结。在纸的中央，从主题开始—最好用一个符号，然后画出从主题上

分散出来的分支。如果你将纽约市进行脑图呈现，就将自由女神像作为中心。如果你在悉尼，就用港口大桥作为中心点。如果是本书中关于大脑的那个章节，就画一个由两部分组成的大脑。

3．使用「关键词」表达各分枝的内容---- 脑图目的是要把握事实的精粹, 方便记忆, 所以不要把完整的句子写在分枝上。

4．将相关的内容放到同一分支上，每一内容如新的亚分支那样分散开来。使用符号、颜色、文字、图画和其它形象表达内容。图象愈生动活泼愈好。

5．建立自己的风格 --- 脑图并不是艺术品, 所绘画的能助你记忆, 才是最有意义的事。

6．你完成每一分支后，用不同色彩的框将其框上。

7．重画能使「脑图」更简洁, 有助于长期记忆 --- 同一主题可多画几次, 不会花很多时间, 但你很快会把这主题牢牢的记住。

8．有规律地将内容补充到每一张图上。这样，就很容易从概要开始，然后当你在每一学科中学到更多要点时，不断使脑图更加丰富、充实。

最后，这是一个简单的脑图例子，大家可以看看。

另外再转一个实例：

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1236675