I'm creating a Node app using MongoDB that allows users to submit reviews. There is also an admin portal to allow admin to read the reviews.
The reviews have a location field where the user is to fill in the location of the place they are reviewing. The admin creates these locations (cities) on their portal. Then, when the user wants to write a review, the app fetches all the locations created by the admin, puts them in a select box, and the user selects the location. The location is then saved along with the other details of the review.
Currently, I save the location field as Schema.Types.ObjectId in the Review collection. And then, populate the field, when I need to return the Review documents.
However, my Supervisor disagrees with this approach, wanting me to save the Review with just the name of the location.
His argument is that doing the population would be needlessly expensive, while mine is that, if there is a need to update the location details (say, a location name was misspelled...), the reviews would not reflect the new location details.
Which/who is correct? And what do you recommend for this problem?
One more consideration: One of the main/most frequent uses of the location data is to show the location distribution of the reviews to the admins (aggregation/filters)...
Actually, both are correct depending on certain situations.
Let's look at both perspectives.
One of the primary reasons for considering ID is due to it's immutable nature that it does not change overtime. Having said that, it's not necessary that you must use ID all the time, instead look for the immutable nature of a property which does not change overtime and consider it as Identifier of the object. This use case usually arises in static data models (for ex: cities in your case) where all you have is City Name as the property of the object, here you can store city names as Identifiers, for ex: New York can be stored as NEW_YORK.
Second approach, setting ID as the primary unique identifier of the object, is a standard and safe approach anytime with a compromise of being okay with overkill in the situations of static data models as mentioned above.
So in a nutshell, look for the immutable nature of the property and the possible of extending that data model in future; based on these two factors, you can go for the appropriate approach.
P.S. If population of cities is the concern, you can always introduce Application level caching(redis or memcached) or better, Network level caching(max-age: <expiration-seconds> header in the http response - do this only if you're sure that your http response wouldn't change before given expiration duration)
If you need any more help, let me know. Cheers!