IndexedDB模式设计与数据分区策略：避免动态对象存储的陷阱

理解IndexedDB的模式（Schema）管理

indexeddb是一个强大的客户端结构化数据存储方案，其核心在于“数据库”和“对象存储”（object store）的概念。对象存储类似于关系型数据库中的表，用于存放具体的数据记录。在使用indexeddb时，一个关键的生命周期事件是onupgradeneeded回调。

当以下两种情况发生时，onupgradeneeded事件会被触发：

1. 数据库首次创建时。
2. 使用indexedDB.open()方法打开数据库时，传入的版本号高于当前数据库的现有版本号时。

onupgradeneeded回调是唯一允许对数据库模式进行修改的地方，例如创建、删除对象存储，或创建、删除索引。这意味着像db.createObjectStore()这样的操作，必须且只能在此回调函数内部执行。

动态添加对象存储的误区

在某些应用场景中，开发者可能希望根据运行时需求动态地创建新的对象存储，例如为了实现类似localStorage的命名空间隔离，为每个“分区”创建一个独立的存储。然而，这种做法通常会遇到以下问题：

1. createObjectStore的限制： 如前所述，db.createObjectStore()不能在onsuccess或其他运行时回调中被调用。尝试在非onupgradeneeded上下文中调用它会导致错误。
2. 频繁的版本升级： 为了触发onupgradeneeded来添加新的对象存储，每次都需要递增数据库的版本号。这意味着每次添加新的“分区”时，用户都需要经历一次数据库升级过程。这不仅增加了代码的复杂性，也可能导致不必要的性能开销和用户体验问题（例如，如果升级过程耗时，可能会阻塞主线程）。
3. 模式稳定性： 数据库模式（Schema）的设计应尽可能保持稳定。频繁的模式变更会增加维护难度，并可能引入潜在的兼容性问题。

因此，尝试通过编程方式在onsuccess中“强制”触发版本升级（例如，设想一个db.bumpVersion()方法）是不符合IndexedDB设计哲学的，也是不可行的。

推荐的数据分区策略：内部属性分区

鉴于IndexedDB对模式修改的严格限制以及对稳定模式的追求，推荐的做法是避免为每个逻辑分区创建独立的对象存储。相反，我们可以在一个或少数几个通用对象存储内部，通过在数据对象中添加一个特定的“分区键”或“类型”属性来实现数据的逻辑隔离。

实现原理：

北极象沉浸式AI翻译

免费的北极象沉浸式AI翻译 - 带您走进沉浸式AI的双语对照体验

0

查看详情

1. 单一或少量通用对象存储： 创建一个或几个设计良好的对象存储，例如一个名为'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 });
     }
   };

   登录后复制

2. 数据结构设计： 在每个要存储的数据对象中，添加一个用于标识其所属“分区”的属性。例如，如果模拟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;
   }

   登录后复制

3. 查询与过滤： 当需要获取特定“分区”的数据时，可以通过遍历对象存储并根据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模式设计与数据分区策略：避免动态对象存储的陷阱的详细内容，更多请关注php中文网其它相关文章！