Основной вопрос, касающийся структуры данных хранилища объектов indexedDB для эффективности редактирования по сравнению с извлечением данных - PullRequest
0 голосов
/ 23 марта 2019

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

Данные, с которыми я имею дело, состоят из наборов шаблонных форм, в которых каждая форма, хотя и очень похожая, может иметь разное количество определенных фрагментов информации и разные объемы данных для каждого элемента. Грубо говоря, каждая форма обычно имеет от 50 до 75 отдельных элементов данных, некоторые из которых имеют только логическое значение, а другие - абзацы текста.

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

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

Итак, мой вопрос, что является более сложным для браузера? Чтобы извлечь и заменить более крупный объект данных для одного ключа или нескольких отдельных извлечений более мелких объектов, содержащих одинаковый объем общих данных?

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

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

Спасибо, что рассмотрели мой очень начинающий вопрос.

Добавлено описание

Я не пытаюсь усложнять вещи, а просто лучше понимаю. Пожалуйста, предположите, что на одну форму было 1000 объектов недвижимости. Если пользователь редактирует одно свойство только в форме, то либо объект, хранящий 1000 свойств, будет извлечен с get и сохранен в переменной, одно значение свойства отредактировано, а затем put обратно. Или новый объект должен быть построен из всех данных в форме, а затем этот объект put возвращается в качестве перезаписи существующего объекта. Таким образом, в любом случае большой объект необходимо перемещать и удерживать где-то за пределами базы данных. Невозможно просто изменить одно значение в базе данных без извлечения всех данных.

Шаги, связанные с поиском ключа, десериализацией объекта и повторной сериализацией объекта, и все остальное занимают значительную часть общего времени, независимо от размера фактического объекта данных? Или будет существенная разница между редактированием ключа, содержащего объект с одним свойством, и редактированием одного свойства в ключе, содержащем объект с 1000 свойствами?

Если существует значительная разница, то на стороне редактирования это сэкономило бы время, потому что я почти никогда не собираюсь сохранять все 1000 свойств одновременно, а только по мере их завершения, например, в событии onchange.Однако на стороне извлечения и отображения, возможно, будет открыт курсор или индекс на этих 1000 отдельных клавиш для извлечения данных и заполнения HTML.Я предполагаю, что это займет больше времени, чем поиск и удержание одного большого объекта и его использование для заполнения HTML.Таким образом, существует некоторая конкуренция между ускорением сохранения и одновременным извлечением всех данных формы для ускорения заполнения HTML.

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

Проработав некоторое время с этим, я думаю, что был глуп, потому что мне следовало подумать, что, поскольку это оба асинхронных процесса, сохранение менее важно для пользователя, чем для поиска.Быстрое заполнение экрана новыми данными важнее, чем быстрое его сохранение.

...