Come superare le carenze nei rapporti dal database EAV?

Question

Le gravi carenze con disegni di database Entità-attributo-valore in SQL tutti sembrano essere legati ad essere in grado di interrogare e riferire sui dati in modo efficiente e rapido. La maggior parte delle informazioni che ho letto sull'argomento mettono in guardia contro l'implementazione dell'EAV a causa di questi problemi e della comunanza di query/reporting per quasi tutte le applicazioni.

Attualmente sto progettando un sistema in cui i campi per una delle entità non sono noti in fase di progettazione/compilazione e sono definiti dall'utente finale del sistema. L'EAV sembra essere adatto a questo requisito, ma a causa dei problemi che ho letto, sono titubante nell'implementarlo in quanto vi sono anche alcuni requisiti di reporting piuttosto pesanti per questo sistema. I penso Ho escogitato un modo per aggirare questo, ma vorrei porre la domanda alla comunità SO.

Dato che il tipico database normalizzato (OLTP) non è sempre l'opzione migliore per l'esecuzione dei report, una buona pratica sembra avere un database "di report" (OLAP) in cui vengono copiati i dati dal database normalizzato, indicizzato in modo estensivo e probabilmente denormalizzato per facilitare le query. È possibile utilizzare la stessa idea per ovviare alle carenze di un progetto EAV?

L'aspetto negativo principale che vedo sono la maggiore complessità di trasferire i dati dal database di EAV per la rendicontazione, si può finire per dover modificare le tabelle del database di report come nuovi campi sono definiti nel database EAV. Ma questo è difficilmente impossibile e sembra essere un compromesso accettabile per la maggiore flessibilità data dal design EAV. Questo svantaggio esiste anche se utilizzo un archivio dati non SQL (ad esempio CouchDB o simile) per l'archiviazione dei dati principale poiché tutti gli strumenti di reporting standard si aspettano un back-end SQL su cui interrogare.

fare i problemi con i sistemi EAV per lo più andare via se si dispone di un database di report separato per l'interrogazione?

EDIT: Grazie per i commenti finora. Una delle cose importanti del sistema su cui sto lavorando è che sto solo parlando dell'utilizzo dell'EAV per una delle entità, non di tutto nel sistema.

L'intero nocciolo del sistema è quello di essere in grado di estrarre dati da più fonti disparate che non sono conosciute in anticipo e scricchiolare i dati per ottenere alcuni dati "più noti" su una particolare entità. Quindi ogni "campo" con cui ho a che fare è multivalore e mi viene anche richiesto di tenere traccia della cronologia per ciascuno di essi. Il design normalizzato per questo finisce con l'essere 1 tavolo per campo, il che rende comunque l'interrogativo un po 'doloroso.

Ecco gli schemi di tabella ei dati di esempio che sto guardando (ovviamente cambiato da quello su cui sto lavorando, ma penso che illustra il pozzo punto):

Tabelle EAV

Person 
------------------- 
- Id - Name  - 
------------------- 
- 123 - Joe Smith - 
------------------- 

Person_Value 
------------------------------------------------------------------- 
- PersonId - Source - Field  - Value   - EffectiveDate - 
------------------------------------------------------------------- 
-  123 - CIA - HomeAddress - 123 Cherry Ln - 2010-03-26 - 
-  123 - DMV - HomeAddress - 561 Stoney Rd - 2010-02-15 - 
-  123 - FBI - HomeAddress - 676 Lancas Dr - 2010-03-01 - 
------------------------------------------------------------------- 

tabella di rapporto

Person_Denormalized 
---------------------------------------------------------------------------------------- 
- Id - Name  - HomeAddress - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
---------------------------------------------------------------------------------------- 
- 123 - Joe Smith - 123 Cherry Ln -     0.713 -    2010-03-26 - 
---------------------------------------------------------------------------------------- 

Progettazione normalizzato

Person 
------------------- 
- Id - Name  - 
------------------- 
- 123 - Joe Smith - 
------------------- 

Person_HomeAddress 
------------------------------------------------------ 
- PersonId - Source - Value   - Effective Date - 
------------------------------------------------------ 
-  123 - CIA - 123 Cherry Ln -  2010-03-26 - 
-  123 - DMV - 561 Stoney Rd -  2010-02-15 - 
-  123 - FBI - 676 Lancas Dr -  2010-03-01 - 
------------------------------------------------------ 

