IndexedDB：管理动态对象存储与数据分区策略

本文探讨了在IndexedDB中动态添加对象存储（Object Store）的挑战，特别是createObjectStore方法只能在onupgradeneeded事件中调用的限制。针对在运行时根据需求创建不同存储的需求，文章指出频繁修改数据库模式（Schema）并非最佳实践。相反，建议采用在单个对象存储内部通过数据属性（如storeName字段）进行数据分区，从而维护稳定的数据库结构，并提供相应的实现策略和注意事项。

IndexedDB模式变更机制解析

indexeddb是一个强大的客户端结构化数据存储方案，其核心概念是数据库（database）和对象存储（object store）。对象存储类似于关系型数据库中的表，用于存储键值对数据。indexeddb的模式（schema）管理严格，任何对数据库结构的修改，例如创建、删除或修改对象存储，都必须在idbopendbrequest的onupgradeneeded回调函数中进行。

onupgradeneeded事件只在以下两种情况被触发：

1. 首次创建数据库时。
2. 当使用比当前数据库版本更高的版本号打开数据库时。

这意味着，如果需要添加新的对象存储，就必须通过递增数据库版本号来触发此事件。在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）相对稳定，不应频繁变动。为了实现数据分区而避免频繁修改模式，推荐的策略是在单个或少数几个对象存储内部进行数据管理：

1. 使用数据属性进行分区：
   这是最推荐和灵活的方法。创建一个或少数几个通用的对象存储（例如，命名为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 方法保持不变

2. 使用复合键（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应用。