Couchbase Relationship Representation

Hello ,

I have question I have read that views are indexed on disk and index may be large than the original data if it emits data from different docs type , my question Is I can’t judge in some situation that I have to use view or I have to use default get by doc name look for this scenario :

I want to make social game that will contains 3 tables as bellow :
1- UserProfile : contains all user personal info and general info like facebookID , score , coins ..
2- UserDetails : it will contain all user stage saved objects like user map also UserID.
3- UserFriends : here a link table that contains only the ids of user friends and UserID .

What I did in my game is, I retrieve user profile and other user info like details by Doc Name because I am who will save them and they are countable so each user have these docs so in java I call :
client.getBuilk ( “UserProfile_UniqueID” ,”UserDetails_UniqueID” …etc ) ;

And also I can retrieve the user friends id form doc like this :
client.get( “UserFriends_UniqueID”)

Also I create view that will get just small info from the UsersProfile such as friend name and score
So after getting friends id I will call that view and support it with ComplexKeys which is friends id and all data will returns as I want .

I don’t know if this will have drawbacks and will cause problems , should I have to use views ?if yes how can I retrieve friends info for specific player?

1 Answer

« Back to question.

Hello,

First of all, your approach based on keys and key lookups is good. If you are happy with it you do not have to change.

Even when you are using views, at the end most of the time you use the key of the document to get the information. This is what the Java SDK is doing for example when you query a view using includeDocs=true.

Do you mind showing us an example of your JSON documents? this could help to see what could be done. But for me, based on my understanding of your model so far, you do not need views in your application.

Regards
Tug
@tgrall