问题
In indexedDB, if the keys are arrays of integers such as [n,0] through [n,m], for operations that involve getting all the records in which the first element of the array key is n or opening a cursor on the same set of records, is there any advantage to using an index on an additonal property that stores n over using a key range?
Reasons to think an index may not be better include that the browser has to maintain the index for each change to the object store, an additional property has to be added to each record to store already stored data n, and little may be gained since the keys in the index will always point to consecutive records in the object store rather than dispersed throughout.
If the number of different values of n are likely no more than 1,000 and for m no more than 50, is using an index superior to a key range?
Thank you.
回答1:
I guess the purpose of indexedDB is to have object store locally. It is not sql that you need to update columns in every object. since you change the object structure (saying by adding property) it is true that all the objects in the store must be rewriten as you said...
emm well... another option for you is to update the db with another store which contain somthing similar to forien key in sql or uniqe key which store the other stored objects extentions... and in it every obj item is also supposed to be same structured.
I think this is the point you start to use onupgradeneeded intansively.
来源：https://stackoverflow.com/questions/60824806/indexeddb-using-an-index-versus-a-key-range