|
|
1
18
我不是CouchDB专家,但在做了一些研究之后,我发现了这一点。 简单的答案是,除非你有充分的理由不使用UUID。 答案越长,取决于: 更改ID的成本与更改ID的可能性 更改成本低,可能更改ID 这方面的一个例子可能是一个具有非规范化设计的博客,比如 jchris' blog ( sofa code available on git hub ) 每当其他网站链接到博客文章时,这是对ID的另一个引用,因此更改ID的成本会增加。 更改ID和永不更改的ID的成本很高 这方面的一个例子是任何使用自动增量ID的高度规范化的DB设计。stackoverflow.com是一个很好的例子,它的自动递增的问题ID可以在每个URL中看到。更改ID的成本非常高,因为每个外键都需要更新。 ID将有多少引用或“外键”(关系数据库语言)? 任何“外键”都会大大增加更改ID的成本。必须更新其他文档是一个缓慢的操作,绝对应该避免。 ID更改的可能性有多大? 如果您不想使用UUID,您可能已经知道要使用什么ID了。 如果它可能改变,那么改变ID的成本应该很低。如果不是,请选择其他ID。 你想要使用一个容易记住的ID的动机是什么? 不要说表演。 Benchmarks show “couchdb_s view key lookup几乎(但不是完全)和直接文档查找一样快”。这意味着必须搜索才能找到一个记录并不重要。不要因为可以直接查找文档而选择友好ID。 你会做很多批量插入吗? 如果是这样,最好使用增量UUID以获得更好的性能。 看看这个 post 关于大容量插入。达米安·卡茨评论说:
|
|
|
2
4
从关系数据库的角度来看,我花了一段时间才找到couchdb。但事实与接受的答案是相反的; 与使用默认UUID不同,生成智能ID可以极大地帮助您检索和排序数据。
http://guide.couchdb.org/draft/documents.html
https://pouchdb.com/2014/05/01/secondary-indexes-have-landed-in-pouchdb.html |
|
|
3
2
我知道这是一个答案很长的问题,但对于那些发现这个问题的人来说,还有另一个重要的考虑。当一个文档被删除时,你只知道它的ID。键入(
|
|
|
4
0
使用标识符 很多 在couchdb内部,任何额外的散列成本都会降低一堆内部的速度,所以最好还是使用所提供的uuid。 |
|
|
5
0
您可以使用默认的couchdb id(uuid),正如在 documentation 使用默认UUID的主要原因如下:
现在,另一方面,如果您依赖服务器(couchdb)来生成uuid,并且由于第一个post请求被弹出而最终发出两个post请求,那么您可能会生成两个文档,并且永远不会发现第一个文档,因为只有第二个文档会被报告,因此,最好生成您自己的uuid以确保U_秷秷永远不会出现重复的文档,但除非您特别需要,否则我绝对会使用UUID。 documenta . |
|
|
6
-1
数据库中的主键不应该有任何“意义”,除非可能对序列进行编码。您可能想更改slug,但不想更改主键。 有一个很好的理由可以使用以时间戳开始的东西来在您的键中具有固有的顺序。我经常使用“%f@%s”%(time(),hostname())获得有序的唯一密钥。(只有当time()实现从未两次返回相同的值时,这才有效。) 对于其他的东西(例如图像),我想避免重复的地方,我经常使用sha(数据)作为键。 |
|
|
developer · 带外键的SQL表设计 1 年前 |
|
|
relatively_random · 确保两个表之间一致的共同参考 1 年前 |
|
|
b126 · 在两种不同的Oracle模式上执行相同查询的速度差异很大 2 年前 |
|
|
robertspierre · 在多对多关系中自动删除未引用的行 2 年前 |
|
|
Michael Samuel · MYSQL在以下情况下自动创建索引 8 年前 |