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