# Design the Initial ERD of ScholarX

**URL:** https://sef.discourse.group/t/design-the-initial-erd-of-scholarx/72
**Category:** ScholarX
**Created:** [May 13, 2020, 2:13am UTC](https://sef.discourse.group/t/design-the-initial-erd-of-scholarx/72 "2020-05-13T02:13:36Z")
**Posts on this page:** 1
**Showing post:** 30

<div class="post-metadata">

### Author: ![YohanAvishke](https://yyz2.discourse-cdn.com/free1/user_avatar/sef.discourse.group/yohanavishke/32/106_2.png) [@YohanAvishke](https://sef.discourse.group/u/YohanAvishke)
#### Post date: [August 10, 2020, 9:18am UTC](https://sef.discourse.group/t/design-the-initial-erd-of-scholarx/72/30 "2020-08-10T09:18:37Z")

</div>

Hi, I did some research on finding the best approach for database initialization and data management.  
SpringBoot recommends any of the following ways to initialize the database,

- JPA, Hibernate, basic SQL scripts  
There is no logical difference between these approaches. And the approach that one should use completely depend on the technologies of the project itself.

But however, since the main reason we are trying to use basic SQL scripts is the issue with Cascading, I did some further digging to check if it’s recommended to use the Cascading on the script itself.  
And the approach is not recommended because

> Hibernate doesn’t know which records the cascading operation on the database removes. It can’t remove any entity that maps one of the removed records from the 1st or 2nd level cache. Due to this, you are at a high risk that your caches contain outdated information (records that no longer exist).

In other words, the SpringBoot database cache can get invalidated and we will be forced not to use the `EntityManager `.

So the best approach would be as follows,

- Let the database initialization through JPA Entities without adding Cascading to any of the `to many` relationships.
- When a bulk removal is needed(Eg: Removing children of a parent) write native SQL scripts in the Repository to provide the functionality.

This approach will solve the above mentioned caching problem and the following 2 problems,

1. When using JPA delete with Cascade for a `to many` relationships, a huge number of SQL scripts will be executed.
2. When using JPA delete with Cascade for a `many to many` relationships, a chain removal might occur and might end up removing all the data.

References:  
i. [https://docs.spring.io/spring-boot/docs/2.3.2.RELEASE/reference/html/howto.html#howto-database-initialization](https://docs.spring.io/spring-boot/docs/2.3.2.RELEASE/reference/html/howto.html#howto-database-initialization)  
ii. [https://thorben-janssen.com/avoid-cascadetype-delete-many-assocations/](https://thorben-janssen.com/avoid-cascadetype-delete-many-assocations/)

WDYT about the above approach?

---

_[View the full topic](https://sef.discourse.group/t/design-the-initial-erd-of-scholarx/72)._