本文探讨了在IndexedDB中动态添加对象存储（Object Store）的挑战，特别是createObjectStore方法只能在onupgradeneeded事件中调用的限制。针对在运行时根据需求创建不同存储的需求，文章指出频繁修改数据库模式（Schema）并非最佳实践。相反，建议采用在单个对象存储内部通过数据属性（如storeName字段）进行数据分区，从而维护稳定的数据库结构，并提供相应的实现策略和注意事项。
IndexedDB模式变更机制解析
indexeddb是一个强大的客户端结构化数据存储方案，其核心概念是数据库（database）和对象存储（object store）。对象存储类似于关系型数据库中的表，用于存储键值对数据。indexeddb的模式（schema）管理严格，任何对数据库结构的修改，例如创建、删除或修改对象存储，都必须在idbopendbrequest的onupgradeneeded回调函数中进行。
onupgradeneeded事件只在以下两种情况被触发：
首次创建数据库时。当使用比当前数据库版本更高的版本号打开数据库时。
这意味着，如果需要添加新的对象存储，就必须通过递增数据库版本号来触发此事件。在onsuccess回调中尝试调用db.createObjectStore()会导致运行时错误，因为此时数据库连接已处于稳定状态，不允许进行模式修改。
开发者常常会遇到一种需求：希望在运行时根据不同的“命名空间”或“类型”动态地创建或使用不同的对象存储，例如实现一个类似于localStorage但支持多个独立存储空间的异步版本。
class LocalStorageAsync { #database; constructor(storeName = 'default') { const dbName = 'LocalStorageAsyncDB'; // 首次打开或版本升级时处理模式 const openRequest = indexedDB.open(dbName, 1); // 初始版本号为1 openRequest.onupgradeneeded = (event) => { const db = event.target.result; // 在这里创建或修改对象存储 if (!db.objectStoreNames.contains('dataStore')) { db.createObjectStore('dataStore', { keyPath: 'id', autoIncrement: true }); } }; this.#database = new Promise((resolve, reject) => { openRequest.onsuccess = (event) => { const db = event.target.result; // 在这里不能创建新的对象存储 // if (!db.objectStoreNames.contains(storeName)) { // db.createObjectStore(storeName); // 错误：不能在 onsuccess 中调用 // } resolve(db); }; openRequest.onerror = (event) => { console.error("IndexedDB error:", event.target.errorCode); reject(event.target.error); }; }); } // getItem, setItem 等方法将操作 #database async getItem(storeName, key) { const db = await this.#database; const transaction = db.transaction(['dataStore'], 'readonly'); const store = transaction.objectStore('dataStore'); // 假设数据结构为 { id: 'some_key', storeName: 'foo', value: 'bar' } const request = store.get(key); // 如果key是复合的，需要索引或遍历 return new Promise((resolve, reject) => { request.onsuccess = (event) => { const item = event.target.result; // 筛选出特定storeName的数据 if (item && item.storeName === storeName) { resolve(item.value); } else { resolve(null); } }; request.onerror = (event) => reject(event.target.error); }); } async setItem(storeName, key, value) { const db = await this.#database; const transaction = db.transaction(['dataStore'], 'readwrite'); const store = transaction.objectStore('dataStore'); // 存储时带上 storeName 属性 const dataToStore = { id: key, storeName: storeName, value: value }; const request = store.put(dataToStore); return new Promise((resolve, reject) => { request.onsuccess = () => resolve(); request.onerror = (event) => reject(event.target.error); }); }}// 示例使用async function testLocalStorageAsync() { const defaultStore = new LocalStorageAsync('default'); await defaultStore.setItem('default', 'myKey', 'myValue'); console.log('Default store value:', await defaultStore.getItem('default', 'myKey')); const fooStore = new LocalStorageAsync('foo'); // 此时不会创建新的对象存储 await fooStore.setItem('foo', 'anotherKey', 'anotherValue'); console.log('Foo store value:', await fooStore.getItem('foo', 'anotherKey'));}testLocalStorageAsync();
避免动态模式变更的策略
正如问题中提到的，尝试在onsuccess回调中通过“虚构”的bumpVersion方法来触发onupgradeneeded是不可能的。IndexedDB的设计哲学是模式（Schema）相对稳定，不应频繁变动。为了实现数据分区而避免频繁修改模式，推荐的策略是在单个或少数几个对象存储内部进行数据管理：
使用数据属性进行分区：这是最推荐和灵活的方法。创建一个或少数几个通用的对象存储（例如，命名为dataStore）。在存储每个数据项时，为其添加一个额外的属性（如storeName或type），用于标识该数据所属的逻辑分区。
优点：数据库模式稳定，无需频繁触发onupgradeneeded。简化数据库管理和版本控制。所有数据集中管理，便于备份和迁移。缺点：查询特定分区的数据时，可能需要遍历或创建索引。对于大型数据集，需要为storeName属性创建索引以优化查询性能。
示例代码（基于上述LocalStorageAsync的优化）：在LocalStorageAsync的constructor中，我们只创建了一个名为dataStore的对象存储。getItem和setItem方法则通过在存储的数据对象中添加storeName属性来区分不同的逻辑存储。为了高效查询，建议为storeName属性创建索引。
// 在 onupgradeneeded 中为 storeName 创建索引openRequest.onupgradeneeded = (event) => { const db = event.target.result; if (!db.objectStoreNames.contains('dataStore')) { const store = db.createObjectStore('dataStore', { keyPath: 'id' }); // 为 storeName 属性创建索引，允许重复值 store.createIndex('byStoreName', 'storeName', { unique: false }); }};// ... getItem 方法中使用索引async getItem(storeName, key) { const db = await this.#database; const transaction = db.transaction(['dataStore'], 'readonly'); const store = transaction.objectStore('dataStore'); const index = store.index('byStoreName'); // 获取索引 // 使用索引和 keyPath 查询 const request = index.get(IDBKeyRange.only(storeName)); // 查询特定 storeName 的数据 // 注意：这里需要进一步过滤 key，因为 index.get(storeName) 可能会返回多个结果 // 更直接的方式是使用复合键或在应用程序层过滤 // For a simple key-value store, we might need to iterate or rely on a composite key if possible // A simple get(key) followed by a storeName check is often sufficient for simple cases. const directRequest = store.get(key); // 先按主键获取 return new Promise((resolve, reject) => { directRequest.onsuccess = (event) => { const item = event.target.result; if (item && item.storeName === storeName) { resolve(item.value); } else { resolve(null); } }; directRequest.onerror = (event) => reject(event.target.error); });}// ... setItem 方法保持不变
使用复合键（Compound Keys）：如果你的数据模型允许，可以将storeName和key组合成一个复合键作为主键。这样可以直接通过复合键进行高效查找。
优点： 查询效率高，直接定位数据。缺点： 键的结构可能变得复杂，不适用于所有场景。
示例：
// 在 onupgradeneeded 中创建对象存储时，不指定 keyPath，而是手动管理键const store = db.createObjectStore('dataStore'); // 无 keyPath// setItem 时async setItem(storeName, key, value) { const db = await this.#database; const transaction = db.transaction(['dataStore'], 'readwrite'); const store = transaction.objectStore('dataStore'); const compositeKey = [storeName, key]; // 复合键 const dataToStore = { value: value }; // 实际存储的数据 const request = store.put(dataToStore, compositeKey); // 使用复合键存储 // ...}// getItem 时async getItem(storeName, key) { const db = await this.#database; const transaction = db.transaction(['dataStore'], 'readonly'); const store = transaction.objectStore('dataStore'); const compositeKey = [storeName, key]; const request = store.get(compositeKey); // 使用复合键查询 // ...}
请注意，IndexedDB的复合键要求键是数组，并且数组中的每个元素都是有效的键类型。
注意事项与总结
Schema稳定性优先： 尽量保持IndexedDB的模式稳定。频繁的onupgradeneeded触发不仅会增加代码复杂性，还可能导致用户数据迁移的风险和性能开销。数据分区逻辑： 如果需要逻辑上的数据分区，优先考虑在数据对象内部添加标识属性（如storeName、type等），并通过索引来优化查询。性能考量： 对于大型数据集，为分区属性创建索引至关重要，以避免全表扫描。何时使用onupgradeneeded： onupgradeneeded应该用于真正的数据库结构变更，例如添加新的数据类型、重构现有数据模型或引入新的功能模块，而不是用于简单的逻辑数据分区。版本管理： 当确实需要修改数据库模式时，务必谨慎管理数据库版本号，并编写健壮的迁移逻辑。
通过采纳上述策略，开发者可以在不频繁修改IndexedDB模式的前提下，灵活地管理和分区应用程序数据，从而构建更稳定、高效的Web应用。
以上就是IndexedDB：管理动态对象存储与数据分区策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1512389.html
微信扫一扫 
支付宝扫一扫 
