Relazione N-1-N Tra 3 Tabelle: Perchè Gestrla Con Many_Many ?

International Italian
1

Cerco di spiegarmi meglio

Listings [N <-> 1] ListingItems [1 <-> N] Items

col risultato che ogni listino ha N item e ogni item può far parte di N listini.

Ho visto parecchi esempio in giro di casi come questi, ed una gran parte di questi seguono questa strada:

  • NON creano neppure il model di ListingItems

  • Definiscono in Listings una relazione MANY_MANY direttamente con Items, tipo così:




'items' => array(self::MANY_MANY, 'Item', 'tbl_listingItems(listingId, itemId)'),

Vi chiedo i pro e i contro.

La mia opinione è che NON si deve mai hard-codare il nome di una tabella.

A parte questa questione, ho paura a seguire questa strada, perchè non so dove conduce. Se limita o se in realtà dà delle comodità che altrimenti non avrei.

2

Ciao realtebo,

Premetto che non sono molto pratico di yii, ma ho avuto lo stesso problema con doctrine2.

L’approccio di non preoccuparsi della tabella intermedia credo sia quello migliore: dovrebbe essere il sistema a doversi preoccupare di creare e popolare la tabella intermedia, e anche l’estrazione delle collezioni di dati dovrebbe essere trasparente all’utente.

Solo nel caso in cui si ha una relazione many2many con attributo mi sono trovato costretto a creare la tabella intermedia ed a trasformare la relazione in 2 relazioni one2many e many2one ma credo siano casi un pò particolari e cms non saprei gestiti in maniera differente

Ciao

Mojo

3

A me non piacciono le many many, preferisco fare 2 relations.

Con l’approccio many many non puoi accedere ai campi della tabella ponte, come discusso in questo post.

Usare 2 relazioni comporta il fatto che vengono eseguite due query separate, se ti serve migliorare l’efficienza usa with per ridurle ad una.

Se usi la many many non hai il modello per aggiungere-togliere abbinamenti, devi sare dao per questo.

4

grazie per entrambi i consigli.

Preciso che le tabelle a regime saranno di poche decine di righe ciascuna, quindi non avrò problemi di performance… spero !

Quello che dovrò fare è di permettere all’utente dalla form dei listini di spostare aggiungere e rimuovere continuamente degli articoli … non chiedetemi perchè, sto cliente ha necessità strane … ma verrà comunque fatto solo all’inizio dopo l’installazione, per cui questa volta voglio stare comodo io come programmatore, poi penserò a fare l’interfaccia usabile all’utente.

Quindi, in breve, con la tabella intermedia (a cui non posso rinunciare per motivi di design che non mi competono), conviene usare la strada delle due relazioni N-1 e 1-N per raggiungere a da b e viceversa?

In fase di salvataggio abbinamento, dovrò creare a mano un nuovo record nella tabella intermedia…

uhm… mi sa che dovrò pensare bene alla GUI sta volta…

5

A titolo di conferma: avendo queste relazioni …

Listings [N - 1] ListingItem [1 - N] Item

… io imposto così le relations … giusto ?

Listings




"listingItemObj" =>  array(self::HAS_MANY, "ListingItem", "listingId"),

ListingItem




"listingObj" =>  array(self::BELONGS_TO, "Listing", "listingId"),

"itemObj" =>  array(self::BELONGS_TO, "Item", "itemId"),

Item




"listingItemObj" => array(self::HAS_MANY, 'ListingItem', 'itemId' ),
6

Confermo. Vedi il post che ti ho linkato per dei consigli su come fare gli abbinamenti.

7

grazie alla tua domanda ho soddisfatto anche un mio dubbio ;) io personalmente creo il model intermedio per un riscontro nel db delle associazioni presenti… viceversa, se ho capito bene, dovrei fare queste verifiche via codice… o sbaglio?

8

Se non hai il model devi usare il Dao

9

… qui parli arabo …

10

Il dao e’ l’accesso diretto, quello che fai con Yii::app()->db->createCommand-> ecc ecc