Uso di MySql 5.7 Colonne JSON per EAV

7

Sto sviluppando un prodotto di e-commerce e sono stato in grado di implementare tutte le funzionalità e mi è stato concesso di consentire agli utenti di creare attributi aggiuntivi per un prodotto. In questo momento ho due opzioni.

EAV

EAV è in gran parte disapprovato, ma sembra funzionare per Magento. Ma dopo aver cercato tutti i mal di testa che causa sono un po 'riluttante ad usarlo

Usa colonne JSON in MySql 5.7

Questo è piuttosto nuovo e non ho visto che sia implementato da nessun'altra parte e sto temendo scansioni complete della tabella come risultato dell'interrogazione degli attributi JSON. Ma dopo aver letto questo MySql 5.7 JSON sembra raccomandare l'uso di JSON. e sarebbe meno faticoso di implementare qualcosa come questo Pratico Consigli sullo schema MySql .

La mia domanda è, anche se sono incline all'utilizzo della colonna JSON per memorizzare gli attributi dato che NoSQL non è un'opzione per me, ci sono degli svantaggi più gravi rispetto all'utilizzo delle tabelle EAV.

    
posta Madawar 29.01.2016 - 14:44
fonte

1 risposta

1

Né EAV né la scelta di una colonna JSON sono approcci sbagliati nel tuo caso, ma quale è meglio per te dipende da cosa vuoi fare con i dati una volta memorizzati nel database.

Se tutto ciò che si desidera è avere un prodotto con attributi definiti dall'utente e si desidera leggere il prodotto nel suo insieme, il modo JSON fornirà prestazioni migliori per te, poiché l'intero prodotto si troverà all'interno di uno stesso tabella, puoi semplicemente decodificare il JSON recuperato dal database e utilizzarlo come preferisci sul frontend.

Se vuoi comunque non solo leggere il prodotto nel suo insieme ma, con una visione futura, magari introdurre la possibilità di filtrare i prodotti con determinati attributi (diciamo a colori), l'utilizzo dell'approccio EAV aumenterebbe le prestazioni di questa operazione , poiché puoi filtrare prodotti i cui nomi di attributi corrispondono direttamente a quelli che stai cercando.

SELECT
    pa.ProductId
FROM
    product_attributes pa
WHERE
    pa.'Name' = "color"

Se si dispone di questa funzionalità con la colonna JSON, il modello dell'attributo JSON utilizza più risorse rispetto alla diretta stringa comparativa.

Come sviluppatore del backend API REST per applicazioni mobili, un esempio con cui lavoro spesso fornisce all'utente una panoramica delle notifiche push ricevute tramite un centro notifiche all'interno del client mobile.

Poiché non sto pianificando di eseguire query frequenti sui dati su base frequente, la colonna JSON è completamente valida. Voglio solo fornire i dati esistenti in diversi formati all'utente quando lo interrogano, quindi prendo i dati dal database e li scarico all'utente. È ancora meglio perché la superficie delle API REST è JSON, quindi non mi è nemmeno richiesto di eseguire alcuna formattazione aggiuntiva come dovrei fare nel caso di un modello EAV.

    
risposta data 20.11.2016 - 18:12
fonte

Leggi altre domande sui tag