Mysql
 sql >> Database >  >> RDS >> Mysql

Persistere dati non primitivi in ​​JPA

OK, ecco,

Presumo che tu stia creando la tua applicazione con Spring Boot, Hibernate come ORM e probabilmente un database relazionale (MySQL).

Per quanto riguarda il design db:

Sì, l'oggetto Patreon qui è l'entità proprietaria con una relazione OneToMany con l'entità Item (poiché un Patreon può avere N oggetti). La tua entità Patreon potrebbe fare con il seguente ridesing:

1) Prova a utilizzare tipi non primitivi soprattutto per le chiavi della tabella (ID lungo -> ID lungo).

2) Perdi l'array di CheckOutItems e l'elenco itemHistory. Prima di tutto le relazioni dovrebbero essere modellate usando collezioni e non array. In secondo luogo non hai bisogno di quei due. Non memorizzerai mai i CheckOutItems né l'itemHistory in questo modo. Crea invece un List<Item> items che memorizzerà gli elementi Patreon mentre descrive la relazione (ecco alcuni esempi:http:/ /www.baeldung.com/hibernate-one-to-many )

3) Sempre con l'entità Item è necessario perdere l'array della cronologia. L'unica cosa di cui hai bisogno è un riferimento all'entità proprietaria (Patreon in questo caso) completando così il lato ManyToOne della relazione.

4) Nota che i campi Data devono essere annotati con @Temporal fornendo anche il tipo corretto (puoi leggere di più).

5) La classe dell'oggetto in generale dovrebbe avere a che fare con una riprogettazione.

5) Dopo che tutto quanto sopra è a posto e supponendo che tu stia usando Spring, puoi creare un Repository con il quale puoi interrogare un oggetto Patreon recuperando così un oggetto insieme alle sue entità correlate (Items).

Per quanto riguarda le tue domande:

Q1:Sì, si vede. Vedi sopra per ulteriori informazioni.

Q1.2:Nessun array non lo è. Liste o meglio ancora Set sono più adatti.

Q1.3:Sì, c'è. La prima è un'annotazione JPA utilizzata nei database relazionali mentre la seconda è un'annotazione specifica di Spring Data utilizzata da database e framework che non sono di questo tipo (relazionale) o non hanno un'API di persistenza standard definita (come JPA). Perché NonNull e NotNull sono più o meno gli stessi con il primo che sostituisce effettivamente il secondo (cosa che viene eseguita spesso). L'unica differenza che vedo è l'obiettivo. Puoi leggere di più qui:https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/lang/NonNull.html https://docs.oracle.com/javaee /7/api/javax/validation/constraints/NotNull.html

Q2:Sì, c'è. Vedi sopra.

Q3:Con un po' di design intelligente non vedo la necessità di altro, ma se pensi che ti aiuterà, perché no. Basta non esagerare con il design e la sua complessità