0

I am trying to create a system to mock APIs. For that I'll have a group of contributors for a particular project who can edit and create certain APIs. Now only Admins can add a contributor to a group.

I'm currently planning to use CouchDB but I would be using a query builder so that I could perhaps switch database in future. I would be happy for schema design suggestions that might apply more generally to document-oriented databases.

I've created a schema where I've decided to have 3 collections as follows:

APIS

{
    api_id:ObjectID(Or some unique id),
    api_name:string,
    api_group:string,
    endpoint:string,
    req_headers:[{},{},...](Array of json objects),
    req_body:{}(JSON Object),
    res_headers:[{},{},...](Array of json objects),
    res_body:{}(JSON Object),
    res_status:Int(This will be http status),
    success:boolean
}

Groups

{
    group_id:ObjectID(Or some unique id),
    group_name:string,
    apis:[api_id](array of api_ids),
    admins:[user_id](array of user ids),
    contributors:[user_id](array of user ids)
}

Users

{
    user_id:ObjectID(Or some unique id),
    user_name:string,
    email_id:string,
}  

I would like to know if there is a better approach to make this design in such a way that the relational structure can be minimized?

As you can see the APIS are related to Groups and Groups is related to Users based on their respective ids. But structure should be flexible enough to incorporate changes in future.

  • All documents are participating the same database under the single mongod or else. – Md Haidar Ali Khan Feb 12 '18 at 9:43
  • 2
    Are you trying to model for CouchDB, MongoDB, or lowest common denominator features of both? While there are similarities in the general category of "document-oriented database", the query languages and storage features are certainly not identical. If you are aiming for efficiency, I recommend you choose a database so your question has more context for an answer. – Stennie Feb 12 '18 at 9:52
  • I would go with COUCHDB in case that's what you meant, but still would be happy to know something that can stand good for a document-database :) – TGW Feb 12 '18 at 10:36
  • If you're looking for efficiency, I'd still narrow down which document-oriented database you are planning to use. For example, someone has edited your question text to change Couch to Couchbase. Although Apache CouchDB and Couchbase Server have some common origins, they also have different features (including query languages and approaches to joins): couchbase.com/couchbase-vs-couchdb. The choice of database will influence the ease or efficiency of reading or updating your data model. – Stennie Feb 12 '18 at 10:57
  • I would be using a querybuilder so that I could switch db if I ever want to but as you mentioned between CouchDb and Couchbase I would go with CouchDB made relevant change in question – TGW Feb 12 '18 at 11:07
0

As MongoDB BOL Here MongoDB does not support joins. In MongoDB some data is denormalized, or stored with related data in documents to remove the need for joins. However, in some cases it makes sense to store related information in separate documents, typically in different collections or databases.

MongoDB applications use one of two methods for relating documents:

Manual references where you save the _id field of one document in another document as a reference. Then your application can run a second query to return the related data. These references are simple and sufficient for most use cases.

DBRefs are references from one document to another using the value of the first document’s _id field, collection name, and, optionally, its database name. By including these names, DBRefs allow documents located in multiple collections to be more easily linked with documents from a single collection.

To resolve DBRefs, your application must perform additional queries to return the referenced documents. Many drivers have helper methods that form the query for the DBRef automatically. The drivers do not automatically resolve DBRefs into documents.

DBRefs provide a common format and type to represent relationships among documents. The DBRef format also provides common semantics for representing links between documents if your database must interact with multiple frameworks and tools.

  • The database references page could definitely use a refresh: there are some options for server-side joins with caveats. For common use cases (and best performance) it is usually preferable to colocate data using embedding. However, MongoDB 3.2 added support for left outer joins to an unsharded collection via the $lookup aggregation operator. In MongoDB 3.6 the $lookup operator was enhanced to support join conditions and uncorrelated sub-queries. – Stennie Feb 12 '18 at 10:09
  • I am aware that joins is not a much appreciated stuff in mongo world, and I am already considering Manual References if the structure I've provided seems good. I just wanted to know if it was good enough or can it be improved? Also couch is something I am considering instead of mongoDB – TGW Feb 12 '18 at 10:40
  • @ Stennie,As per OP , he want to reference one document id with another documents with their respective id. In "Modeling Embedded Relationships" you are using only one documents id and other documents you just embedding inside that. – Md Haidar Ali Khan Feb 12 '18 at 11:23
  • @TGW,Whatever you have provided the documents structure through which not possible in MongoDB.In you have said every documents have unique and certain id. That's means "APIS_id" and "group_id" and "Users_id" all of them have unique and certain id. – Md Haidar Ali Khan Feb 12 '18 at 11:43
  • @TGW,Suppose that if you shall go to do "Manual References" when a "APIS_id" collection's document references a any other collection of any documents , it also needs to specify which collection to look into based on that collections of that documents type. In such scenarios where a document references documents from many collections, we should use DBRefs. – Md Haidar Ali Khan Feb 12 '18 at 11:46

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.