Application design, how many buckets is too much

When importing relational data in to Couchbase , should each table corresponds to a bucket. I ask because older documentation recommends minimizing the number of buckets and keep multiple document types together and use a type attribute to differentiate between. The tutorials I’ve see for using N1QL have one bucket for each entity which makes joining documents easier.

Imagen importing employee and department data when the employee has a dept_id foreign key. Should employees and departments be in separate buckets? Or should I put them in the same bucket and give them type attributes with keys like emp_id_1 and dept_id_2 which doesn’t seem to work as well with N1QL.

At present the number of buckets are limited to 10. So you should minimize number of buckets.
N1QL will work well, you need to give addition predicates e.type = “employee” AND m.type = “manager”

Checkout travel-sample bucket which has 5 different types. https://docs.couchbase.com/server/4.5/travel-app/travel-app-data-model.html and ANSI JOIN queries with 17 examples https://blog.couchbase.com/ansi-join-support-n1ql/

Check out “Designing Index For Query In Couchbase N1QL” https://blog.couchbase.com/n1ql-practical-guide-second-edition/

While it is possible to simply import relational rows as Couchbase documents, it is often better to remodel the data to take advantage of the nesting and arrays that JSON documents permit. Joins are always expensive, and if you have common queries that rely upon joins, the queries will likely be faster if the relevant documents are merged.

There are many examples online of how to do this. One good place to start is here: https://blog.couchbase.com/moving-from-sql-server-to-couchbase-part-1-data-modeling/

Does this imply an index is needed on type?

I am working with a data model that has teams, stadiums, and players. What would be a good way to model this in Couchbase. nesting a stadium inside of each team and a team inside each player seems like it would use a lot of space.

@bfwarner -Yes, it sounds like your particular data is not likely to benefit from nesting. It all depends on the cardinality of relationships and the kinds of queries you’ll be running. Some situations, such as customers with a small, variable number of mailing addresses or credit cards, nesting that data doesn’t increase data size much and can avoid joins.

For the best performance, make sure that when one data type refers to another, use the document id. E.g., if a player is only on one team, have the ‘team’ field of the player contain the document id of the team. Document ids are the fastest way to retrieve a document.