Relationships
One to One
Example : Student has one to one relationship with Address
In NO-SQL address data is embedded along with student while in SQL student and adress can be stored in different tables and joined with addressId column in RDBMS
To replicate this relationship
- Create a schema for student and add studentId
- Create a schema for Address
- Create a property in student schema for address
If your store selection is NO-SQL there is not need for any addressId and API can be genreated, but while choosing RDBMS it is needed
One to Few
Example : Order has few orderlines and Course has few course items although this is a subset of one to many, approach to handle is slightly in different.
To replicate this relationship
- Create a schema for Order and add orderId
- Create a schema for Orderline
- Create a property in Order schema for orderline with Orderline and mark as list
In No-SQL databases one to few will be considered as embedded relation, while in Sql it will be considered as One to Many relationship with orderId as join key in the given example
One to Many
Example : Department has one to many relationship with students. One to many leads to fetch on lot of records in RDBMS and embedding approach in NO-SQL databases will lead to limitations.
Instead the preferred approach would be to have many to one relation ship from student to department and if any filters are required on department, filters can be applied on select all of students api
Many to One
Example : Student has many to one relationship with department.
While creating student schema, departmentId can be added and department can be referenced as many to one relationship at schema level. These references will not need inserts / updates in API.
Many to Many
Example : Students and Course have may to many relationship. Although RDBMS systems support many to many relationship, and it is often treat via 3rd normal form with an additional entity enrollment or registrations
While designing in radical, this 3rd normal form entity is preferred i.e Many to Many is avoided and instead becomes many to one relationship.
Steps to for achieving registrations
- Add a student schema with studentId as key
- Add a course schema with coureseId as key
- Add a schema for registration, with student and courseId. Also add references of student and course and make them as references via many to one in advanced options.
- Add API's for registration, this allows CRUD and other operations on registrations
Here registration is infite i.e a student can register to any number of courses. If a students has a upper limit then to one many with List<Course>
can be used.