This shows the various options I found for representing relations in OOP languages. This is for obtaining opinions from people on what style(s) is preferred.

RelationsInOop.kt

/**Option-1**/
data class Tag (val id: Long, val name: String, val icon: Int)

// subTasks contains tasks themselves.
data class Task(val id: Long, val name: String, val tags: List<Tag>, val subTasks: List<Task>)



/**Option-2**/
data class Tag (val id: Long, val name: String, val icon: Int)

// subTasks contains ids of the tasks.
data class Task(val id: Long, val name: String, val tags: List<Tag>, val subTasks: List<Long>)



/**Option-3**/
data class Tag (val id: Long, val name: String, val icon: Int)

// subTasks is not there in the class.
data class Task(val id: Long, val name: String, val tags: List<Tag>)

I see the following pros and cons in the following approaches:

Option-1

Pros

• The design is more 'object-oriented' and intuitive

Cons

• It is really difficult to use with a relational db
• I'm forced to load all the sub-tasks every time I load a task even if I don't access the sub-tasks field at all
• The above problem is worsened because each of those sub-tasks may have their own sub-tasks

Option-2

Pros

• Since we only store ids, we've to load less data

Cons

• Storing ids feels like dealing with relational model rather than object oriented model

Option-3

Pros

• The structure matches that of entities/tables in our db
• Each individual object is small

Cons

• We've to use other methods of accessing sub-tasks. For Eg: by having methods of the form getSubTasksForTask(task)
• The Task class itself tells us nothing about the existence of the concept of sub-tasks