Couchbase JSON структура модели

Question

Я хочу работать с couchbase json-document предназначенный. Но я не знаю, как лучше всего хранить и структурировать данные и получить их позже.

Есть ли какой-нибудь учебник для начала работы (ресурсы, связанные с couchbase.com, не помогли)?

Я использую PHP для доступа к couchbase. У меня есть следующий образец:

(new document) 
user1 
{ 
"uid":1, 
"name":"marius" 
} 

(new document) 
planet1 
{ 
"pid":1, 
"user_uid":1, 
"name":"earth" 
} 

(new document) 
user2 
{ 
"uid":2, 
"name":"anyone" 
} 

(new document) 
planet2 
{ 
"pid":2, 
"user_uid":2, 
"name":"saturn" 
} 

Теперь, что бы самый умный способ установки (вставки) эти документы в базу данных, и как я могу получить (выбрать) документы по выбору.

Чтобы сказать, что в SQL я хочу к ->SELECT * FROM пользователя, планета, где user.uid = 1 И planet.user_uid = 1

Answer 1

Couchbase хранит данные иначе, чем в реляционной базе данных.

Есть два основных способа получить данные из Couchbase:

ключ/значение. Это означает, что вы даете вашему документу один ключ для запроса, а затем, очевидно, значение будет всего документа. Таким образом, для пользователя:

user = couch.get(123) 

Это будет возвращать весь документ для пользователя ID 123.

Просмотров. Вы можете писать представления в Couchbase, используя функции map/reduce. Самое приятное в том, что к этим представлениям можно обращаться так же, как к представлениям в CouchDB, поэтому вы можете делать такие вещи, как упорядочение и ограничение. http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options

Ознакомьтесь с проектной документацией/мнениями на портале Couchbase. Когда вы пишете один, он даст вам URL-адрес, чтобы проверить вашу карту/уменьшить материал. Затем вы можете добавить параметры в URL для выполнения дополнительной работы.

Answer 2

Нет общего способа сказать, как должны быть разработаны ваши документы. Это зависит от характеристик вашего приложения. Соотношение записи и чтения? Как используются данные и т. Д. С сильными сторонами преобразования данных с использованием представлений в кушетке, я думаю, вы могли бы сделать более «общие» документы и создать определенные представления, которые преобразуют документ в соответствии с вашим прецедентом. Разумеется, это не решение, которое вы должны применять ко всем прецедентам (не рассматривайте его как дизайн серебряной пули).

Классический пример - пример блога. Должны ли вы хранить комментарии в сообщении или извлекать комментарии и сами проживать со ссылкой? Это зависит от характеристик. Является ли более распространенным иметь несколько комментариев или обычно загружает комментарии?

Другой образец. Что делать, если вы храните документ заказа. Должен ли клиент быть частью заказа или заказа клиента? Может быть, и то, и другое? Да, возможно. Я бы сказал, что с документами dbs вам нужно быть немного более открытым для дублирования данных. Возможно, что документ Customer по-прежнему существует как «текущий вид» клиента, при этом все его данные и заказ содержат фрагменты снимка клиента; полезный для контекста заказа и некоторый обзор в приложении, который затем использует ссылки на фактический клиентский документ? Вероятно. Но опять же, это зависит от того, как вы будете потреблять данные.

Что касается перевода на SQL: http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-sql.html