Question

有许多可用的键值存储。目前你需要选择一个并坚持下去。我相信一个独立的开放式API，不是由键值存储供应商制作的，它会使商店之间的切换变得更加容易。

因此，我正在构建一个数据存储区抽象层（如ODBC，但专注于更简单的键值存储），以便有人构建一次应用程序，并在必要时更改键值存储。这个API太简单了吗？

get(Key)
set(Key, Value)
exists(Key)
delete(Key)

由于到目前为止我看到的所有API似乎都添加了很多，我想知道还需要多少其他方法？

我收到一些回复说set（null）可用于删除项目，如果get返回null，则表示项目不存在。这有两个原因。首先，混合返回类型和状态是不好的，其次，并非所有语言都具有null的概念。参见：

我确实希望能够对数据执行多种类型的操作，但据我所知，一切都可以在键值存储之上构建。它是否正确？我应该提供这些增值功能吗？例如：像mapreduce或索引

在内部，我们已经在Erlang和Ruby中拥有了这个基本版本，它为我们节省了大量时间，并且还使我们能够测试不同键值存储的特定用例的性能

Answer 1

只做绝对必要的事情，而不是问它是否过于简单，要问它是否过多，即使它只有一种方法。

Answer 2

如果你所做的只是获取，设置和删除键，这很好。

Answer 3

您的API缺少一些有用的功能，例如“hasKey”和“clear”。你可能想看看Python的骇客，http://docs.python.org/tutorial/datastructures.html#dictionaries，然后选择其他函数。

每个人都在说，“简单就是好”，直到“简单太简单”才真实。

Answer 4

API没有“太简单”的东西。越简越好！如果它按原样解决了需要，那就离开吧。

Answer 5

delete方法是不必要的。您只需将null传递给set。

编辑添加：

我只是在开玩笑！我会保留删除，并可能添加Count，Contains，也许还有一个枚举器（或两个）。

Answer 6

我完全是为了简化界面，但没有关于系统的要求的更多细节，很难判断这个界面是否足够。当然看起来很简洁。

不要忘记记录“密钥不存在”的语义，因为通过阅读上面的API定义并不清楚。 已更新：我发现您添加了exists方法：这是必要的吗？您可以使用get方法并定义某种NIL，不是吗？

也许值得考虑：如何考虑价值的“新鲜度”？即相关的“最后修改”时间戳？当然，这取决于您的系统要求。

访问控制怎么样？它是否在API定义的范围内？

通过密钥迭代怎么样？如果有可能存在大集合，则可能需要包含一些分页语义。

Answer 7

创建API时，您需要问问自己，我的API为用户提供了什么。如果您的API过于简单，以至于您的客户可以更快，更轻松地编写自己的应用，那么您的API就会失败。问问自己，我的功能是否给他们带来了特定的好处如果答案是否定的，则过于简单和通用。

Answer 8

如上所述，越简单越好，但可以使用简单的迭代器或键列表方法。我总是需要遍历集合。如果没有由迭代器处理，那么也是一个“size（）”方法。但这显然取决于你的使用情况。

Answer 9

这不是太简单，它很漂亮。如果“exists（key）”只是“get（Key）！= null”的便捷简写，你应该考虑删除它。我想这取决于你得到的值（）的大小或复杂程度。