两个领域完全不一样,包括关注点,技术,运营等..我总结了一下:
1. 企业应用有很多功能属于增删改查的类型.有的是单表操作,有的是多表的JOIN,有的可能需要些逻辑判断,但大致的基本思路是这样,一个企业应用大约逃离不出这些结构.游戏不同.没有增删改查,没有任何的模式套路!做企业应用的思路和做游戏的思路完全不同.我们部门曾经单独为游戏的后台做了机器人脚本,能自动创建对游戏的表的管理功能,而游戏的后台管理功能大体与企业应用类似,这样想来可能企业应用还是有套路可循的.
2.二者的关注点不同.企业应用关注的是功能能否实现,模块,代码写的是否秀雅,当然游戏的开发也肯定关注这个,但游戏更要关注:性能,画面和可玩性…性能包括游戏的响应速度,能否支撑玩家的巨大的并发量 等.画面也非常重要,一个好的游戏能让人有赏心悦目的感觉.同样可玩性也要挖掘出来.要让玩家玩的爽,有能从中盈利,难度比较高呢…
3.代码编写的方式不同.企业应用的思路大多可以想到.比如页面列表显示,无法是取数据,然后转换成一个VIEW在页面上显示出来.而游戏呢,逻辑性之复杂令人瞠目.这里不多说了.可能一个简单的功能,需要上千行代码…还有一系列的算法等等,同时还要考虑到编写代码后游戏的运行速度和性能…
4.做企业应用很多人习惯用模型的方式设计数据库,比如一个表代码一个对象等.这样会产生可能一个查询有涉及到5张表之多.游戏呢?一个月就会有50万条记录,如何JOIN?JOIN一次要让你必须在1秒内响应,并且线上还有1000个玩家在玩,你能行吗?不行!尽量少JOIN表,这是提高数据库效率的一个非常好的方法.
5.多用缓存.不多说了,优势是:1减少访问数据库的时间和数据库的压力 2.提高请求响应速度.等等…
还有很多…呵呵
来点批判啊。。。版主人呢？
企业应用不是这么简单。来自于几个方面的复杂性。
一、如何抽象企业从事的业务领域（可能涉及哲学或世界观的思考），用合适的领域模型来表达。这就涉及到企业的业务相对游戏来讲具有更大的可变型。系统如何支撑，企业战略或业务模式的变化。这是极大的挑战，不能是因为软件系统的重构，停止业务的运行。
二、即使一个中型企业、业务系统也是非常多的，错综复杂的关系，一个是刚上线可能就可能已经是一个Legacy系统，系统的集成和处理历史遗留系统，这是游戏不需要面对的。
三、认为企业应用的逻辑简单、无非是数据的CRUD操作，这是有失偏颇的。现实的业务的不确定性远高于游戏的不确定性。而企业应用就在用软件或代码表达现实业务， 实现世界或业务的非正常流程远多于游戏，如何处理这些“异常”需要深入的思考和平衡。
四、作为企业应用，一个业务操作后面可能是上是十个乃至几十个系统在做服务，所以数据库访问压力、缓存、相应速度、操作的协调，业务操作的RollBack等都是异常复杂，对架构师来讲是极具挑战性的。对架构是瞻前顾后的平衡能力远高于游戏的架构师面临的挑战。可以这样说，游戏开发面临的挑战是点上的，企业应用开发面临的挑战是面上的。
还有更多方面，值得探讨，先说到这里
伟哥，怎么样？我们老大的评语有道理不？
1. 企业应用不是简单的CRUD。
2. 企业应用关注于正确性，可扩展性等，而有戏非常关注于用户体验。企业应用也有关注于性能的地方。
3. 业务模型和存储模型并不总是一样的，有些情况下一次join要比N次不带join的查询要好
很懂很李解,很好很强大.
还是思考和解决问题的领域不同.企业应用更关注的是对一个企业的战略,业务的抽象,以完美的形式提供对企业策略,效率的支持.
前几天看了京东的CEO访谈,深有感触.京东为什么卖的东西比市场低很多?他们难道不赚钱吗?因为他们背后有极其优秀的系统在帮助他们,使得京东能计算出用户的购物偏好,订单周转率,知道用户买了这个产品后下一个可能会买什么,这个产品会有多少人会买,需要进多少货才足够…等等.希望强哥团队能开发这样的系统,这样才真正能称得上一个优秀的企业应用.
企业应用PK游戏应用,只是领域不同而已,真正要做到尖端,复杂度二者不可衡量…
一个月就会有50万条记录 , 其实这样的查询，还是不应该采用join
join是一种很不好的习惯，只能应用于小数据量的情况
通过程序进行任务的分解和结果集的合并，只做单表查询，数据库的速度还是比较不错的。
看到很多人都提到不要用join，我想join影响伸缩性，是原因之一。为了提高速度，往往到后期，很多网站都选择了数据库分割，这样同一张表里的数据可能被分到不同的表了，同一物理机器上的数据也可能被分到不同的物理机器上，这样，原先的join要么不能运行，要么运行极慢，所以为了以后数据库伸缩性考虑，而不采用join，是可以理解的。
@imlsq
我回复你的评论了，嘻嘻。
@all
测试一下，大家因该收到邮件了
不知道现在篱笆的系统是都是集成的？还是分散为各个小系统？呵呵
感觉从一个大方向来说，集成是一个必然的趋势，当然这也带来了系统的复杂度，但是从整体考虑还是值得的。用友软件多棒？皆因于他带来了企业的整体解决方案。
集成的一个重要的考虑点是系统的性能，一个整体的系统能否承受大的数据访问。
我有同事在快钱，为了解决系统性能的问题，也是通过拆系统，拆表的方式实现的，感觉这样的方式不是很好。
一个企业应用，解决多系统的整合问题也是必要的吧。。
做企业应用，我觉得大部分的开发的驱动力都是来源于业务需求和成本，集成也不例外，没有为了集成而集成的。为了满足新的业务需求，或者为了以更少的成本来支持现有的业务，我们才将孤立的应用集成起来。至于性能等问题，到目前为止并非整个系统的最重要的地方。如果目前的性能能满足业务需要，我们没有太大的动力去做集成的。至于你说的拆系统拆表，这更多的是设计上的问题，而性能也只是设计时要考虑的一个因素而已，还有很多的因素需要考虑，比如我们的硬件环境，遗留系统的状况，对不同应用的稳定性可靠性要求，开发人员的分配和配合等等。我觉得你的眼界得放宽些，不能总是只盯在性能上。
有道理，大概老是做系统对性能上一直很偏执，呵呵。这点是不正确的。
企业应用很深好奥妙