Alternative a Entity-Attribute-Value (EAV)?

Il nostro database è progettato sulla base del modello EAV (Entity-Attribute-Value). Coloro che hanno lavorato con i modelli EAV conoscono tutta la schifezza che viene fornita con lo scopo di flessibilità.

Ho chiesto al mio cliente i motivi per cui l’uso del modello EAV (flessibilità) e la loro risposta è stata: le loro quadro cambiano nel tempo. Quindi, oggi possono avere una tabella con pochi attributi, ma in un mese possono essere aggiunti alcuni nuovi attributi o un attributo esistente può essere rinominato. Devono produrre report per tornare a qualsiasi stadio nel tempo e interrogare i dati in base alla forma delle quadro in quella fase.

Capisco che questo non sia fattibile con un modello relazionale convenzionale, ma personalmente considero l’EAV come anti-modello. Esistono altri modelli alternativi che ci consentono di acquisire la dimensione temporale nelle modifiche alle quadro e alle istanze?

Saluti, Mosh

    C’è una differenza tra EAV fatto in modo fedele o cattivo; 5NF fatto da persone competenti o da coloro che sono incapaci.

    La sesta forma normale è la forma normale irriducibile (non è ansible alcuna ulteriore normalizzazione). Elimina molti dei problemi comuni, come ad esempio The Null Problem, e fornisce il metodo definitivo per identificare i valori mancanti. È il NF accademicamente e tecnicamente robusto. Non ci sono prodotti per supportarlo e non è comunemente usato. Per essere implementato correttamente e coerentemente, richiede un catalogo per i metadati da implementare. Ovviamente, l’SQL richiesto per navigare diventa ancora più ingombrante (SQL è già piuttosto complicato), ma è facilmente superabile automatizzando la produzione di SQL dai metadati.

    EAV è un set parziale o un sottoinsieme di 6NF. Il problema è che di solito è fatto per uno scopo (per consentire l’aggiunta di colonne senza dover apportare modifiche DDL) e per le persone che non sono a conoscenza del 6NF e che non implementano i metadati. Il punto è 6NF ed EAV in quanto principi e concetti offrono vantaggi sostanziali e aumenti delle prestazioni; ma comunemente non è implementato correttamente, e i benefici non sono realizzati. Un bel po ‘di implementazioni EAV sono disastri, non perché EAV è cattivo, ma perché l’implementazione è scarsa.

    Per esempio. Alcune persone pensano che l’SQL richiesto per build le file 3NF dal database 6NF / EAV sia complesso: no, è ingombrante ma non complesso. Più importante, è ansible fornire una VISIONE SQL ordinaria, in modo che tutti gli utenti e gli strumenti di report vedano solo la VISIONE 3NF diretta e che i problemi 6NF / EAV siano trasparenti. Infine, l’SQL richiesto può essere automatizzato, quindi il costo del lavoro che molte persone subiscono è del tutto inutile.

    Quindi la risposta è davvero, la sesta forma normale, essendo il padre di EAV, e una forma più pura, è la sostituzione per esso. Il Caveat è, assicurarsi che sia fatto correttamente. Ho un grande db 6NF, e non soffre nessuno dei problemi che le persone postano, si comporta magnificamente, il cliente è molto felice (nessun ulteriore lavoro è un segno di completa soddisfazione funzionale).

    Ho già pubblicato una risposta molto dettagliata ad un’altra domanda che si applica anche alla tua domanda, a cui potresti essere interessato.

    Altre domande EAV

    Indipendentemente dal tipo di modello relazionale utilizzato, le modifiche al nome del campo di tracciamento richiedono un sacco di metadati di cui è necessario tenere traccia nei registri delle transazioni o nelle tabelle di controllo. Sfortunatamente, interrogare uno di quelli per lo stato in una data particolare è molto complicato. Tuttavia, se il client richiede solo lo stato in una data specifica, tuttavia, l’intero stato, non solo rispetto alle modifiche del nome, è ansible duplicare il database e ripristinare il log delle transazioni in base al tempo richiesto e eseguire le query sulla nuova istanza . Tuttavia, se le quadro aggiunte dopo la data specificata devono apparire nella query con i nomi dei campi precedenti, si ha un problema di progettazione molto grande prima di te. In tal caso, con le informazioni fornite nella domanda, suggerirei di negoziare alternative con il cliente o ottenere maggiori informazioni sull’uso dei report per trovare soluzioni alternative.

    È ansible passare a un archivio dati basato su documenti, ma ciò non risolverà il problema nel secondo caso. Spiacente, questa non è davvero una risposta, ma avendo lavorato in situazioni simili, il cliente probabilmente ha bisogno di una soluzione di reporting più realistica o di un certo numero di altri investitori disposti ad affrontare la capitale per l’ingegneria.

    Quando questo problema è venuto fuori per noi, abbiamo mantenuto lo schema db costante e implementato un factory di mapping delle quadro basato su un timestamp. Alla fine, il cliente ha continuamente modificato i requisiti (su base settimanale-mensile) sul modo in cui i campi aggregati sono stati calcolati e non sono mai stati pienamente soddisfatti.

    Da aggiungere alle risposte di @NickLarsen e @PerformanceDBA

    Se devi tenere traccia delle modifiche cronologiche a cose come il nome del campo, potresti voler guardare qualcosa come le Dimensioni che cambiano lentamente . Mi sembra che tu stia utilizzando l’EAV per modellare modelli dimensionali dinamici (probabilmente elenchi di ricerca).

    Il modo più semplice (e probabilmente il meno efficiente) per ottenere questo risultato consiste nell’includere un campo “as of” nelle tabelle EAV e, ogni volta che si verifica una modifica, inserire un nuovo record (anziché aggiornare un record esistente) con la data corrente. Ciò significa che è necessario modificare le query per includere o cercare sempre una data “as of”, o sordina a “now” se non ne viene fornita nessuna. La tua quadro base che si unisce agli oggetti EAV dovrebbe quindi interrogare “top 1” dalla tabella EAV dove “as of” date è minore o uguale alla data “last updated” della riga, ordinata da “as of” discendente. Nella peggiore delle ipotesi, se è necessario tenere traccia della modifica più recente a una determinata riga in cui sia il nome (memorizzato nella tabella ‘attributo’) sia il valore sono stati modificati, questa logica verrà concatenata alla tabella dei valori utilizzando ‘ultima modifica’ della riga per trovare il valore appropriato per quella data specifica.

    Questo ovviamente ha il potenziale per generare GRANDI quantità di dati se ci sono molti cambiamenti. Questo è il motivo per cui questo approccio viene definito “lentamente” mutevole. È inteso per valori dimensionali che possono cambiare, ma non molto spesso. Per aiutare con le prestazioni delle query, gli indici sui campi “come da” e “ultima modifica” dovrebbero aiutare.

    Creare una nuova descrizione di tabella per ogni descrizione di descrizione di quadro e una tabella aggiuntiva che indica quale tabella è quale versione. Anche il sistema di query dovrebbe essere aggiornato.

    Penso che creare uno script che genera, tabelle e query sia la soluzione migliore.