Перевести схему базы данных sql на IndexedDB

Question

У меня есть три таблицы в моей схеме SQL: клиенты с адресом и т. Д. Заказы с информацией о заказе и файлами, в которых хранятся загруженные файлы. как таблица файлов, так и таблица заказов содержат внешние ключи, ссылающиеся на таблицы клиентов.

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

Теперь я знаю, что есть файл shim.js, но я пытаюсь понять само понятие.

Помощь и советы высоко оценены!

EDIT:

Так что я бы на самом деле надо думать о том, какие запросы я хочу, чтобы затем оптимизировать выполнение IndexedDB для этих запросов, является то, что главное здесь? В принципе, я хочу хранить клиента один раз, а затем много заказов для этого клиента, а затем иметь возможность загружать небольшие файлы (желательно pdf) для этого клиента, даже не обязательно для каждого заказа (хотя, если это легко реализовать, я могу сделать это) ... Я вижу каждого клиента как отдельную сущность, у меня не будет таких вещей, как «дайте мне всех клиентов, которые заказали xy» - мне нужно только каждый клиент, а затем сохранить все заказы для клиента и всех файлов , Я хочу уйти: поиск клиента с именем XY - который затем дает мне список всех заказов и их дат и список файлов, загруженных для этого клиента (возможно, связанных с заказом).

Answer 1

Этот вопрос является слишком широким, чтобы правильно ответить. Тем не менее, основная концепция, которую следует изучать при переходе с SQL на No-SQL (indexedDB), - это концепция хранилищ объектов. Большинство баз данных SQL являются реляционными и выполняют большую часть работы по оптимизации запросов для вас. indexedDB нет. Таким образом, понятия нормализации и денормализации работают по-другому. Координатор должен четко планировать ваши собственные запросы. В отличие от дизайна приложения/системы, который позволяет использовать простые SQL-запросы, которые разрабатываются в более поздний момент времени и, возможно, даже легко добавляются/меняются в более позднее время, вам действительно нужно сделать много планирования вперед для индексированного DB.

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

Непонятно из вашего вопроса, но ваши 3 таблицы - это клиенты, заказы и файлы. Я выйду на конечность и сделаю некоторые догадки. Готов поспорить, вы могли бы использовать одно хранилище объектов, клиентов. Затем для каждого объекта клиента сохраняются свойства обычного клиента, сохраняются свойства массива заказов и сохраняются свойства массива файлов. В массиве заказов сохраните объекты порядка.

Если ваши файлы бинарные, это не сработает, вам нужно будет использовать blobs и даже столкнуться с проблемами с поддержкой blob в различных версиях браузера indexedDB (некоторые из них поддерживают Chrome, это неясно от версии к версии).

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

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

Если отношение между клиентами и заказами много для многих, то это также не будет работать так хорошо, из-за необходимости избыточно хранить информацию о заказе на одного клиента.Тем не менее, одна заметка здесь заключается в том, что это избыточное хранилище довольно распространено в базах данных в стиле NoSQL, таких как indexedDB. Цель состоит не в том, чтобы идеально моделировать данные, а для хранения данных таким образом, чтобы ваши наиболее часто возникающие запросы выполнялись быстро (при сохранении правильности).

Edit:

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

1. Получите одно сущность из хранилища объектов клиента на основе идентификатора клиента.
2. Откройте курсор над заказами и получите все заказы для клиента. В хранилище заказов используйте свойство client-id. Создайте индекс для этого свойства client-id. Откройте курсор над индексом для определенного идентификатора клиента.
3. Открыть курсор над хранилищем файлов, используя аналогичную тактику, как # 2.

В вашем слое bizlogic применяйте ограничения данных. Например, при удалении клиента сначала удалите все файлы из хранилища файлов, затем удалите все заказы из магазина заказов, а затем удалите единый клиентский объект из хранилища клиентов.

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