>>C/S方式访问数据库，才需要SQL。既然已经放到内存里来了，还需要啥子SQL哟。这不是脱裤子放屁嘛？还不仅仅是多此一举，应该是自找麻烦。
比如多个数组，需要联合查询，自己写要做多个循环，比较，等等。
但是用SQL就一条语句，简单很多。
数据是不是在内存，和用不用SQL是两回事。
不明白为什么C/S才要用SQL，B/S不用SQL，用什么访问数据库？
>>usejava说的不对，内存数据库并不是仅仅为了保存一个临时数据而准备的，他在使用上就像正常的数据库一样，从使用者的角度上如果不告诉你使用的是什么数据库，两者给你的感觉是一样的。内存数据库本身也包括了备份、故障转移等功能，这些问题跟正常数据库一般无二。
ACoder说的没错。我认为内存数据库用于保存临时数据的原因是，数据在内存里不安全，不可能实时备份。而且内存数据库相对于传统数据库的最大优势是速度。
>>>比如多个数组，需要联合查询，自己写要做多个循环，比较，等等。
>>>但是用SQL就一条语句，简单很多。
>>>数据是不是在内存，和用不用SQL是两回事。
>>>不明白为什么C/S才要用SQL，B/S不用SQL，用什么访问数据库？
用SQL检索数据，效率是很低的。因为它对于C/S与rDBMS有特殊的效用，付出这代价是划算的。现在放进内存里了，这需求就没有了，我们不脱裤子就可以放屁了。
SQL又不支持OO。如果支持OO，那倒还可以考虑。
B/S，其实也是C/S，确切地说，是Web形式的C/S。只要是C/S模式，只有是关系型数据库，就离不开SQL。反过来说，进了内存，就不必再SQL了。
>>用SQL检索数据，效率是很低的。因为它对于C/S与rDBMS有特殊的效用，付出这代价是划算的。
不明白特殊效用指什么。说SQL效率低，我不是很赞同，至少目前没有更好的方案来替代SQL和RDBMS。
>>SQL又不支持OO。如果支持OO，那倒还可以考虑。
OO不是万能的,不支持OO就不考虑，是不是有点过了。
>>反过来说，进了内存，就不必再SQL了。
进了内存还要SQL的原因是可以保护原有投资，只需要把原有的临时数据表放到内存数据库，基本不用作大改动就可以提高性能。
这世界上不是所有系统都是OO的，为了提高性能就用OO重写老系统，有必要吗？
还是那句话，即使OO是非常好的，也不代表是万能的，可以打倒一切其他技术。
SQL的内存效率低于直接查找我不知道你怎样得出这样结论的。
首先不是每个人都能写出最优的查询算法的，使用遍历的方式的时间复杂度是最高的，必须使用二分法等方式进行查询，第二个数据库的存储并不是一条记录一个段内存的存储，之所以叫关系型数据库是因为使用了数学上的原理，通过映射等一些方式的组合出的结果。第三数据库可以通过牺牲空间来设定索引，通过索引可以直接找到相应的记录。
数据库本身就是OO的，他认为一切都是数据，如果你从业务分析的角度，一个数据库面对的对象不应该是数据么？？
你认为用Java编码去访问数组很麻烦，可机器因你的付出而轻松。
你用SQL很轻松，可机器却因你的潇洒而费了大劲了。
用汇编语言或机器语言写代码，你最费力，可机器最轻松。
用C语言写代码，你轻松不少，可机器也费劲不少。
用其它高级语言写，轻松更多，机器也费劲更多。
用SQL写，可机器最辛苦了。
数据库采用B+树等技术和索引提高性能，算法很复杂。你用java简单查询数组恐怕还没有用SQL性能好。当然你也可以采用复杂算法来提高性能，但是这等于又设计了一个数据库，只不过不采用SQL。
我同意用汇编写的代码执行效率高，但是开发费用你考虑过没有，花更少的钱换台好机器，性能恐怕更好。而且高级语言写的程序可读性和维护性更好。
机器辛苦是正常的，怕机器辛苦干脆人来干好了，还要计算机干什么。
SQL语言是比高级语言更高级的语言。一般高级语言是面向过程的，就是你自己得拿出办法来，并编码把这做法代码化。SQL是面向问题的，你只需把问题提出来。
说的很对，所以SQL才能够有如此广泛应用。编码简单易懂，这也是我们采用高级语言编程的原因，也是各种语言提供大量库或者包供我们调用的原因。
前段时间做过，以实际例子回答你的问题。
1.什么时候我们的系统需要内存数据库支持。
//a. 原有DBMS性能不够，不满足需求了；b. 原有系统必须平滑地使用内存数据库，即不需要大的改动；c. 数据不是特别重要，即使丢失不会造成运行问题、用户投诉问题等. d. 数据量不会很大。
//我们的系统当时是用oracle，后面局方要求能支持更大的用户数，oracle成瓶颈了，所以考虑用内存数据库替换的方案；使用内存内存数据库对系统当然改动很小，只需要更改db url即可；我们的用户数据不是很重要，在运行过程中是经常更新的，而且在某种条件下还会自动清除；至于数据量，内存始终是比磁盘小，所以一般只将频繁访问的数据放在内存数据库。
2.如果我们项目需要内存数据库支持，我们需要自己设计内存数据库吗？还是有第三方开发的内存数据库，有哪些可用的内存数据库产品可用，最好是开源的。
//当然有开源的了，就看性能能不能满足你们应用的需求。我们当时研究了H2DB，它的多线程搞的很差，后来重写了这部分，性能确实要比oracle好。（目前还没有商用，只是做了模拟测试）
3.开发内存数据库难度大吗，如何开发，需要什么技术。大体步骤是什么？
//具有普通DBMS功能的内存数据库的开发难度应该很大，我们当时写H2DB的C驱动就弄了好久。其实还有一种似分布式缓存的"内存数据库"，数据实际上可以保存在HashMap中，client通过socket与之通信，我们另外一个系统也有用。
4.既然是内存数据库。那么数据都放在内存。。要是断电数据不丢了吗。如何保证数据不意外丢失。
//目前我们的数据不是很重要，所以没有考虑这个问题。
5.既然是数据库，那么如果如果无限存储的话，那对内存也就需要无限支持。是不是用内存数据库的系统一般数据量都有限呢。
//参考1的回答。
希望对LZ有用。
1 内存数据库和传统关系型数据库比较起来，它的响应更快，并发更高，处理事务的能力更强。我测试过Oracle的TimesTen，在PC机上，Oracle每秒大概处理2000多个事务，而TimesTen可以处理2万多个。所以在实时系统，有大量并发的系统中可以使用内存数据库，比如呼叫中心，花费实时通知，证券系统等。
2 内存数据库可以持久化，所以不存在断电数据丢失的问题。而且内存数据库也有完备的备份，HA方案。
3 TimesTen是关系型内存数据库，我记得ExtremeDB是对象型内存数据库，这两个都是收费的，比较贵！当然也有很多开源的，但是开源的功能上不完善。
4 内存数据库比较耗内存，但现在内存很便宜，据说通信行业有用250G内存来存储数据
1）对于大数据量
现在固体硬盘发展很快，容量上升与价格下降都可以用“飞快”来形容。这个不需要新技术。
2）对于小数据量
干脆不用数据库，都放在内存里，内部电池备用。我的导航仪就是这样。
我现在内存DB用得很局限，就开发时候用它建临时DB，希望能了解更多方面的用途。
楼上说的导航仪我不太懂，印象是它后面有更大的可靠的卫星备份在撑着，而且好像不需要写入数据。
内存数据库能不能做好集群我也很想知道。
感觉memcache那种方式把一切都扔进map里也应该算内存db，但是不支持传统sql，一切用key操控，当然也没有那么多统计函数可用。我们有一部分数据是用这种方式管理的，但是这些数据都是可以安全重建的，不需要备份。