and*_*yuk 27 database-design couchdb
我们都知道,对于关系数据库,最好使用数字ID作为主键.
在couchdb中,生成的默认ID是UUID.最好是坚持使用默认值,还是使用用户在应用程序中使用的易于识别的标识符？
例如,如果您在couchdb中设计stackoverflow.com数据库,您是否会使用问题slug(例如,what-is-best-practice-when-creating-document-ids-in-couchdb)或每个文档的UUID ？
and*_*yuk 18
我不是沙发专家,但在做了一点研究后,这就是我发现的.
简单的答案是,使用UUID,除非你有充分的理由不这样做.
答案越长,取决于:
更改ID V的成本ID更改的可能性
更改成本低且可能更改ID
这方面的一个例子可能是具有非规范化设计的博客,例如jchris的博客(git hub上提供的沙发代码).
每当另一个网站链接到博客帖子时,这是对id的另一个引用,因此更改id的成本会增加.
更改ID和永远不会更改的ID的高成本
这方面的一个例子是任何使用自动增量ID进行高度规范化的数据库设计.Stackoverflow.com是一个很好的例子,它可以在每个URL中看到自动递增的问题ID.由于每个外键都需要更新,因此更改ID的成本非常高.
id会有多少引用或"外键"(关系数据库语言)？
任何"外键"都会大大增加更改ID的成本.必须更新其他文档是一个缓慢的操作,绝对应该避免.
ID有多大可能改变？
如果您不想使用UUID,您可能已经知道要使用的ID.
如果可能发生变化,更改ID的成本应该很低.如果不是,请选择其他ID.
想要使用容易记忆的ID的动机是什么？
不要说表现.
基准测试显示 "CouchDB的视图键查找几乎,但不完全,与直接文档查找一样快".这意味着必须进行搜索才能找到记录并不是什么大问题.不要仅仅因为您可以直接查找文档而选择友好ID.
你会做很多批量插入吗？
如果是这样,最好使用增量UUID以获得更好的性能.
查看有关批量插入的帖子.Damien Katz评论并说:
"如果你想拥有最快的插入时间,你应该给出_id的升序值,所以得到一个UUID并将其递增1,这样它总是插入索引中的相同位置,并且一旦你是处理大于RAM的文件.为了更容易地做同样的事情,只需按顺序对文件进行编号,然后使用填充使其固定长度,以便它们正确排序,例如"0000001"而不是"1".
从关系数据库的角度来看，我花了一些时间弄清了couchdb。但是事实与接受答案相反。
代替使用默认的uuid，生成智能ID可以极大地帮助您检索和排序数据。
假设您有一个数据库电影。所有文档都可以在URL / movies下的某个位置找到，但是究竟在哪里？
如果将带有_id Jabberwocky（{“ _id”：“ Jabberwocky”}）的文档存储到电影数据库中，则该文档将在URL / movies / Jabberwocky下可用。因此，如果将GET请求发送到/ movies / Jabberwocky，则将取回构成文档的JSON（{“ _id”：“ Jabberwocky”}）。
http://guide.couchdb.org/draft/documents.html
性能提示：如果您只是使用随机生成的文档ID，那么您不仅会错失获得免费索引的机会，而且还会增加建立索引的开销，而这些索引永远都不会使用。因此，请使用并滥用您的文档ID！
https://pouchdb.com/2014/05/01/secondary-indexes-have-landed-in-pouchdb.html