Berkeley DB -- 补充一些东西
前面漏掉的一些东东。
腐烂数据的处理或者说数据库文件的瘦身：
当你从Btree或Hash数据库删除key/data对时，它并不把这个返回给文件系统，这使得数据重用成为可能。也就是说Btree和Hash数据库都是只增的。当你删除大量key/data对时，你可能想使数据库文件也缩减，你应该建立一个新的数据库文件，把记录从旧文件复制过去。应该是导入导出记录，而不是直接copy文件。
字节序的问题：
例如：数字254~257。在一个小数在前（little-endian）的系统上是：
254 fe 0 0 0
255 ff 0 0 0
256 0 1 0 0
257 1 1 0 0
如果你把他们当成字符串处理那么他们的排序是糟糕的:
256
257
254
255
在一个大数在前（big-endian）系统上是:
254 0 0 0 fe
255 0 0 0 ff
256 0 0 1 0
257 0 0 1 1
and so, if you treat them as strings they sort nicely. Which means, if you use steadily increasing integers as keys on a big-endian system Berkeley DB behaves well and you get compact trees, but on a little-endian system Berkeley DB produces much less compact trees. To avoid this problem, you may want to convert the keys to flat text or big-endian representations, or provide your own Btree comparison function.
前面漏掉的一些东东。
腐烂数据的处理或者说数据库文件的瘦身：
当你从Btree或Hash数据库删除key/data对时，它并不把这个返回给文件系统，这使得数据重用成为可能。也就是说Btree和Hash数据库都是只增的。当你删除大量key/data对时，你可能想使数据库文件也缩减，你应该建立一个新的数据库文件，把记录从旧文件复制过去。应该是导入导出记录，而不是直接copy文件。
字节序的问题：
例如：数字254~257。在一个小数在前（little-endian）的系统上是：
254 fe 0 0 0
255 ff 0 0 0
256 0 1 0 0
257 1 1 0 0
如果你把他们当成字符串处理那么他们的排序是糟糕的:
256
257
254
255
在一个大数在前（big-endian）系统上是:
254 0 0 0 fe
255 0 0 0 ff
256 0 0 1 0
257 0 0 1 1
and so, if you treat them as strings they sort nicely. Which means, if you use steadily increasing integers as keys on a big-endian system Berkeley DB behaves well and you get compact trees, but on a little-endian system Berkeley DB produces much less compact trees. To avoid this problem, you may want to convert the keys to flat text or big-endian representations, or provide your own Btree comparison function.
