本文深入探讨了IndexedDB中对象存储（Object Store）的创建与管理策略。针对在运行时动态添加对象存储的需求，文章阐明了createObjectStore方法只能在onupgradeneeded回调中执行的限制，并指出频繁修改数据库模式（Schema）的弊端。最终，提出了一种更健壮、推荐的数据分区方法：通过在数据对象内部添加分区属性，而非创建多个对象存储来实现数据隔离，从而保持数据库模式的稳定性。
理解IndexedDB的模式（Schema）管理
indexeddb是一个强大的客户端结构化数据存储方案，其核心在于“数据库”和“对象存储”（object store）的概念。对象存储类似于关系型数据库中的表，用于存放具体的数据记录。在使用indexeddb时，一个关键的生命周期事件是onupgradeneeded回调。
当以下两种情况发生时，onupgradeneeded事件会被触发：
数据库首次创建时。使用indexedDB.open()方法打开数据库时，传入的版本号高于当前数据库的现有版本号时。
onupgradeneeded回调是唯一允许对数据库模式进行修改的地方，例如创建、删除对象存储，或创建、删除索引。这意味着像db.createObjectStore()这样的操作，必须且只能在此回调函数内部执行。
动态添加对象存储的误区
在某些应用场景中，开发者可能希望根据运行时需求动态地创建新的对象存储，例如为了实现类似localStorage的命名空间隔离，为每个“分区”创建一个独立的存储。然而，这种做法通常会遇到以下问题：
createObjectStore的限制： 如前所述，db.createObjectStore()不能在onsuccess或其他运行时回调中被调用。尝试在非onupgradeneeded上下文中调用它会导致错误。频繁的版本升级： 为了触发onupgradeneeded来添加新的对象存储，每次都需要递增数据库的版本号。这意味着每次添加新的“分区”时，用户都需要经历一次数据库升级过程。这不仅增加了代码的复杂性，也可能导致不必要的性能开销和用户体验问题（例如，如果升级过程耗时，可能会阻塞主线程）。模式稳定性： 数据库模式（Schema）的设计应尽可能保持稳定。频繁的模式变更会增加维护难度，并可能引入潜在的兼容性问题。
因此，尝试通过编程方式在onsuccess中“强制”触发版本升级（例如，设想一个db.bumpVersion()方法）是不符合IndexedDB设计哲学的，也是不可行的。
推荐的数据分区策略：内部属性分区
鉴于IndexedDB对模式修改的严格限制以及对稳定模式的追求，推荐的做法是避免为每个逻辑分区创建独立的对象存储。相反，我们可以在一个或少数几个通用对象存储内部，通过在数据对象中添加一个特定的“分区键”或“类型”属性来实现数据的逻辑隔离。
实现原理：
单一或少量通用对象存储： 创建一个或几个设计良好的对象存储，例如一个名为’dataStore’的通用存储。
// 数据库首次创建或版本升级时openRequest.onupgradeneeded = (event) => { const db = event.target.result; if (!db.objectStoreNames.contains('dataStore')) { db.createObjectStore('dataStore', { keyPath: 'id' }); // 假设每个记录都有一个唯一的ID } // 如果需要，可以为分区键创建索引以优化查询 const store = db.transaction('dataStore', 'readwrite').objectStore('dataStore'); if (!store.indexNames.contains('partitionIndex')) { store.createIndex('partitionIndex', 'partitionKey', { unique: false }); }};
数据结构设计： 在每个要存储的数据对象中，添加一个用于标识其所属“分区”的属性。例如，如果模拟localStorage的storeName，可以将此作为partitionKey。
// 存储数据时async setItem(partitionKey, key, value) { const db = await this.#database; // 获取数据库实例 const transaction = db.transaction('dataStore', 'readwrite'); const store = transaction.objectStore('dataStore'); const data = { id: `${partitionKey}_${key}`, // 组合键作为唯一ID partitionKey: partitionKey, key: key, value: value }; await store.put(data); await transaction.done;}// 获取数据时async getItem(partitionKey, key) { const db = await this.#database; const transaction = db.transaction('dataStore', 'readonly'); const store = transaction.objectStore('dataStore'); const id = `${partitionKey}_${key}`; const data = await store.get(id); await transaction.done; return data ? data.value : null;}
查询与过滤： 当需要获取特定“分区”的数据时，可以通过遍历对象存储并根据partitionKey属性进行过滤，或者如果为partitionKey创建了索引，则可以直接使用索引进行高效查询。
// 获取某个分区的所有数据 (使用索引)async getAllItemsByPartition(partitionKey) { const db = await this.#database; const transaction = db.transaction('dataStore', 'readonly'); const store = transaction.objectStore('dataStore'); const index = store.index('partitionIndex'); const request = index.getAll(partitionKey); // 使用索引查询 return new Promise((resolve, reject) => { request.onsuccess = (event) => { resolve(event.target.result); }; request.onerror = (event) => { reject(event.target.error); }; });}
这种方法的优点在于：
模式稳定： 数据库模式一旦定义，就无需频繁更改。管理简化： 避免了管理多个对象存储的复杂性。性能优化： 通过为分区键创建索引，可以高效地查询特定分区的数据。
总结
IndexedDB的onupgradeneeded回调是进行数据库模式修改的唯一入口，而动态创建对象存储通常不是一个推荐的做法。为了实现数据分区或命名空间隔离，最佳实践是在一个或少数几个通用对象存储内部，通过在数据对象中引入一个“分区键”属性来逻辑地划分数据。这种方法不仅符合IndexedDB的设计哲学，还能确保数据库模式的稳定性，简化管理，并为数据查询提供灵活且高效的手段。在设计IndexedDB应用时，应优先考虑稳定且可扩展的数据模型，而非频繁地改变数据库的底层结构。
以上就是IndexedDB模式设计与数据分区策略：避免动态对象存储的陷阱的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1512393.html
微信扫一扫 
支付宝扫一扫 
