Какая структура данных IndexedDB для приложения Chrome?

Я собираюсь создать приложение Chrome, посвященное выполнению заказов на магазины и рынки. Заказы поступают с таких API-интерфейсов, как Amazon MWS. Данные хранятся только в приложении (с резервным копированием). Системе необходимо также быстро работать, если хранится 50 000 или 100 000 заказов.

Итак, как структурировать IndexedDB для этого?

Каждый заказ может иметь несколько упорядоченных элементов. Он также может иметь несколько кодов отслеживания отправлений и т. Д.

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"
        }
    ]
}

Должен ли я создать только один объектStore, который содержит полные данные заказа в одном объекте /строке, как показано выше? Если бы я сделал это: Возможно ли и быстро иметь индекс для поиска номера посылки? - Опять же: в каждом объекте /строке могут быть несколько номеров парцелл.

Или лучше или даже нужно сделать это, как в реляционных БД:

  • Один объект-хранилище для заказа
  • один для orderItem
  • один для отправленных посылок ... и все это связано с тем же порядковым номером?

Каков более быстрый и эффективный способ?

2 голоса | спросил Lutz 28 PMpThu, 28 Apr 2016 19:54:15 +030054Thursday 2016, 19:54:15

1 ответ


1

Отвечая на мой собственный вопрос: сейчас я провел несколько тестов. Похоже, что это невозможно сделать с этим объектом только в 1 объектеStore.

Другой пример, который будет работать:

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

Создание индекса будет выполняться путем:

objectStore.createIndex(objectIndexName, objectKeypath, optionalObjectParameters);

С настройкой objectKeypath можно указать значение в основном объекте, например "name":

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

Также можно было бы обратиться к форме значений подобъекта объекта, такого как "shipping.method":

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

НО не возможно адресовать значения, такие как "track", которые содержатся в объектах, хранящихся в массиве. Даже что-то вроде "parcels[0].track", чтобы получить первое значение, поскольку индекс не работает.

Во всяком случае, можно было бы индексировать все простые элементы массива (но не объекты).

Таким образом, следующая более простая структура позволит создать запись индекса для каждого парциального номера в массиве "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"]
} 

при создании индекса с multiEntry установлен на true:

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

Во всяком случае, отсутствие возможности индексирования значений объектов в массивах делает использование indexedDB действительно ненужным сложным. Это провал в дизайне. Это заставляет разработчика делать такие вещи, как в реляционных БД, при этом не хватает всех возможностей SQL. Действительно плохо: (

ответил Lutz 29 AMpFri, 29 Apr 2016 01:29:44 +030029Friday 2016, 01:29:44

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132