Entity-Attribute-Value table vs single table per l'archiviazione di post, eventi e pagine

Naviga le tue risposte
2

Sto cercando di decidere se utilizzare solo tabelle individuali con più campi per l'archiviazione di post, pagine ed eventi o l'utilizzo di tabelle con campi di base oltre ad avere tabelle EAV come pure per campi facoltativi. Inoltre, l'EAV consentirebbe di aggiungere più "attributi" a ciascuna entità senza effettivamente modificare il database (basta cambiare leggermente il codice dell'applicazione).

Tuttavia, quello che mi preoccupa sono le prestazioni. EAV diminuirebbe le prestazioni in tale scenario (memorizzando dati come eventi)?

Inoltre, vale la pena aggiungere una tabella EAV come event_meta al database nel caso in cui avessi bisogno di aggiungere campi / attributi aggiuntivi al modello più avanti (quando le specifiche cambiano e il sistema deve essere espanso)?

Attualmente posso pensare a due opzioni:

  1. Non si usano le tabelle EAV e si hanno solo tabelle singole per ogni tipo di entità (post, pagine ed eventi) e tutti i dati (circa 15 campi) nella tabella delle entità.

  2. Utilizza le tabelle EAV per archiviare i dati facoltativi che di solito non vengono immessi dagli utenti (ciò impedirebbe alle tabelle delle entità di avere molti campi vuoti) ma di memorizzare tutti i dati necessari e cruciali nelle tabelle delle entità.

Inoltre, per l'opzione due potrei essere in grado di avere solo una "tabella" di una tabella generica anziché tre post, pagine ed eventi di tabelle e usare solo più righe valore attributo nella tabella EAV (e avere un campo tipo nella tabella dei post). Tuttavia ciò probabilmente ridurrebbe ancora di più le prestazioni.

L'opzione 1 è molto più semplice da implementare. Tuttavia, l'opzione 2 potrebbe rendere più semplice estendere le entità in futuro poiché il database non dovrebbe mai essere regolato.

Un'altra cosa importante da considerare è la prestazione. Cosa succede quando abbiamo milioni di righe in events_meta. Ogni volta che qualcuno visualizzerebbe un evento, l'applicazione dovrebbe eseguire query su entrambe le tabelle che sarebbero piuttosto grandi e temo che ridurrebbe le prestazioni.

Quindi quale opzione dovrei usare per la mia situazione?

    
posta alwaysStuck 06.08.2014 - 17:17
fonte

3 risposte

3

Non creare un database nel tuo database. La performance farà schifo e così sarà il codice per gestirlo. Gli attributi che guidano la logica dell'applicazione dovrebbero essere colonne reali nel database sulla tabella appropriata con un nome corrispondente al loro scopo. Utilizza un EAV quando devi supportare un numero arbitrario di attributi definiti dall'utente che sono trasparenti alla tua applicazione.

Le modifiche allo schema fanno parte della manutenzione dell'applicazione del database. Cercare di evitarlo porta alla pazzia.

    
risposta data 06.08.2014 - 17:50
fonte
0

Sono d'accordo con @kevin cline. Dovremmo avere dei campi di regole fisse e logiche come colonne piuttosto che attributi dato che possiamo ottimizzare facilmente le prestazioni avendo questi campi come colonne (indicizzazione, ecc.). Ora un giorno Le prestazioni sono molto più importanti dello storage (lo storage sta diventando più economico), quindi abbiamo bisogno di costruire il nostro design che offre le migliori prestazioni. Dalla mia esperienza sento che dovremmo rendere i campi come attributi solo se c'è un rapido bisogno di creare nuovi campi nell'applicazione OR se dobbiamo registrare le azioni a ogni livello di Attributo \ Field. A meno che non abbiamo nessuno dei due requisiti speciali sopra elencati, possiamo sempre andare con Architettura Normale (Non EAV)

    
risposta data 24.09.2016 - 08:56
fonte
0

Il vecchio detto è "puoi inserire la logica nel codice, o puoi metterlo nel database" - la scelta migliore è guidata dai requisiti. Se il valore principale della tua app deve essere totalmente flessibile per il concetto di "campi definiti dall'utente", allora vai di sicuro all'EAV. D'altra parte, tuttavia, per quanto riguarda le prestazioni, se il DB è indicizzato e amp; configurato in modo appropriato, 5 milioni di righe non sono un grosso problema: ho gestito app con centinaia di milioni di righe di dati nel settore sanitario. Quando gli indici / config sono dove dovrebbero essere, anche 300 milioni di righe funzionano velocemente (tranne che per i carichi batch :)). Controlla link -attribute-value_model

    
risposta data 18.10.2016 - 23:21
fonte

Leggi altre domande sui tag

Devo separare una web api dal server web? User Story - Come dovrebbe essere definito per modifiche complesse che coinvolgono più applicazioni