Концептуальные проблемы с IndexedDB (отношения и т. д.)

Я сам новичок в IndexedDB, но я тоже много думал о том, как я буду использовать IndexedDB для таких целей. Первое, что я бы предложил, если вы еще этого не сделали,-это посмотреть, как другие базы данных ключей / документов (CouchDB, MongoDB и т. д.) работа, так как это по существу тип базы данных, которая является IndexedDB.

существует несколько различных подходов к обработке отношений в базе данных документов...как для синхронизации с реляционными серверная база данных, вероятно, вам нужно будет создать какое-то пользовательское сопоставление, потому что некоторые подходы к отношениям, которые имели бы смысл для IndexedDB, не будут очень четко сопоставляться с реляционной базой данных. Тем не менее, я думаю, что настройка такого сопоставления определенно выполнима, и большая проблема заключается в том, как обрабатывать отношения в IndexedDB, поэтому я сосредоточусь здесь...

Что касается вашего предлагаемого решения, я думаю, что оно может работать хорошо, и вы можете написать простая библиотека запросов, которая помогла консолидировать код сантехники (подробнее об этом ниже). Хранилища ключевых значений построены так, чтобы быть очень эффективными при поиске элементов по ключам, поэтому для каждого связанного объекта это может быть не так неэффективно, как вы думаете...однако я придумал другую идею, которая лучше использует индексы...

во-первых, для моего предлагаемого решения вам нужно будет хранить метаданные "objectstore "где-то, кроме самого объекта" reference " ...это не обязательно даже нужно хранить в IndexedDB вообще; вы можете просто использовать схему в памяти для этого:

var schema = {
    Course: {
        fields: [id, title],
        relationships: {
            lecturers: {objectstore: 'lecturer'},
            semester: {objectstore: 'semester'},
        }
    },
    Lecturer: { ... }
    ...
};

(кстати, в вашем примере JSON есть ошибка...у вас не может быть более одного ключа с именем "reference" - это должен быть массив "references".)

это освобождает вас от хранения значений ID непосредственно в полях отношений, так что вы можете создавать индексы на них (я использовал префиксы букв для ясности, хотя на самом деле все они, вероятно, будут иметь ID 1, так как значения ID не должны быть уникальными для всех магазинов):

var course1 = {
    id:'C1',
    lecturers:['L1'],
    semester:1
};

var lecturer1 = {
    id:'L1',
    courses:['C1']
}

var semester1 = {
    id:'S1',
    courses:['C1']
}

вы, конечно, должны быть осторожны, чтобы все операции хранения/извлечения происходили через функции доступа к данным (например, insert (), update (), delete ()), которые были достаточно умными, чтобы гарантировать, что отношения всегда обновлялись правильно с обеих сторон...на самом деле вам может не понадобиться это в зависимости от того, как вы планируете запрашивать данные, но это кажется хорошей идеей, так как иногда вы можете просто захотеть получить Идентификаторы связанных объектов (для поиска позже или нет), а не фактическое их извлечение.

предположим, у вас есть индекс в поле "курсы" в магазине лекторов. Используя индекс, вы можете одним махом найти всех лекторов, связанных с определенным идентификатором курса:

lecturerStore.index("courses").get("C1").onsuccess = …

для этого примера это не имеет большого значения, потому что курсы, как правило, имеют только 1-2 лекторов, но рассмотрим, как индекс может быть использован для эффективного поиска всех курсы в конкретном семестре:

coursesStore.index("semester").get("S1").onsuccess = …

обратите внимание, что в Примере лектора (отношение "многие ко многим") индекс должен быть указан как "multientry", что означает, что если у вас есть поле, значение которого является массивом, каждый элемент массива будет добавлен в индекс. (См.https://developer.mozilla.org/en/IndexedDB/IDBObjectStore#createIndex ...Я не уверен, что поддержка браузера на этом.)

и я уверен, что вы могли бы делать другие умные вещи с индексированием тоже, используя курсоры и IDBKeyRange, чтобы помочь сделать какую-то операцию" соединения". Для идей проверьте эту ссылку, которая демонстрирует способы обработки отношений в CouchDB:

http://wiki.apache.org/couchdb/EntityRelationship

эта ссылка также упоминает использование встроенных документов, что вы определенно должны учитывать-не все объекты обязательно должны иметь свое собственное хранилище объектов, особенно для " агрегации" отношения.

(кстати, я не уверен, насколько это было бы полезно для вас, так как он не предоставляет много возможностей для запросов, но кто-то фактически реализовал CouchDB-подобную базу данных поверх IndexedDB:https://github.com/mikeal/pouchdb)

в дополнение к индексам, реализация механизма кэширования, вероятно, тоже поможет.

теперь, что касается упрощения процесса запроса, я знаю, что вы упомянули, что не хотите использовать обертку библиотека...но у меня была идея о удобном API, который можно было бы создать, который принял бы такой объект:

//select all courses taught by 'Professor Wilkins'
{
from: 'lecturer',  //open cursor on lecturer store 
where: function(lecturer) { return lecturer.name=='Professor Wilkins' }, //evaluate for each item found
select: function(lecturer) { return lecturer.courses }, //what to return from previous step
//this should be inferred in this case, but just to make it clear...
eagerFetch: function(lecturer) { return lecturer.courses }
}

Я не уверен, насколько сложно было бы реализовать, но определенно кажется, что это облегчит жизнь.

Я достаточно долго блуждал, но я хотел упомянуть еще одну вещь, которая заключается в том, что я также думал о заимствовании некоторых идей из баз данных graph, поскольку они намного лучше справляются с отношениями, чем базы данных документов, и я думаю, что можно было бы реализовать графическую базу данных поверх IndexedDB, я просто еще не уверен, насколько это будет практично.

удачи!