NoSQL newbie - modelling golf course data

I am new to NoSQL. I have experience of RDBMS systems and structures, but also by no means a DBA or app developer…

I am a hobbyist / enthusiast, and I am looking to deploy a new iOS app tied to a Parse server backend, using MongoDB. I am thinking through the data model required, and I default to relational data structures…

I would like to model recording golf competitions. Simplistically, a competition is a:

  • Round of golf

  • On a specific course

  • On a specific day / date

Typically, I would have tables to define the Course(s) and 1:Many Hole table linked to each Course.
CourseID
CourseName
CoursePar

HoleID
HoleNo
HolePar
HoleSI
HoleCourseID

Separately, I would store Round in a different table, with a foreign key back to Course. This starts needing many links between tables to perform queries, aggregation, etc. Simply put a Player plays a Round (another 1:Many relation).

Should I instead create rows for each hole recorded, that ALSO has the Course data in it, so each row can perform it’s own queries & aggregation?

Row1:
RowID, HoleNo, CourseID, HolePar, HoleSI, HoleGrossScore, HoleNettScore, etc, etc

Then I may not even need the Course & Hole tables?

Hello and welcome to MongoDB community.

So, the main purpose of the application is to collect the above data - a golf competition related data.

And, then use it for what? What are your main and most used queries? So, your application has a main screen showing somethings and main options to show some details. What are those and important ones? These questions are to drive (not the golf play drive) the design and modeling of data.

Competitions are played on a course with holes. Many players play in a competition. Many rounds are played during competition - and players play and there is an outcome for each round. This is general information, the entities and attributes involved.

Tables or entities, keys, relationships are associated with data and how it is modeled. It is important to figure the application and its main purpose / functions / features - then think about modeling, storing and queries.

You may have looked at this already, but here is a MongoDB documentation link to Data Modeling Introduction.

Thanks @Prasad_Saya for the reply.

There will be 2 primary purposes:

  • Live leaderboards of a Competition, while in progress - so querying from a Competition perspective

  • Player history, a record of all rounds played - I expect mostly per Player but also to aggregate scores together. So this would be querying from the Player perspective

In Parse, I don’t believe you can do nested documents - though I could very well be wrong! It has “Pointers” (1:Many) and Relations (Many:Many) links to other “Classes” (i.e. documents).

Should I be thinking more about what my app actually does, rather than ensuring optimal data storage (i.e. normalization, etc)?

My current entity relationship has multiple tables just to cover Golf Clubs, Courses, Holes. A table for Round. Then add in a join table between Player and Round for the Many:Many relationship.

I wonder if the recording of the course data could simply be ignored in the database - the app would need to know this, but could be downloaded from a JSON data source(?). As a hole is played, it writes all the relevant data for that hole into the database, including:

  • HoleNo
  • ClubName (taken from JSON)
  • CourseName (taken from JSON)
  • HolePar (taken from JSON)
  • HoleSI (taken from JSON)
  • Score

In this way, I would not have to do the multi-table linking in queries to do anything with the data - all the data is available within this document (Parse Class object) to perform queries / calculations / processing. And then group 18 rows of Score entries to make up my entire Round.

Is this an example of a “NoSQL approach”? Or at least a less RDBMS-based approach?

@Dan_Burt just some thoughts.

Should I be thinking more about what my app actually does, rather than ensuring optimal data storage (i.e. normalization, etc)?

Normalization or de-normalization is modeling data. It should serve the purpose of the application functionality, I think. Data modeling is an aspect of application design. MongoDB’s flexible schema allows de-normalization - you can model data such that the related data can be stored and queried together.

De-normalized data has advantages over normalized data - performance and lesser code. Joining tables for queries can affect the performance the wrong way.

For example, lets take course and holes data. A course has 18 (or sometimes 9) holes. This can be stored in a de-normalized form as shown below. Querying information about a hole (or holes) in a course has all the related information without a join.

courseID
courseName
coursePar
holes [ 1.. 18 array of holes]
  holeID
  holeNo
  holePar
...

An example of a normalized data:

A round and player are two entities. A round is played by 2 or more players. The player entity can store all the details (the id, name, address, history, …). But, the round can store some basic player details (e.g., name, city). So, when you query about a round, the query accesses only the round data with basic player info. If more details are needed about the player, then an additional query is made to get the player data.


Is this an example of a “NoSQL approach”? Or at least a less RDBMS-based approach?

It is an approach, alright. But, after storing this data, what kind of queries are run on this data (is to be figured)?

The above discussion about normalized / de-normalized is about the NoSQL design approach. It blends, giving more options to work with data.