Quale struttura di dati IndexedDB per l'app di Chrome?

Question

Quale struttura di dati IndexedDB per l'app di Chrome?

#1 da (1 voti)

2

Sono sulla buona strada per creare un'app Chrome, dedicata a soddisfare gli ordini di negozio / mercato. Gli ordini provengono da API di mercato come Amazon MWS. I dati vengono memorizzati solo nell'app (con backup). Il sistema deve anche lavorare in modo rapido se sono memorizzati 50.000 o 100.000 ordini.

Quindi come strutturare IndexedDB per quello?

Ogni ordine può avere più articoli ordinati. Può anche avere più codici di tracciamento dei pacchi e così via.

var simplifiedOrderObject = {
    "ordernumber": "123-12345-234",
    "name": "Mr. Sample",
    "address": "Foostreet 12, 12345 Bar York",
    "orderitems": [
        {
            "item": "brush",
            "price": "2.00"
        },
        {
            "item": "phone",
            "price": "30.90"
        }
    ],
    "parcels": [
        {
            "service": "DHL",
            "track": "12345"
        },
        {
            "service": "UPS",
            "track": "3254231514"
        }
    ]
}

Dovrei creare un solo objectStore, che contiene i dati completi dell'ordine in un oggetto / riga come mostrato sopra? Se lo farei: È possibile e veloce avere un indice per la ricerca di un numero di pacco? - Ancora: più numeri di pacchi possono essere in ogni oggetto / riga.

O è meglio o addirittura necessario farlo come nei DB relazionali:

Un ObjectStore per l'ordine
uno per orderItem
uno per pacchi spediti ... e tutto ciò è connesso avendo lo stesso numero d'ordine?

Qual è il modo più rapido ed efficiente?

javascript indexeddb chrome

posta Lutz 28.04.2016 - 18:54

fonte

1 risposta

Leggi altre domande sui tag javascript indexeddb chrome

Idee sull'elaborazione del file di testo di input in parallelo dallo script di Bash Strategie di pre-computazione quando si risolvono più equazioni lineari con la stessa matrice?

score 1 · Accepted Answer

Rispondendo alla mia domanda: ho fatto alcuni test adesso. Sembra che non sia possibile farlo con quell'oggetto in solo 1 objectStore.

Un altro oggetto di esempio che funzionerebbe:

var myObject = {
    "ordernumber": "123-12345-234",
    "name": "Mr. Sample",
    "shipping": {"method": "letter",
                 "company": "Deutsche Post AG" }
}

La creazione di un indice sarà effettuata da:

objectStore.createIndex(objectIndexName, objectKeypath, optionalObjectParameters);

Con l'impostazione objectKeypath è possibile indirizzare un valore nell'oggetto principale come "name" :

objectStore.createIndex("name", "name", {unique: false});

Sarebbe anche possibile indirizzare un valore da un oggetto subo di un oggetto come "shipping.method" :

objectStore.createIndex("shipping", "shipping.method", {unique: false});

MA non è possibile indirizzare valori come quelli di "track" , che sono contenuti in oggetti, memorizzati in una matrice. Anche qualcosa come "parcels[0].track" per ottenere il primo valore come indice non funziona.

In ogni caso, sarebbe possibile indicizzare tutti gli elementi semplici di un array (ma non oggetti).

Quindi la seguente struttura più semplice consentirebbe di creare una voce di indice per ogni numero di parcella dell'array "trackingNumbers" :

var simplifiedOrderObject = {
    "ordernumber": "123-12345-234",
    "name": "Mr. Sample",
    "address": "Foostreet 12, 12345 Bar York",
    "orderitems": [
        {
            "item": "brush",
            "price": "2.00"
        },
        {
            "item": "phone",
            "price": "30.90"
        }
    ],
    "trackingNumbers": ["12345", "3254231514"]
}

durante la creazione dell'indice con multiEntry impostato su true :

objectStore.createIndex("tracking", "trackingNumbers", {unique: false, multiEntry: true});

In ogni caso, la mancanza della possibilità di indicizzare i valori degli oggetti nelle matrici rende l'uso di indexedDB davvero non necessario complicato. È un fallimento nel design. Questo costringe lo sviluppatore a fare cose come nei DB relazionali, mentre non ha tutte le possibilità di SQL. Davvero cattivo: (