果30000元,则能够达到98%,假如你肯花30万元或更多,你能够拿到保真度99%的音箱,为了达到9%的提升,你需要跨越从300元到30万元如此大的跨度,值得吗?这个投入产出比是极其不合理的.
从软件产品本身来说,我想我们只能做到相对合理,做到当下最好,在合理的时间内把产品生产出来,而且还相对好用.假如你不这么做,而是为了把这个产品做到最好,你先花费了1年的时间搞语言,再花费1年的时间搞数据库,再花费1年的时间搞脚本...多少年过去了,你总算把产品搞出来了,但市场已经不需要了....- 干了大几十年之后,他磨出来的词语望远镜,比任何工业生产的望远镜的精度都高.
说到解决问题,有一个传说,老外有个生产线,需要在一个纸盒子里面放入某个产品,但由于数量太多,经常出现工人不小心,导致一些空盒子的产生,于是老板要求解决这个问题,花了几百万,用了许多高科技技术比如模糊控制什么的,成功将空盒率下降了很多.而同样的事发生在中国,中国的老板告诉包工头:这个问题不解决,你就给我走人!事实上,包工头不可能花几百万去解决这个问题,于是几个人想了一个办法,在生产线边上放了几台大功率风扇,使劲吹,没有放东西的盒子自然被吹翻了,奇迹了,这个空盒率也下降了,而且比老外的效果还好.... - 非常赞同楼主的意见.
工作时使用的学习方法和学生时代的学习方法是完全不一样的.
事实上,这也涉及到一个工作的目的问题:工作中要求你的是解决问题的能力,解决问题的能力与知识有些关系,但并非正比关系. - .1一份是抽象类(base),封装了一部分常规的操作如:加载/添加/修改/删除/列表等操作.此部分强制要求不允许任何人工修改.当数据结构有变化时,此部分内容全部覆盖.
2.2一份是继承类,继承上述抽象类,所有的新方法添加,均在此类上操作,数据结构变化时,一般此文件不覆盖.
按照上述做法,可以大大减少由于字段添加/更名/减少等变更带来的一系列修改问题.
一般数据表变更时,只需要将此部分的内容进行覆盖即可.少数页面上的变化,仍然需要添加或修改.但由于在model中定义了结构体的数据字段,如果服务端变化了,编译时也可以发现问题所在.... - 太棒了,这个工具可以解决实际工作中的很多需求:最简单的比如给客户演示或试用.
提两个建议:
1.能不能在本地设置好程序,然后把整个工具(内含网站代码)发给客户,由客户点击此工具的执行文件,即可直接浏览.也就是说,不需要用户在本地设置(虽然很简单,但有些用户根本不懂).
2.由于framework这个操蛋的环境,网站是一定需要环境才能跑起来,如果能够解决无环境也能够跑?
但最起码在工具里面可以允许内置离线的各版本framework的安装包,在缺乏运行环境的时候,不至于无法上网抓瞎(就能上网下载也很慢啊) - 不知道直接创建的效率是高于还是低于这个缓存搜索的效率?
从根本上讲,总体程序的运行效率于创建SqlParameter所受到的影响是微乎其微,即使创建再多,对整体性能的影响恐怕仍然属于万分之一甚至更小--但楼主这个想法还是值得肯定的.
只不过这种怀疑需要测试进行验证.
建议楼主,写一个简单的测试,一种是不断的创建若干个不同的SqlParameter[]对象,一种是创建之前先判断缓存中是否存在,运行个几千万次看看二者的性能会不会有所差异?
虽然我觉得最终的测试结果可能不会有大的差异,即使有差异,那也是在几千万次条件下达成的差异,但想像不如相见. - @双击
sqlserver有批量插入,ORACLE何尝没有呢?
这个不能说明问题.
事实上,这个测试说明了一个问题:
越是大型数据库,它的非事务性数据插入性能越高.因为,大多数的操作,都是作为一个一个的非事务性操作频繁进行的(即使该操作内部是事务性的).一次事务性操作性能高说明不了问题.
就比如说SQLite,不是每秒钟能够插入1万条吗?现在我不写入1万条,而是要分1万次,每次以事务的形式插入10条数据,这时候你说谁快? - 数据库的测试,受环境影响比较大,你的CPU/内存/优化/索引情况等都会引起性能的较大差异.之所以这样做测试,其实是做一个定性的分析.知道在这样的条件下,大致上各者之间的差别即可.没有必要深入下去--毕竟不是数据库专家.
- 前几天，苦恼于到底使用哪一种本地数据库来存储部分数据，于是决定做一个数据插入测试进行求证。 本地数据库接触不多，最早用过Access，但现在SQList功能更加强大--而且，说实在的我不喜欢Acce...
但这个appfabric问题也不少(当然优点也不少)
1.访问速度慢,与memcached/redis相比不在一个档次上.据我本机测试,redis每秒钟的写入速度达到6000次以上(一条一条写入),而读取则在1.5万以上(逐条读取);而appfabric,写入与读取速度,均在3000每秒以下(读写速度无区别).
上述测试,均在本机的虚拟机上跑,由本机访问虚拟机上的appfabric及redis
2.appfabric实现了多机联合缓存,号称可以节省不少内存.但事实上,如果要实现高可用性的话,就只能将数据通过key/value的形式存储到缓存中,如果需要实现区域(比如:将同一个表的内容存储在- 测试吧.大的数据量,如果通过网络来的话,时间都耗在网络传输上了,看不出什么名堂.
不过这个测试数据和我以往的测试情况大致相当,基本上,每秒钟能够插入5000条左右的数据.此次测试也没有多大的区别.唯一的区别,仅在于我把它写出来了.
另外说一下,上述的写入测试,是先在内存中循环10万次,先形成IList<T>对象,然后再以事务的形式循环提交给数据库的.并非拼SQL的形式写入.ORM呢,是本人自己写的.
楼上测试数据说一条17毫秒,估计是没有使用事务的情况下吧.... - 第一点,基本赞同,但有一点反对.
1、工作的第1-3年，基础知识积累，更多的是手熟。一定要去经历，经历很多的项目，经历不同的项目。使用不同的语言就更好了。
主要是:"使用不同的语言就更好了。".按我觉得,反而是"使用相同语言".
在第一个3年,你需要专心致志的把一个语言学习好,深入它,才能打造出一个良好的开端.什么都懂不如一个精通. - " + startIndex + " " + pageSize;
return sql;
}
如上（临时手写，仅示意），你只要安心写SQL，不要管它是不是需要分页，当需要分页时，把你写的SQL用上述方法操作一次，即可返回正确的分页SQL，方便。... - 这种公司，不可能有存在的必要。
马上走人！！立即！！！ - 我也是，看不到图片。
还以为我的浏览器有问题了。 - 下载了，恢复了数据库，但仍然无法运行。
操作系统：windows7 x64。
点击执行文件，稍等一会儿，提示“。。。已停止工作”，将其兼容性设置为xp,以管理员运行，仍然出错。 - 招聘人员很花费时间和脑筋.
我是比较赞成上机试的，一方面是有些人理论很强，但动手能力确很弱；一方面是有些人动手能力很强，但理论不行。同时，上机试并非目的，而是在机试的过程中，发现每个从的优点。
另外，机试可以迅速淘汰部分各方面都不行的人员，免得面试人员浪费时间。就像楼上说的：“面试是个问题，对双方都是个考验，我们公司前后得经过6-7轮面试，其中两轮技术面试，招个人折腾两个月，悲催……”， - 而尊重他人的办法，就是在写代码的时候，把自己写的每一个代码的意图讲清楚，让他人查看的时候，能够以最快速的时间理解清楚（因为你是中国人，理解中文比理解英文快一万倍。不要以为写了英文代码自己就跻身老外阶层了），节省他人的宝贵时间。同理，他人如此做，也就节省了你自己的宝贵时间。
同时，写代码也是给自己看的。做项目，必然需要进行后期维护。如果没有详细清楚的注释，一个项目半年后、一年后进行维护，不管是谁写的，主要的流程业务什么的，还是记得住的；但没有任何一个人可以保证，具体的代码书写意图还能够记得清清楚楚、宛如昨天。即使有注释，也会经常在某个方法上思考：咦？当时为什么要这样写？更不用说没有注释的情况了。 - 这个是怎么说?
什么叫做不支持命名空间?好像没有这个问题啊?
定义XML长度?是哪个地方?没有见到过哪里有限定XML长度的. - 关键是思想.楼主的这个设计很好.而且,关键是WCF这方面的架构,可用的很少,大部分都是讲述一些具体的技术.
- 者没有差别。那么，不管并发多少次，并不会发生本质变化。因为，不管多少次并发，它总是要初始化stringbuiler或者不断的在内存中覆盖string,因为它们之间不是累加的关系。
就好比如：马在100米范围内加速比普通的汽车快，但长距离就比不上了。假如十万人都来重复试验这个结果，那将得出相同的结论－－它并不会因为很多的人（并发）各自的测试会有所变化。当然，假如这十万人都找同一匹马和同一辆汽车并且连续的跑的话，那么肯定是汽车比马快了。... - ，做工精良，品质优秀，但即使是这样，它的毛利润，也超过了50%；相同的情况下，汉王产品的品质能够相比吗？功能能够相比吗？
都是急功近利惹的祸。
在市场稀缺的时候，拼命抬高价格，妄想着多捞一把是一把，而不是借助缺乏竞争的市场下，把利润让一部分给用户，迅速扩大产量降低成本占有市场；等到强大的竞争者到来之时，因为上上下下缺乏竞争的意识，没有足够的风险抵抗手段，行动迟缓，头破血流的时候才想起如何反击。。。。。。已经迟了。
实际的来说，功能最多品质最好的电纸书产品，顶多就是1000元左右，最好低于此金额以下才有市场。用户不是傻瓜，市场不是依靠一小部分人送送礼品就能够支撑起来的。... - 百号上千号人员的名称和脸孔对应起来就够呛。
后来在我的强制要求下，设计改为楼主所说的组合式。当然，该同事对我是满腹牢骚，认为我水平低下，一点都没有面向对象编程的思想。... - 就是由于缓存的丢失，会丢失小部分的统计数字，不过用户访问量，并不需要太准确的数字，因此此手法还算合适。
-------------------
事实上，缓存是有过期事件的。
你可以把这部分的缓存，设立一个过期事件，平常的时候，正常进行计算点击数量，一旦该缓存被清除时，即触发该事件，在事件中，将所有的数据写到数据库中。
如此，就不存在统计数据的丢失问题。
事件的实现类似上面“ 深蓝医生”的示例。 - 常规来说，服务端控件，只要不是存放在GridView/DataList、自定义控件（ascx)、母版页里面，它的客户端ID与服务端ID就是一样的。
不管是哪个版本的VS。
楼主以前可能是忽略了，你可以试试看。 - 速度慢的问题，...”
事实上，我从来没有否定存储过程比普通的SQL查询更快，你可以仔细看我上面的说明。
我否定的只是，不要只看到存储过程执行速度更快而不加思索的在任何场景之下大量使用，不同的场景，需要做不同的应用，访问量低的网站，使用存储过程是一个很合理的作法；然而访问量高的网站则变得不合理了。
每秒250个的数据库操作请求，确实轻而易举，我曾经在我笔记本上测试，1秒钟甚至可以向ORACLE数据库插入4000条的数据。但假如这个存储过程在内部必须做一定的运算呢？事实上，存储过程一般是需要做运算的（否则我们拿它来做什么？不如直接SQL算了）... - 把结果写到数据库中去。因为数据库中不再执行计算而只是进行存储，速度大幅提升（不是简单的几倍，而是上百倍）。
当然，这样做的前提是，浪费了一台应用服务器在干这个事；而且，用户提交的数据，不是直接提交到数据库中，而是先通过网络提交到应用服务器，应用服务器计算后再提交到数据库中存储－－浪费了多少的网络带宽啊！！！但相对于解放了数据库服务器来说，这一台应用服务器以算得了什么？不就几万块钱吗？...
