English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Una query uno-a-uno significa che, quando cerchiamo i dati di un tavolo, dobbiamo anche ottenere i dati di altri tavoli.
Esigenza
Iniziamo con un piccolo esempio di esigenza di query uno-a-uno: supponiamo che, quando cerchiamo le informazioni di un ordine specifico, dobbiamo anche ottenere le informazioni dell'utente che ha creato quell'ordine. Il modello di tabella è il seguente (
ResultType
Scrittura della query SQL
Prima di tutto, dobbiamo analizzare le nostre esigenze. 1. Dobbiamo determinare quali due tabelle sono coinvolte in questa esigenza, quale è la tabella principale e quale è la tabella di relazione. Come determinare, è ancora una volta la esigenza - la nostra esigenza è che, quando si consulta l'ordine, si ottengano anche gli utenti che hanno creato quell'ordine. Allora è abbastanza ovvio. La nostra tabella principale è la tabella degli ordini (orders). E la nostra tabella di relazione è la tabella degli utenti (user).
In questo momento, possiamo scrivere la seguente query SQL:
select * from orders
In questo momento, dobbiamo considerare questo problema: quando facciamo la query di join, dovremmo usare il join interno o il join esterno? Per coloro che non sono chiari sulla differenza tra join interno ed esterno, qui faccio una breve introduzione, e più tardi, quando ho tempo, scriverò un blog dettagliato: il join interno mostra solo quelli che soddisfano le condizioni. Il join esterno si suddivide in join esterno sinistro e join esterno destro: il join esterno sinistro mostra tutto quello che è alla sinistra più quelli che sono uguali sulla destra; il join esterno destro mostra tutto quello che è alla destra e quelli che sono uguali sulla sinistra.
La nostra esigenza è quella di associare gli utenti attraverso gli ordini, poiché nella tabella orders c'è un foreign key (userId). Quando si consulta i dati della tabella associata user tramite il foreign key, userId è la chiave primaria della tabella user. In questo caso, possiamo ottenere solo una informazione di user, e questa registrazione non cambierà il risultato della nostra query principale. Pertanto, scegliamo la query di join interno. In questo momento, la nostra query SQL è così:
select * from orders, user where orders.user_id = user.id
Dopo aver completato la query, i risultati sono come segue:
In questo momento, c'è un problema, abbiamo scoperto che in questo momento ci sono due id, il che potrebbe causare problemi nel封装 dei dati in oggetti durante l'output. Inoltre, la colonna User_id è duplicata con i nostri dati di id utente. Dobbiamo migliorare il nostro sql. Come migliorare?
Poiché i dati della nostra tabella principale devono essere consultati integralmente, mentre per la tabella degli utenti abbiamo bisogno solo delle informazioni username, sex, adress (qui è un'ipotesi, non è necessario preoccuparsi di cosa sia necessario) allora dobbiamo specificare manualmente i campi di ricerca della nostra query SQL:
SELECT orders.*, USER.username, USER.sex, USER.address FROM orders, USER WHERE orders.user_id = user.id
Tutto ciò che precede è stato consultato tramite lo strumento di connessione SQL, quando possiamo visualizzare il database necessario, la nostra query SQL è stata stabilita. Ora dobbiamo iniziare il passo successivo:
Creare il pojo
Dobbiamo encapsulare i risultati della query nel relativo oggetto tramite il framework Mybatis. Allora, chi riceve i dati queryati? Se dobbiamo mappare i risultati della query sql al pojo, il pojo deve includere tutti i nomi delle colonne queryate. Ma né la classe Orders originale né la classe User possono mappare tutti i campi. In questo caso, abbiamo una soluzione semplice: scrivere una classe speciale per includere tutti i risultati della query e farla ricevere il set di risultati di ritorno.
In questo caso, c'è un piccolo trucco: non è necessario scrivere tutti i campi nel nuovo pojo, possiamo farlo ereditare un'altro tipo che contiene più campi del risultato della query, e scrivere altri dati necessari nel sottoclasse.
Dopo aver creato il pojo, dobbiamo creare il file di mappatura secondo le norme e scrivere i metodi corrispondenti nell'interfaccia:
mapper.xml
Interfaccia mapper.java
ResultMap
Sul lato della query sql, il modo di implementare resultType e resultMap è lo stesso, quindi salteremo questo passaggio.
L'idea di mappatura resultMap
Sappiamo che quando si utilizza un pojo, possiamo encapsulare alcuni dati nei campi dell'oggetto pojo, i quali possono essere di tipo semplice o un altro pojo. In questo caso, possiamo fare così:
Utilizzando resultMap, mappiamo le informazioni dell'ordine nel risultato della query all'oggetto Orders. Nella classe orders, aggiungere l'attributo User per mappare le informazioni dell'utente trovate nella query associata all'attributo user dell'oggetto orders.
Aggiungere l'attributo user nella classe Orders
mapper.xml
Quando si mappa il set di risultati utilizzando il metodo resultMap, è necessario eseguire due operazioni: una è definire il resultMap, impostare le proprietà degli oggetti corrispondenti alle colonne trovate nel set di risultati. Questo è un po' complicato ma non difficile. L'altra è definire il nostro statement.
resultMap
L'idea di base dell'implementazione di resultMap è stata detta prima. Inoltre, abbiamo aggiunto le proprietà corrispondenti nella classe pojo di orders. Ora, dobbiamo scrivere un resultMap per mappare l'intero risultato della query al tipo Orders. Al suo interno, prima di tutto, è necessario mappare l'ordine, che può essere fatto direttamente utilizzando i tag id e result per corrispondere i due. Poi, è necessario mappare le informazioni dell'utente associato, in questo caso è necessario utilizzare un tag association per mappare il campo user della classe orders con la classe User, e poi utilizzare i tag id e result all'interno di esso per mappare i dati della query con le proprietà dell'oggetto User.
具体代码如下:
<!-- 订单查询关联用户的resultMap 将整个查询的结果映射到cn.mybatis.po.Orders中 --> <resultMap type="cn.mybatis.po.Orders" id="OrdersUserResultMap"> <!-- 配置映射的订单信息 --> <!-- id:指定查询列中的唯 一标识,订单信息的中的唯 一标识,如果有多个列组成唯一标识,配置多个id column:订单信息的唯 一标识 列 property:订单信息的唯 一标识 列所映射到Orders中哪个属性 --> <id column="id" property="id"/> <result column="user_id" property="userId"/> <result column="number" property="number"/> <result column="createtime" property="createtime"/> <result column="note" property=note/> <!-- 配置映射的关联的用户信息 --> <!-- association:用于映射关联查询单个对象的信息 property:要将关联查询的用户信息映射到Orders中哪个属性 --> <association property="user" javaType="cn.mybatis.po.User"> <!-- id:关联查询用户的唯 一标识 column:指定唯 一标识用户信息的列 javaType:映射到user的哪个属性 --> <id column="user_id" property="id"/> <result column="username" property="username"/> <result column="sex" property="sex"/> <result column="address" property="address"/> </association> </resultMap>
statement
La statement è abbastanza semplice, è sufficiente modificare il modo di mappatura del set di risultati di ritorno in resultMap e impostare il tipo di ritorno su resultMap appena completato.
mapper.java
Le differenze tra i due
Dopo aver spiegato i metodi di implementazione della query uno-a-uno, analizziamo ora le differenze e i pro e contro di entrambi.
Prima di tutto, entrambi devono modificare il pojo, uno è aggiungere una classe pojo e l'altro è modificare i campi del pojo. Personalmente, secondo il principio dell'apertura e della chiusura del design pattern, resultType è migliore di resultMap.
In secondo luogo, in termini di semplicità, l'implementazione di resultType è relativamente semplice. Da questo punto di vista, resultType è anche migliore di resultMap.
Tuttavia, resultMap può implementare il caricamento differito, mentre resultType non può implementare il caricamento differito. In questo senso, resultType non è migliore di resultMap.
Quindi: si consiglia di utilizzare resultType se non ci sono richieste speciali di risultato di ricerca.
Come sopra descritto, l'autore ha introdotto la funzione di query uno-a-uno di mybatis a tutti voi, sperando che sia utile. Se avete qualsiasi domanda, lasciate un messaggio, l'autore risponderà prontamente. In questo senso, anche ringraziamo tutti i sostenitori del sito web di urla tutorial!
Dichiarazione: il contenuto di questo articolo è stato tratto da Internet, il copyright spetta ai rispettivi proprietari, il contenuto è stato contribuito e caricato autonomamente dagli utenti di Internet, questo sito non detiene i diritti di proprietà, non è stato editato manualmente e non assume alcuna responsabilità legale. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare una e-mail a: notice#oldtoolbag.com (al momento dell'invio dell'e-mail, sostituisci # con @) per segnalare il problema e fornire prove pertinenti. Una volta verificata, questo sito eliminerà immediatamente il contenuto sospetto di violazione del copyright.