я новичок в концепции nosql, поэтому, когда я начинаю изучать PouchDB, я нашел эту таблицу преобразования. Меня смущает то, как PouchDB обрабатывается, если, скажем, у меня есть несколько таблиц, означает ли это, что мне нужно создать несколько баз данных? Потому что, насколько я понимаю, в pouchdb база данных может хранить много документов, но документ означает строку в sql или я неправильно понял?
... значит ли это, что мне нужно создать несколько баз данных?
No.
... документ означает строку в sql или я неправильно понял?
Это верно. Таблица SQL определяет заголовок столбца (имя и тип) — это имена свойств документа JSON.
Таким образом, все документы (строки) с одинаковыми свойствами (так называемая "схема") эквивалентны вашей таблице SQL. Вы можете иметь столько разных схем в одной базе данных, сколько захотите (посетите json-schema.org для вдохновения).
Как запросить их отдельно? Создавайте представления CouchDB! Вы можете получить все/некоторые «строки» ваших табличных данных (документы с той же схемой) одним запросом, как вы это знаете из SQL.
Чтобы легко писать такие представления, свойство type очень часто используется в документах CouchDB. Ваше известное имя из таблицы SQL может быть вашим типом, например doc.type: "animal"
Имена ваших представлений могут быть animalByName или animalByWeight. Зависит от ваших потребностей.
Ответ на этот вопрос, кажется, на удивление недостаточно задокументирован. Хотя @llabball явно дал достойный ответ, я не думаю, что просмотры — это всегда правильный путь.
Как вы можете прочитать здесь в разделе Когда чтобы не использовать map/reduce, Нолан объясняет, что для более простых приложений ключевым моментом является злоупотребление _ids и использование возможностей allDocs().
Другими словами, если у вас есть два отдельных типа (скажем, исполнители и альбомы), вы можете добавить префикс идентификатора каждого типа, чтобы получить легко доступный для поиска набор данных. Например, _id: 'artist_name' и _id: 'album_title' позволит вам легко найти исполнителей в порядке имен.
Такое размещение данных приведет к повышению производительности из-за того, что не требуются дополнительные индексы и меньше кода. Однако ясно, что если ваши требования к данным более сложны, то представления — это то, что вам нужно.
Иногда план с несколькими базами данных является хорошим вариантом, например, база данных для каждого пользователя или даже база данных для каждой пользовательской функции. Взгляните на эту беседу в списке рассылки CouchDB.
