fsong :
…erlang产品还有秘密吗,估计产品很容易被逆向工程出来吧,这恰恰不符合”工业标准”,呵呵~~乱弹一番…

真的是“乱弹一番”，～此言差亦。

如果说“工业标准”和“程序员数量”或者“应用规模”、“教学语言”之类的因素挂上钩，那还算靠点谱。但如果认为“工业标准”和“逆向工程”之类的因素相关，那么，我个人实在无法认同。

作为“工业标准”的 C (包括ASM)的程序被反向工程的例子实在太多，已经举不胜举。就算是“相对独立的软硬件一体化系统”，比如 iPhone 和 XBox 360 之类，还不是一样被破掉了么？只是多费了一些时间而已。

这个世界上从来就没有过密不透风的墙(将来恐怕也不会有)。有差别的只是突破这堵墙所花的代价会有多高，是否合算而已。只要是被认为具有“破解的价值”，那么无论采用什么技术来做，区别其实不大。以此作为“工业标准”的考量因素，又是从何说起？

虽如此，但在“反逆向工程”上 Erlang 还是有经过精心设计的源代码保护机制，你可以对外发布加密过调试信息的字节码(RSA)(对此，本站另有文章介绍，感兴趣请自行搜索)。虽说这个机制并不一定意味着彻底避免被逆向工程，但无疑是增加了难度——至少不会出现“装个软件源代码就全部被还原”的尴尬情况。单就这一点而言，已经比同样是 ByteCode 的 Java 和 .NET 要强上很多了。

话又说回来，对于我们程序员而言，如果程序真的达到“极具破解价值”的水准，那又何尝不是一种荣誉。

但，在另一方面，对很多 “头一次听说 Erlang 的人” 来说，这个 mnesia 又是被当作 “Erlang 内置的一个数据库” 来介绍的。所以，在他们在探索和学习的路上，必然地发现这个 4G 限制的时候，自然也会产生想象与现实的 “落差” 感。

要解决这种落差，要么是再明确地提供一个真正意义上的 DataBase ，比如说，象 CounchDB 这样的东西。要么是在介绍 mnesia 的时候，就在更显著的地方明确的指出它和数据库之间的差异，提供清晰的信息，以供作出判断。

对于前者，我觉得必要性其实并不高，相反地，像这篇文章中 mnesia unlimit 的做法，我觉得是可取的。因为 mnesia 的 api 设计得相当精巧，尤其是它 qlc 的部分，非常符合 FP 的习惯风格。我在这篇文章后面的 blah 中也提到，某种意义上，不妨将 mnesia 看作是一个类似于 ODBC/JDO/Hibernate 这样的 api 层面的东西。具体要怎样去接驳后端的存储实现，是 DETS/ETS ，又或者是 Memcached/Tokoyo Carbinet，提供选项，让你照自己的喜欢去配置就好。实际上 mnesia 本身在代码之中就留有替换 “存储实现” 的空间(比如，在 ETS 和 DETS 之间选择“存储实现”)，因而这并非不可能完成的任务。Joel Reymont 就是通过 Hack mnesia 自身的代码(其实只能算是少量的 Hack)来做到这一点。倒是 mnesia team 应该考虑如何增加可配置的 API，让这些扩展变得更加容易。

local_content table 需要自己对数据进行分区
fragmented table 用起来则实在是有那么一点…… tricky…

问题是——凭什么啊？作为使用者，选择一个存储机制，当然是希望它越透明越好，如若不然，自然就会考虑其他的选择，比如，自己去架个 couchdb/kai/scalaris 来用。而这些项目的蓬勃发展，正好证明了 mnesia 的这个限制是多么的让人不爽。对于这个问题 otp team 确实需要加以重视，并好好的解决一下。

对于 Erlang 来说，如果只是存储和读取(不做分隔和解析的话)字符集问题其实并无大碍，因为对于 mnesia 来说它存的只是一个 list 它原样存，原样取，在外面你想怎么用就怎么用，爱怎么转换就怎么转换(这就好比，在 java 里面，用 gbk 的 mysql 一样可以处理 utf-8 的字符串)。并无妨碍。