Frage

I know how a relational database stores data. I know the basics of indexeddb (up to and including writing a script which plasters over the differences between chrome and ff). I understand the principles behind using an index and that indexeddb stores js objects.

I am wondering if there is some design pattern that should be used when working with a flat database like indexeddb. Right now I have it saving every "row" to a objectStore which is then looked up by its key or an index. Would it be better to save one huge object instead of a bunch of rows?

Also, how should relationships be handled? That is, how should one bridge the gap between RDBSM's and flat databases like indexeddb?

I did a test yesterday and it took 11 seconds to write

params = {
    "user_id":"4",
    "first_name":"Bob Smith",
     "phone": "1-800-555-1212"
};

to the database 100 times. I did open a new transaction each time but that still seems like a really long time. test was in ff.

War es hilfreich?

Lösung

results are in - it doesn't really matter.

if you store it relationally it has about the same read write times as a database that is naturally relational (websql) or even just key/value pairs (localStorage).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top