我想将SQLite用作保存到磁盘的关联数组。
这是个好主意吗？我担心每次执行以下操作时都必须解析SQL：
数据库[“someindex”] ，必须翻译成类似
的内容从db中选择值，其中index ='someindex'，而这又必须转换为SQL内部语言。
答案 0 :(得分：5)
如果您担心SQL开销并且只需要一个简单的关联数组，那么像GDBM或Berkeley DB这样的dbm可能是个不错的选择吗？
答案 1 :(得分：1)
查看sqlite参数以获得变量的简单方法＆lt; - ＆gt; SQL
答案 2 :(得分：1)
SQLite应该像基于磁盘的关联数组一样快。请记住使用prepared statements，它会解析并编译一次SQL以便多次调用;他们对SQL injection attacks也更安全。如果你这样做，你应该从SQLite中获得相当不错的性能。
对于简单的基于磁盘的关联数组，另一种选择是文件系统;这是一个非常流行的基于磁盘的关联数组。在文件系统上创建一个目录，每个条目使用一个密钥。如果您需要超过几百个，那么每个字符的两个字符前缀创建一个目录，以保持每个目录的文件数量相当小。如果您的密钥不像文件名那样安全，那么使用SHA-1或SHA-256或其他东西对它们进行哈希处理。
答案 3 :(得分：0)
这实际上取决于你的实际问题。您的问题陈述非常通用，并且高度依赖于散列表的大小。
对于小哈希表，一旦你可能真的更喜欢文本文件（方便调试），你只打算读写。
如果您的哈希表小于25美元，那么SQLite可能会很适合您