Creating A MongoDB Database For Movie Maniacs

Example movie document

We have only one collection MOVIES that contains a number of Movie documents. Each movie document has the attributes related to it like MovieId, MovieName, Director, Leading actors etc. Apart from all these attributes that are provided by us, there is another attribute _id. This _id is a primary key attribute and it acts as a unique identifier. This _id attribute is provided by the Mongo DB itself.

Movies are related to their RATINGS. There is a One to Many relationships among the Movies and their ratings. Each movie can have zero or more ratings but each rating is related to one and only one Movie. These Ratings are embedded inside the Movie documents and do not exist as a separate collection. This RATING attribute exists for only those movies which have some rating associated with them and not for the other movies.

Whenever any movie is deleted, all the ratings associated with it are also automatically deleted and one rating cannot be shared among different movies.

Example movie document:-

db.MOVIES.insert(

        “MovieID”: 1,

        “MovieName”: “2001”,

        “Director”: “Stanley Kubrick”,

        “Leading actors”: “Daniel Richter, Gary Lockwood, Keir Dullea, William Sylvester”,

        “ReleaseDate”: “1968”,

        “OscarsWon”: “1”,

        “Country”: “USA”,

        “RATINGS”:

                “ReviewedBy”: “Joe”,

                “Date”: “6/15/18”,

                “Rating”: 9,

                “Comments”: “The best ever!”

                “ReviewedBy”: “Howie”,

                “Date”: “6/9/18”,

                “Rating”: 7

Indexes created for the Database:- 

1. We have created the following index:- 

db.MOVIES.createIndex(

        “MovieID”:-1,

        “Country”:1

This index is a combination of two attributes of Movie collection. MovieId and Country are a part of this Index. “MovieID”:-1 denotes that we are using descending order for MovieID while creating this index. Similarly, “Country”:1 denotes that we are using ascending order while creating this index. Indexes play a very crucial role in improving the performance of our queries. As we have only 25 documents for no in our collection, these differences in performance are not noticeable. But as our database size will grow and the number of documents in our collection will rise, there will be a large improvement in the execution of queries because of these indexes.

Handling of relationships in the database:- 

We have a One to Many relationships between our Movie documents and the Rating documents. Each movie can have Zero or Many Ratings related to it whereas each Rating can only be associated with one and only one Movie. We have used the embedded approach for handling this relationship. So the Rating documents do not exist as a separate collection but they are an integral part of the Movie documents with which they are associated.

These rating documents do not even have the unique identifier (_id) associated with them as Mongo DB only provides this identifier to the root document. The rating documents are strongly associated with the Movie documents. So if any movie document is deleted then all the rating documents associated with it are automatically deleted. 

Alternatives to how the relationships could have been modelled and implemented in MongoDB:-

There are two methods of handling relationships in MongoDB.

1. Embedded Approach:-

            We have used this approach to handle the relationships in our database. In this approach, the document contains all the inner objects/documents embedded in it. The inner documents do not have any unique identifier given by Mongo DB. All the inner documents reside inside the outer document, so these are automatically deleted as soon as the outer documents are deleted. The inner documents are stored as an array of documents inside the main outer document.

Advantages of Embedded Approach:-

1. a) They need fewer queries and updates as one query fetch the main document with all the embedded documents inside it. So it improves the read performance by queries.
2. b) Embedded documents and arrays reduce the need for expensive joins and hence significantly improve the performance.

1. c) All the embedded documents are automatically deleted when the outer document is deleted.

Issues of Embedded Approach:-

1. a) As the size of documents is large, so it causes performance issues for writes.

1. b) MongoDB has a limit that maximum document size can be 16MB. When several inner documents are embedded inside the outer document then the size of our document can increase beyond that.

1. c) There may be inconsistency among the inner documents if embedding requires duplication of some inner documents. In such cases, there might be issues like some of the inner documents are left while other duplicate documents are updated.

1. Normalized Approach:-

            In this approach, all the related documents exist as separate collections. We do not store the original documents inside outer documents but instead of that we just store references to these documents. All the inner documents are also a part of the separate collection. They can exist without the outer documents. Mongo Db provides the unique identifier (_id) to all these documents. So, one inner document can be referenced by multiple outer documents without any duplication of data.

Advantages of Normalized Approach:-

1. a) These are good to use when embedding would result in duplication of data but do not provide sufficient read advantage. 

1. b) We do not need to worry about the size limit of 16MB as all the inner documents are separate documents and only their reference is stored inside the outer document. 

1. c) Writes are faster in the normalized approach as compared to the embedded approach. 

Issues of Normalized Approach:-

1. a) Mongo Db does not support joins, so making the calls to such databases require two different calls. The first call just retrieves the references and then we have to make a separate call to obtain documents from these references.

1. b) Reads in such databases take a very large time as compared to reads on embedded databases.

Recommendations to Movie Maniacs for any additional functionality for the database:- 

1. We can add the classification attribute to our movies document. So the user can easily know about the classification of the movie. 

1. We can add a description field and add the information about the movie story in it. 

1. We can provide various locations to the user where the user can go and access the movie. 

References

Alam, M. (2014) Oracle NoSQL database. New York: McGraw-Hill Education/Oracle Press.

Copeland, R. (2013) MongoDB applied design patterns. Sebastopol, CA: O’Reilly Media, Inc.

Dayley, B. (2015) Sams Teach Yourself NoSQL with MongoDB in 24 hours. Indianapolis, Ind.: Sams.

Eliot, G. and Ashton, R. (2018) The mill on the floss. [Nederland]: Penguin Books.

Francia, S. (2012) MongoDB and PHP. Beijing: O’Reilly.

McCreary, D. and Kelly, A. (2014) Making sense of NoSQL. Shelter Island: Manning.

Perkins, L., Redmond, E. and Wilson, J. (2018) Seven databases in seven weeks. Raleigh, N. C.: The Pragmatic Bookshelf.

Vaish, G. (2013) Getting started with NoSQL.