davislf2
davislf2

Reputation: 77

MongoDB and Node.js design or refactoring

I have received a legacy project, and the system uses simple two-layer structure: buildings -> zones to store every data. My mission is to POST data to all selected areas and sub-areas. However, I am told to develop extensively for future consideration of the different type of buildings. Therefore, I want to add two new layers to this structure. The terms in parentheses in the following structure are what I want to add:

buildings -> (AHU) -> zones -> (sub-zones)

It means the previous structure is "William Street" (collection) -> "AHU-B-Z1"

The new structure will look like "William Street" (collection) -> "AHU-B" -> "Z1" -> "A"

The structure of existing buildings collection looks like this:

{ zone:
   [ { precooling: [Array],
       name: 'AHU-B-Z1',
       _id: 5aa96e045104165bc96916e8 },
     { precooling: [],
       name: 'AHU-B-Z2',
       _id: 5aa91e6412c17df1f81371d3 },
     { precooling: [],
       name: 'AHU-B-Z3',
       _id: 5aa9f1e6412c17df813171d2 } ],
  _id: 5aa6596e04510bc9694116e7,
  name: 'William Street',
  coordinate: [ 14.2, -19.1 ],
  yearlyEnergyCost: 100000,
  __v: 17 }

However, the whole Node.js project is based on the logic of building/zone. For example,

router.get("/building/:buildingid/zone/:zoneid", controllerZone.getOneZone);
router.route("/building/:buildingid/zone")
    .get(controllerZone.getZone)
    .post(controllerZone.postZone);

How can I redesign the DB and Node.js more efficiently? Is there any better way to modify this structure with fewer efforts? Thanks.

Upvotes: 0

Views: 170

Answers (1)

Hans Yulian
Hans Yulian

Reputation: 1180

before we start, remember that there is no right or wrong, it's just either good or bad. As far as I am dealing with mongodb and nodejs alot in the past few years, i notice that these are the best practices appears for me:

  1. If the data was previously from an RDBMS structure, retain from using nested structure especially one to many or even many to many relationship in mongodb even though mongodb support it. The project i ran come to alot of problem when trying implementing this, so? use back the RDBMS structure? as long as it is something that might getting a heavy query, then better be.
  2. If data is from one to one relation in RDBMS structure, or something that can be stated as a new object in any programming language, for example: coordinateX, coordinateY, we can make this into a single object coordinate. paddingLeft, paddingRight, etc can become a padding. it's fine to make it into a single object, nested in mongodb document to make it neat and easy to be deserialized by even strict programming languages
  3. Data that most likely not getting heavy query, for example: logs, audit, and so on are fine to ignore the 1st condition.
  4. You can still put the reference id of a relation in mongodb, just fine anyway.

In this case, my advise for your data is to be split to 2 collection: building and zone. In the building, put an id and for zone, put buildingId as reference. Coordinate can be made into a json object inside building:

coordinate: {
   long: 123
   lat: 123
}

Hope this help

Upvotes: 1

Related Questions