ORM - Object relational mapping with Javascript

Question

I'm working on a NodeJS API project and I'm using CouchDb (Object document storage, similar to MongoDb).

In javascript you're free about flow control, because the data structure that you handle are just JSON. So you can just pass object from client to server, and from server to database, without using classes, just passing over the JSON data. However it can be nice to have class that handle this data structures and represent entities.

e.g.

var user = new User({name: 'jim'});
user.getName(); // 'jim'

We can then imagine that after we've created a new instance, we save it to the database:

e.g.

await userRepository.add(user); // await = asynchronous flow of ES7

My question is about relational context between entities, imagine that our users has a oneToMany relation with projects .

// Create new project and save the project 
var project = new Project({id: 1});
await projectRepository.add(project);

// Create new user, add a project to the list, save the user
var user = new User({id: 1});
user.addProject(project.getId());
await userRepository.add(user);

In this example the relation between entities is handled manually, since the datastore used is a NoSQL database, and we have to reference the relation directly in our code. OOP languages such as JAVA can use ORM and allows you to do the following:

user.getProjects(); // [{ project_1_data }, { ... }];

Because the objects are mapped to the database, and because properties of objects can be other objects. A similar use case in Javascript looks like the following:

var projects = user.getProjects(); // [1, 2] list of IDs
await projectRepositories.get(projects[0]); // {...} data of the project

Am i wrong?

How would you represent the relation between multiple entities?

Should objects be in memory during the request runtime or should I just handle relation using IDs even in the domain models.

Please tell me if it's not clear enough. Best regards.

score 0 · Accepted Answer · edited May 23 '17 at 11:54

I think I read your question correctly, if so:

I represent relations either as sub documents or a list of IDs. The decision point there is how many other entities are going to need a relation to the sub document in question. In your example, if a user is the only entity that has those projects and projects are unique to users, I would keep the projects in a sub document of the user. However, it's likely that several users may be on the same project and perhaps there is a team entity that has all of the projects assigned to that team. In that case, you would need a lot of sub documents, have a lot of duplicated data, and you would introduce a requirement that every sub document be updated if say, the name of the project changed. If you keep the projects as a separate collection and reference the IDs, you only have 1 place to make that change. You may also need to make several calls into the DB to populate your entity depending on your document DBs support for join-like functionality. This might help for couch:

Best way to do one-to-many "JOIN" in CouchDB

If for instance you have a blog post with a series of comments, that would be a good use case for sub documents. Those comments are never going to belong to other users and they will never be comments for other posts. They are isolated to a blog post so you can think of the blog post and comments as a single document.

I know document DBs are all the rage, but personally when I have highly relational data, I don't hesitate to just use SQL. It's awesome. :D

Hope that helps.

ORM - Object relational mapping with Javascript

How would you represent the relation between multiple entities?

1 Answers1