比如多个数组，需要联合查询，自己写要做多个循环，比较，等等。
但是用SQL就一条语句，简单很多。
数据是不是在内存，和用不用SQL是两回事。
不明白为什么C/S才要用SQL，B/S不用SQL，用什么访问数据库？

ACoder说的没错。我认为内存数据库用于保存临时数据的原因是，数据在内存里不安全，不可能实时备份。而且内存数据库相对于传统数据库的最大优势是速度。

>>SQL又不支持OO。如果支持OO，那倒还可以考虑。
OO不是万能的,不支持OO就不考虑，是不是有点过了。

>>反过来说，进了内存，就不必再SQL了。
进了内存还要SQL的原因是可以保护原有投资，只需要把原有的临时数据表放到内存数据库，基本不用作大改动就可以提高性能。
这世界上不是所有系统都是OO的，为了提高性能就用OO重写老系统，有必要吗？

还是那句话，即使OO是非常好的，也不代表是万能的，可以打倒一切其他技术。

数据库本身就是OO的，他认为一切都是数据，如果你从业务分析的角度，一个数据库面对的对象不应该是数据么？？

1.什么时候我们的系统需要内存数据库支持。
//a. 原有DBMS性能不够，不满足需求了；b. 原有系统必须平滑地使用内存数据库，即不需要大的改动；c. 数据不是特别重要，即使丢失不会造成运行问题、用户投诉问题等. d. 数据量不会很大。
//我们的系统当时是用oracle，后面局方要求能支持更大的用户数，oracle成瓶颈了，所以考虑用内存数据库替换的方案；使用内存内存数据库对系统当然改动很小，只需要更改db url即可；我们的用户数据不是很重要，在运行过程中是经常更新的，而且在某种条件下还会自动清除；至于数据量，内存始终是比磁盘小，所以一般只将频繁访问的数据放在内存数据库。

2.如果我们项目需要内存数据库支持，我们需要自己设计内存数据库吗？还是有第三方开发的内存数据库，有哪些可用的内存数据库产品可用，最好是开源的。
//当然有开源的了，就看性能能不能满足你们应用的需求。我们当时研究了H2DB，它的多线程搞的很差，后来重写了这部分，性能确实要比oracle好。（目前还没有商用，只是做了模拟测试）

3.开发内存数据库难度大吗，如何开发，需要什么技术。大体步骤是什么？
//具有普通DBMS功能的内存数据库的开发难度应该很大，我们当时写H2DB的C驱动就弄了好久。其实还有一种似分布式缓存的"内存数据库"，数据实际上可以保存在HashMap中，client通过socket与之通信，我们另外一个系统也有用。

4.既然是内存数据库。那么数据都放在内存。。要是断电数据不丢了吗。如何保证数据不意外丢失。
//目前我们的数据不是很重要，所以没有考虑这个问题。

5.既然是数据库，那么如果如果无限存储的话，那对内存也就需要无限支持。是不是用内存数据库的系统一般数据量都有限呢。
//参考1的回答。

希望对LZ有用。