IndexedDB 和多对多关系
你们都是如何处理 IndexedDB 中的多对多关系的?
例如,假设我有一个 Blog
对象来保存博客文章,还有一个 Tag
对象来保存博客文章的标签/标签。一个Blog
可以有多个Tag
,一个Tag
可以被多个Blog
使用。
我会创建一个 blog store
和 tag store
(尽管我愿意接受建议)来容纳两种类型的对象:
// ...
var blogStore = db.createObjectStore("blog", {keyPath: "blogId", autoIncrement: true});
blogStore.createIndex("title", "title", {unique: true});
var tagStore = db.createObjectStore("tag", {keyPath: "tagId", autoIncrement: true});
tagStore.createIndex("label", "label", {unique: true});
我可以立即想到两种链接方式两者:
- 有一个
Blog.tags
,它是一个包含blogId
和tagId
的BlogTag
对象数组(并且也可以在商店中检索)或 - 有
Blog.tags
是一个tagId
数组,可用于查找Tag
。
第一种方法看起来比较冗长,但是这是在 SQL 中解决这个问题的方法。这只是我应该留下的 SQL 包袱吗?
我想第三种方法是让 Blog.tags
成为 Tag
的数组。这看起来很简单,但我无法查询 Tag
或跨博客重复使用标签(或者我可以吗?)。
有其他人用indexedDB处理过这种情况吗?如果是这样,你最后做了什么?有哪些陷阱?
How are you all handling many-to-many relationships in IndexedDB?
For example, say I have a Blog
object to hold a blog post and a Tag
object for a tag/label of the blog post. One Blog
can have many Tag
s and one Tag
can be used by many Blog
s.
I would create a blog store
and tag store
(though I'm open to suggestions) to house the two types of objects:
// ...
var blogStore = db.createObjectStore("blog", {keyPath: "blogId", autoIncrement: true});
blogStore.createIndex("title", "title", {unique: true});
var tagStore = db.createObjectStore("tag", {keyPath: "tagId", autoIncrement: true});
tagStore.createIndex("label", "label", {unique: true});
Off hand I can think of two ways to link the two:
- have a
Blog.tags
which would be an array ofBlogTag
objects which holdsblogId
andtagId
(and would also be in the store for retrieval) or - have a
Blog.tags
which would be an array oftagId
s that could be used to look up theTag
s.
The first way seems longer-winded but is how this would be tackled in SQL. Is that just SQL-baggage that I should leave behind?
I suppose a 3rd way would be to have Blog.tags
be an array of Tag
s. This seems simplest but then I couldn't query for Tag
s or reuse tags across blogs (or could I?).
Has anyone else handled such a situation with indexedDB? If so, what did you end up doing? What were some pitfalls?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我正在开发 IndexedDB 支持的 JS 神经网络实现 并面临着这个问题
问题。
我们在 IndexedDB 中没有联接,因此您至少要查看两个对象存储命中,除非您正在进行某种记忆/缓存。
根据经验,我发现面向文档的样式最适合 IndexedDB 对象(将所有内容存储在同一存储中),但需要辅助存储来容纳关系。
这就是我正在做的事情。
假设您想拥有一个演员和电影的本地商店——类似于 IMDB。这种关系以及大多数多对多关系都可以使用 IndexedDB 使用两个表进行建模:对象和关系。
这是两个表。您希望对几乎所有内容进行关键查找*。任何没有说独特的东西都可能是非独特的。
对象对象存储:
关系对象存储:
演员/电影示例将是对象表中的两条记录和关系表中的一条记录:
用于获取 Michael Cera 的电影的伪代码:
用于获取给定年份的所有电影的伪代码:
Psuedo -用于获取电影演员的代码:
用于获取所有演员的伪代码:
I'm working on an IndexedDB-backed JS neural network implementation and faced this very
problem.
We don't have joins in IndexedDB so you're looking at at least two object store hits unless you're doing some sort of memoization/caching.
From experience I've found that a document-oriented style is best with IndexedDB objects (store everything in the same store), but a secondary store is needed to house relations.
Here's what I'm doing.
Say you want to have a local store of actors and movies -- something like IMDB. This and most any many-to-many relationship can be modeled with IndexedDB using two tables: Objects and Relationships.
Here are the two tables. You'd want key lookups* on almost everything. Anything that doesn't say unique can be non-unique.
Objects object store:
Relationships object store:
An actor/movie example would be two records in the Objects table and one in the relationship table:
Psuedo-code for getting Michael Cera's movies:
Psuedo-code for getting all movies from a given year:
Psuedo-code for getting a movie's actors:
Psuedo-code for getting all actors: