Attributo di entità Valore Database vs rigide Modello Relazionale e-commerce

È sicuro di dire che il EAV/CR modello di database è male. Detto questo,

Domanda: Che modello di database, di una tecnica o modello deve essere utilizzato per affrontare le “classi” di attributi che descrivono prodotti di e-commerce che può essere modificato in fase di esecuzione?

In un buon E-commerce, database, potrete memorizzare le classi di opzioni (come la risoluzione della TV quindi hanno una risoluzione per ogni TV, ma il prossimo prodotto non può essere di una TV e di non avere “la risoluzione della TV”). Come si fa a memorizzare loro ricerca in modo efficiente, e consentire agli utenti di impostare i tipi di prodotto con campi variabili che descrivono i loro prodotti? Se la motore di ricerca trova che i clienti in genere ricerca per la Tv basata sulla console di profondità, si potrebbe aggiungere console di profondità per i campi, quindi aggiungere una profondità unica per ogni tv tipo di prodotto in fase di esecuzione.

C’è una bella caratteristica comune tra buon e-commerce applicazioni dove si mostra una serie di prodotti, quindi sono “drill down” sul lato menu dove è possibile vedere “la Risoluzione della TV” come intestazione, e i cinque più comuni TV Propositi per il gruppo trovato. Si fa clic su uno e si mostra solo Piatto della risoluzione, permettendo di eseguire il drill down selezionando altre categorie del menu laterale. Queste opzioni sarebbe la dinamica del prodotto attributi aggiunti in fase di esecuzione.

Ulteriore discussione:

Così lunga storia breve, ci sono i link su Internet o modello descrizioni che potrebbero “accademicamente” risolvere la seguente configurazione? Ringrazio Noel Kennedy, suggerendo una tabella di categoria, ma il bisogno di essere più grande di quello. Ho descritto un modo diverso di seguito, cercando di evidenziare il significato. Ho bisogno di un punto di vista di correzione per risolvere il problema, o potrebbe essere necessario andare più in profondità nel EAV/CR.

Amore di risposta positiva l’EAV/CR del modello. I miei compagni di tutti gli sviluppatori dicono che cosa Jeffrey Kemp toccato sotto: “la nuova entità deve essere modellati e progettati da un professionista” (prese fuori dal contesto di leggere la sua risposta qui sotto). Il problema è:

  • entità aggiungere e rimuovere gli attributi settimanale
    (parole chiave di ricerca dettare il futuro attributi)
  • nuove entità arrivare settimanale
    (prodotti sono assemblati con parti)
  • vecchio entità andare via settimanali
    (archiviato, meno popolare, stagionale)

Il cliente vuole aggiungere attributi di prodotto per due motivi:

  • dipartimento /ricerca per parole chiave /tabella di confronto tra prodotti simili
  • prodotto di consumo di configurazione prima di checkout

Gli attributi devono avere un significato, non solo una ricerca per parole chiave. Se si desidera confrontare tutti i dolci che hanno un “panna montata, glassa”, possono fare torte, fare clic su di compleanno a tema, fare clic su panna montata, glassa, quindi controllare tutte le torte che sono interessanti, sapendo che tutti hanno panna montata, glassa. Questo non è specifico per torte, solo un esempio.

  • questo è gonna ottenere grezzi
  • Perché non si può avere solo una ‘categoria’ tabella con una chiave esterna che si riferisce a se stesso?
  • Non è sicuro, né preciso, a dire che l’EAV modello di database è un male, perché è anche adatto per alcune applicazioni.
  • Che cosa succede se si decorare vari oggetti con proprietà diverse, ereditare da un genitore come Entity Framework 4? Come si fa a non persistere di tali oggetti?
  • Appena tornato al punto di questo eccellente articolo di circa un consulente di esperienza con un sistema basato su una versione estrema del EAV. Leggi! simple-talk.com/opinion/opinion-pieces/bad-carma
  • L’EAV è una soluzione molto valida modello di database. Sto lavorando su un problema simile, come voi, e la soluzione è EAV. Vorrei raccomandare il seguente articolo: sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/…

InformationsquelleAutor Zachary Scott | 2009-05-15



10 Replies
  1. 74

    Ci sono alcuni pro e contro che mi vengono in mente, ci sono situazioni in cui uno è meglio dell’altro:

    Opzione 1, EAV Modello:

    • Pro: meno tempo per progettare e sviluppare una semplice applicazione
    • Pro: nuove entità facile aggiungere (potrebbe anche
      essere aggiunti dagli utenti?)
    • Pro: “generica” di componenti di interfaccia
    • Con: complesso di codice necessarie per convalidare tipi di dati semplici
    • Con: molto più complesso di SQL per il semplice
      report
    • Con: complesso di rapporti che possono diventare quasi
      impossibile
    • Con: scarse prestazioni per grandi insiemi di dati

    Opzione 2, la Modellazione ogni entità separatamente:

    • Con: più il tempo necessario per raccogliere i
      il progetto e i requisiti
    • Con: nuovi enti dovranno essere modellato e
      progettato da un professionista
    • Con: interfaccia personalizzata componenti per ogni
      entità
    • Pro: tipo di dati vincoli di convalida e di semplice attuazione
    • Pro: SQL è facile da scrivere, facile da
      capire ed eseguire il debug di
    • Pro: anche il più complesso dei rapporti sono relativamente semplici
    • Pro: migliore performance per grandi insiemi di dati

    Opzione 3, Combinazione (modello entità “correttamente”, ma aggiunge “estensioni” per gli attributi personalizzati per alcune/tutte le entità)

    • Pro/Contro: più il tempo necessario per raccogliere i requisiti e design rispetto all’opzione 1, ma forse non come opzione 2 *
    • Con: nuovi enti dovranno essere modellati e progettati da un professionista
    • Pro: nuovi attributi possono essere facilmente aggiunti in un secondo momento
    • Con: complesso di codice necessarie per convalidare tipi di dati semplici (per gli attributi personalizzati)
    • Con: interfaccia personalizzata componenti ancora necessaria, ma generico componenti dell’interfaccia può essere possibile per gli attributi personalizzati
    • Con: SQL diventa complesso appena attributo personalizzato è incluso in un report
    • Con: buona prestazione in generale, a meno che non si avvia bisogno di una ricerca o un report gli attributi personalizzati

    * Non so se l’Opzione 3, necessariamente, salvare qualsiasi momento, in fase di progettazione.

    Personalmente ho propendono per l’opzione 2, e di evitare di EAV, ove possibile. Tuttavia, in alcuni casi gli utenti hanno bisogno di una flessibilità che viene fornito con l’EAV, ma questo è un grande costo.

    • Se hai avuto un unica tabella con gli indici per i valori di testo 1-n, quindi in C# (in ram) la mappa che si desidera ciò di cui avete bisogno. Ancora funzionerebbe come un EAV, ma “partite” sarebbe di modelli di dominio. Come una sorta di serializzazione, ma è possibile utilizzare SQL seleziona indicizzate campi di testo. Non più seleziona per ogni record. Tutti i “costi” accade in RAM.
    • che suona più o meno come l’opzione 3. Ogni riga è 1-n extra “generico” colonne, e i dati in essi viene interpretato a livello di applicazione. Si ottiene il beneficio di prestazioni di avere tutti i dati di un record in un unico luogo. I metadati su queste colonne deve essere memorizzato da qualche parte, tuttavia, e questo è dove il costo si insinua. Certo, siamo in grado di cache dei metadati in ram, ma costa sempre di più di avere il dominio modellato direttamente nel codice dell’applicazione. Sicuramente meglio di un fullfledged EAV modello però!
    • +10000 Grande risposta. Oggi la gente lesinare sulla progettazione di un database e di esigenze di raccolta. Si preferisce scrivere cento volte di più linee di codice, che prendono il tempo per fare un buon design.
    • Non hai bisogno di più design per l’relazionale opzione (2) che l’EAV opzione (1) se si sta solo fornendo la struttura dell’opzione 1. E l’interfaccia relazionale è generico da metadati che descrivono la struttura. Questo rimuove tutte le opzione 2 Cons. Però hai dimenticato l’unico Con: il DDL può essere troppo lento, per la gestione di tabelle.
    • Ciao @philipxy, non ho detto “più design”. La ragion d’essere per l’EAV è che (presumibilmente) il progettista del sistema di trascorrere meno tempo la progettazione del modello, lasciando questo lavoro di progettazione per “utenti” e poi (questa mancanza di progettazione professionale conduce al Cons elencati per l’Opzione 1). Se l’EAV comporta alcun risparmio per il progettista che aggiunge solo più benzina sul fuoco per respingere l’EAV di mano. Inoltre, io non sono d’accordo che il DDL è “troppo lenta” – dal momento che dovrebbero essere richiesti solo raramente (cioè per correggere gli errori nel modello, o per implementare nuove funzionalità, le prestazioni devono essere relativamente poco importante.
    • Ciao. Il mio punto di ri design, che ragion d’essere è un mito: Quando non c’è nessun disegno non c’è nessun SQL, e quando il design non accadere l’EAV è complesso & senza DBMS di supporto, mentre il SQL DDL+DML. Il mio punto di ri DDL, la reale (ma non solo) l’EAV è se il DDL è troppo lento. DDL manipola DBMS tabelle di metadati esattamente come DML manipola l’EAV tabella, eccetto se volete qualsiasi DBMS funzionalità sul tavolo rappresentata dai metadati nella EAV caso diverso l’interrogazione dopo la ricostruzione di esso poi si sono rotolare il vostro proprio DBMS.

  2. 62

    È sicuro di dire che l’EAV/CR modello di database è male.

    No, non è così. È solo che sono un inefficiente utilizzo di database relazionali. Puramente chiave/valore, funziona alla grande con questo modello.

    Ora, per il vero problema: Come conservare i vari attributi e tenerli ricercabile?

    Basta usare EAV. Nel tuo caso sarebbe una singola tabella supplementare. indice sul nome dell’attributo e il valore, più RDBMs utilizzare il prefisso di compressione per il nome dell’attributo di ripetizioni, il che rende molto veloce e compatto.

    EAV/CR diventa brutto quando si utilizza per sostituire il ‘reale’ campi. Come per ogni strumento, un uso eccessivo è “cattivo”, e dà una cattiva immagine.

    • Grande pragmatica risposta!!!
    • quindi la domanda è ho 15 campi aggiuntivi per una delle mie categorie e in eav modello reqires 16 join + tavolo principale, così facendo 16 left join per la ricerca dei prodotti (e avendo 16, dove se custmer desidera )in 3-4 milioni di record(un sito per la vendita di prodotti di seconda mano da parte di persone ) è perofrmance basso ?
    • Se questi “campi aggiuntivi” sono già definite, allora si sarebbe sicuramente fatto meglio come “campi reali”. E, naturalmente, fare un certo numero di join nella query di grandi dimensioni sarebbe un pesante tributo (ma potrebbe essere ancora ok!). Quello che ho fatto su un metadati-heavy project è quello di consentire a un numero qualsiasi di “tag” (come EAV record) per “voce principale”, ma la “grande domanda” riprende solo alcuni predefiniti tagnames, mantenendo il numero totale di join limitata (attualmente tipica è a soli 4 tag e circa il 5 altri join), e quando l’utente seleziona un elemento specifico, poi si acquisisce tutto ciò che è relativo, ma per un singolo elemento.
    • ma, naturalmente, che specifica il sistema è attualmente in fase di porting di un hstore campo (solo uno dei motivi per cui dobbiamo utilizzare PostgreSQL)
  3. 15
    //A questo punto, mi piacerebbe prendere un momento per parlare di Magento/Adobe formato PSD. 
    //Magento/PSD non è una buona piattaforma di e-commerce/formato. Magento/PSD non è nemmeno una cattiva piattaforma di e-commerce/formato. Definendolo come un 
    //insulto ad altri male piattaforma di e-commerce/formato come Zencart o OsCommerce. No, Magento/PSD è un'enorme piattaforma di e-commerce/formato. Avendo 
    //lavorato su questo codice per diverse settimane ormai, il mio odio per Magento/PSD è cresciuta di un furioso incendio 
    //che si brucia con l'ardente passione di milioni di soli. 
    

    http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

    I modelli interni sono wacky al meglio, come qualcuno ha lo schema in un boggle gioco, sigillato che e metterlo in una pittura shacker…

    Mondo reale: sto lavorando su un midware realizzazione di app ed ecco una query per ottenere informazioni di indirizzo.

    CREATE OR REPLACE VIEW sales_flat_addresses AS
    SELECT sales_order_entity.parent_id AS order_id, 
           sales_order_entity.entity_id, 
           CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
           GROUP_CONCAT( 
             CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
             ORDER BY sales_order_entity_varchar.value DESC
             SEPARATOR '!!!!!' 
           ) as data
      FROM sales_order_entity
           INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
           INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
       AND sales_order_entity.entity_type_id =12
     GROUP BY sales_order_entity.entity_id
     ORDER BY eav_attribute.attribute_code = 'address_type'

    Esige l’indirizzo di un ordine, pigramente

    Sommario: Solo utilizzare Magento se:

    1. Di ricevere grandi sacchi di denaro
    2. È necessario
    3. Godere di dolore
    • Questo è un vecchio post, ma vorrei aver trovato questo 3 mesi fa, quando ho iniziato a Magento progetto per un cliente. +1 per il boggle/vernice-shaker analogia!
    • Piuttosto interessting, magento e sembra che il re-of-the-road in termini di sistemi di e-commerce. Forse è solo marketing è molto buona
    • Cordiali saluti, Il link è rotto..
    • Magento non è popolare a causa del livello di manutenzione, ma la possibilità di personalizzare, permettendo a chiunque di implementare nuove funzionalità senza modifiche di architettura o di alcune modifiche. Questa caratteristica viene fornito con un costo.
    • Stare lontano da Magento 2 se si vuole evitare la Tripla del Dolore e Più il dolore per entrambi FE e BE
  4. 15

    Mi sorprende che nessuno di cui database NoSQL.

    Ho mai praticato NoSQL in un contesto di produzione (appena testato MongoDB, fu impressionato) ma il punto di NoSQL è essere in grado di salvare gli articoli con diversi attributi della stessa “documento”.

    • Considera che scrive su MongoDB richiedono database-livello di chiusura, e che cosa significa per la produzione concomitante di traffico.
    • Considera che la durata del blocco è nell’ordine dei microsecondi.
  5. 11

    In cui le prestazioni non è un requisito importante, come in un ETL tipo di applicazione, l’EAV ha un altro vantaggio: differenziale salva.

    Ho implementato una serie di applicazioni in cui un raggio requisito è la capacità di vedere la storia di un oggetto di dominio la sua prima “versione” al suo stato attuale. Se il dominio oggetto ha un gran numero di attributi, il che significa che ogni cambiamento richiede una nuova riga inserita nella tabella corrispondente (non un aggiornamento, perché la storia si sarebbe perso, ma di un inserto). Diciamo che questo dominio oggetto è una Persona, e ho 500k Persone di pista con una media di 100+ variazioni nel corso della vita delle Persone ciclo di vari attributi. Coppia che, con il fatto che raro è l’applicazione che ha solo 1 principali oggetto di dominio e sarete rapidamente surmize che la dimensione del database crescere rapidamente fuori controllo.

    Una soluzione semplice è quello di salvare solo il differenziale modifiche principali oggetti del dominio, piuttosto che più volte il salvataggio di informazioni ridondanti.

    Tutti i modelli di modificare nel corso del tempo per riflettere le nuove esigenze di business. Periodo. Utilizzando l’EAV è solo uno degli strumenti a nostra casella di utilizzare, ma non dovrebbe mai essere classificati automaticamente come “cattivo”.

    • +1 per “Utilizzando l’EAV è solo uno degli strumenti a nostra casella di utilizzare, ma non dovrebbe mai essere classificati automaticamente come “cattivo”.”
    • Btw, questo è chiamato ” (SCD lentamente cambiando dimensioni). Anche bitemporale requisiti (un caso specifico di Tipo 4 SCD), chiamata per l’EAV schema per gli attributi che hanno questa proprietà. Ricordate, il 99% dei NoSQL non indigeni si unisce, quindi, se avete necessità di “live” che unisce con questo tipo di dati, l’EAV è l’unico modo per andare.
  6. 3

    Io sono alle prese con lo stesso problema. Può essere interessante per voi di controllare il seguente discussione su due esistenti soluzioni di e-commerce: Magento (EAV) e Joomla (regolare struttura relazionale):
    https://forum.virtuemart.net/index.php?topic=58686.0

    Sembra, che Magento EAV prestazioni è un vero showstopper.

    È per questo che sto sporgendosi verso una normalizzato struttura. Per superare la mancanza di flessibilità sto pensando di aggiungere alcuni dati separati dizionario in futuro (XML o separate tabelle DB) che può essere modificato, e, su tale base, il codice dell’applicazione per visualizzare e confrontare le categorie di prodotto, con un nuovo set di attributi sarebbe generato, insieme con gli script SQL.

    Ad architettura sembra essere il sweetspot in questo caso – flessibile e performante allo stesso tempo.

    Il problema potrebbe essere l’uso frequente di ALTER TABLE in un ambiente live. Sto usando Postgres, quindi la sua MVCC e DDL transazionale, si spera di alleviare il dolore.

  7. 2

    Ho ancora votare per la modellazione al minor significativi a livello atomico per EAV. Lasciate che le norme, le tecnologie e le applicazioni che marcia verso alcune comunità di utenti per decidere i modelli di contenuto, la ripetizione esigenze di attributi, cereali, etc.

  8. 2

    Se è solo il catalogo prodotti di attributi e, di conseguenza, i requisiti di convalida per gli attributi sono piuttosto limitate, l’unico vero inconveniente per l’EAV è le prestazioni delle query e anche che è solo un problema quando la query si occupa con più “cose” (prodotti) con gli attributi, le prestazioni per la query “dammi tutti gli attributi per il prodotto con id 234” mentre non ottimale è ancora molto veloce.

    Una soluzione è usare il database SQL /EAV solo per il modello per l’admin /edit lato del catalogo prodotti e di avere qualche processo che denormalizes prodotti in qualcosa che lo rende ricercabile. Visto che hai già gli attributi e, quindi, è piuttosto probabile che si desidera sfaccettature, questo qualcosa potrebbe essere Solr o ElasticSearch. Questo approccio evita fondamentalmente tutti i lati negativi per il valore aggiunto europeo del modello e la complessità aggiunta, è limitata per la serializzazione di un prodotto completo per JSON su update.

  9. 2

    EAV ha molti svantaggi:

    1. Degrado delle prestazioni nel tempo
      Una volta che la quantità di dati in applicazione cresce oltre una certa dimensione, il recupero e la manipolazione dei dati, è probabile che diventano sempre meno efficienti.
    2. Le query SQL sono molto complesse e difficili da scrivere.
    3. Problemi di Integrità dei dati.
      Non si può definire chiavi esterne per tutti i campi necessari.
    4. È necessario definire e mantenere i propri metadati.
    • 1. Questo è vero per la maggior parte dei database relazionali troppo; questo è il motivo per cui sharding è stato inventato. 2. Dati di modellazione può essere complesso e di difficile attuazione. Ho passato settimane-mesi di attesa per schema di cubo OLAP modifiche. 3. Già in gran parte fatto in software 4. Devi fare questo “in ERwin, Excel, Visio” durante la modellazione uno schema relazionale in ogni caso.
  10. 1

    Ho un problema leggermente diverso: invece di molti attributi di tipo sparse valori (che è probabilmente una buona ragione per usare EAV), voglio memorizzare qualcosa di più simile a un foglio di calcolo. Colonne nel foglio di lavoro può cambiare, ma all’interno di un foglio tutte le celle che contengono i dati (non di rado).

    Ho fatto un piccola serie di test a benchmark di due progetti: uno che utilizza l’EAV, e l’altro utilizzando un Postgres ARRAY per memorizzare i dati della cella.

    EAV
    Attributo di entità Valore Database vs rigide Modello Relazionale e-commerce

    Array
    Attributo di entità Valore Database vs rigide Modello Relazionale e-commerce

    Entrambi gli schemi sono gli indici di apposite colonne, e gli indici sono utilizzati dal progettista.

    È venuto fuori che il array-based schema era un ordine di grandezza più veloce per entrambi gli inserti e le query. Da un veloce test, mi è sembrato che sia in scala linearmente. I test non sono molto approfondite, però. Suggerimenti e forcelle di benvenuto – sono sotto licenza MIT.

    • come hai fatto a fare join sul foglio colonne (cioè vlookup) con la matrice del modello? Non è necessario scrivere la matrice di merge-sort funzione? Dubito fortemente che può essere buono come il precompilato merge sort, se hai usato sheet_id + coordinata x+y-coordinate di una cella il valore della cella è la chiave. (per emulare excel, pregenerate una tabella di ricerca per coordinate x, dove 0-18278 sono le colonne di A-ZZZ (excel maxes a 16384)), quindi è possibile selezionare i valori in cui sheet_id=uuid e x-coord = 0 e y-coord < 1001 per ottenere i primi 1000 righe del col A.
    • hai ragione; ho appena carico le colonne che mi interessano e fare il join in Python. Slack!

Lascia un commento