Il campo "Fiducia" qui viene generata utilizzando la logica che non può essere espresso facilmente (se non del tutto) utilizzando SQL quindi la mia operazione più comune oltre l'inserimento di nuovi valori verranno tirando TUTTI i dati su una persona per tutti i campi in modo da poter generare il record per la tabella di rapporto.Questo è in realtà più semplice nel modello EAV poiché posso eseguire una singola query. Nella progettazione normalizzata, finisco per dover eseguire 1 query per campo per evitare che un massiccio prodotto cartesiano li unisca tutti insieme.

Answer 1

Risposta breve - sì, un database di segnalazione è un approccio ragionevole per risolvere i problemi di segnalazione da un EAV modello di dati.

Ho trascorso diversi anni a lavorare con una soluzione di gestione delle informazioni che consentiva agli utenti finali completa libertà di definire il proprio modello di dati, con lo schema e i dati memorizzati utilizzando un modello EAV. È interessante notare che questo prodotto ha fornito oggetti meta-schema utilizzati per soddisfare i requisiti di reporting (ad esempio grafici per fornire la navigazione dell'oggetto, le viste per eseguire la proiezione, ecc.). Ciò significava che l'utente finale era libero di definire le query utilizzando gli stessi termini e concetti che avevano utilizzato per creare il modello di dati nella prima istanza. L'atto di segnalazione consisteva essenzialmente nel calcolare il set di dati navigando in queste definizioni e passare il risultato a uno strumento di scrittura di report tradizionale come se si trattasse di dati relazionali.

Uno dei punti di forza di questo approccio era che lo stesso meccanismo che era già in vigore per trasformare il modello EAV in qualcosa con cui l'utente potesse lavorare poteva essere riutilizzato e applicato alla funzione di reporting.

Answer 2

Il problema con EAV non è dovuto all'EAV in quanto tale. È dovuto alla progettazione e alla creazione di un database senza comprendere quali siano realmente i requisiti dei dati e quale struttura logica i dati debbano avere per soddisfare questi requisiti. EAV, e qualsiasi altro sistema che consente agli utenti di progettare i propri dati, capovolge il problema.

In questo schema, per prima cosa, creiamo un sistema che consenta agli utenti di archiviare qualsiasi tipo di dato, indipendentemente dalla sua struttura e indipendentemente dall'uso futuro previsto. Poi, quando è il momento di far uscire i rapporti, dobbiamo capire cosa abbiamo e come si riferisce a ciò di cui abbiamo bisogno.

Buona fortuna.

Answer 3

In questo schema, per prima cosa viene creato un sistema che consente agli utenti di archiviare qualsiasi tipo di dato, indipendentemente dalla sua struttura e indipendentemente dall'uso futuro previsto. Poi, quando è il momento di far uscire i rapporti, dobbiamo capire cosa abbiamo e come si riferisce a ciò di cui abbiamo bisogno.

Dal momento che attribuisce chiaramente la natura del problema per "essere in questo schema", sembra davvero di me come se il problema con EAV davvero è a causa di EAV in quanto tale.

In effetti, vieni a pensarci: "un sistema che consente agli utenti di archiviare qualsiasi tipo di dati di qualsiasi tipo" è l'equivalente di un sistema che consente agli utenti di definire solo le loro relvars. Ma quale parte di quel sistema consente agli utenti di definire i vincoli su ciascun attributo? Oops, la folla EAV sembra aver perso un aspetto non troppo poco importante della gestione dei dati, sembra ...

Answer 4

Non c'è alcun problema con EAV Passo molto tempo a interrogare dai database MASSIVE EAV. Chiunque sostenga che segnalare EAV sia difficile o impossibile ha 1 o 2 problemi, o hanno un sistema EAV molto mal progettato o non capiscono come interrogare da uno. ottenere dati di report affidabili da un EAV DB è abbastanza semplice una volta che l'hai fatto alcune volte. Non c'è bisogno di un database di segnalazione o di qualcosa di speciale, solo alcune buone domande.

Se si sta costruendo un DB EAV, trascorri MOLTO tempo a progettarlo, il progetto creerà o interromperà la tua applicazione e sarà un incubo cercare di sistemare o gestire uno mal progettato.