Come superare le carenze nel riportare dal database EAV?

StackOverflow https://stackoverflow.com/questions/2523741

Domanda

Le gravi carenze con disegni di database Entità-attributo-valore in SQL tutti sembrano essere correlate a essere in grado di interrogare e riferire sui dati in modo efficiente e rapido. La maggior parte delle informazioni che ho letto sull'argomento avvisate contro attuazione EAV a causa di questi problemi e la 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 / tempo di compilazione e sono definite dal utente finale del sistema. EAV sembra una buona misura per questo requisito, ma a causa dei problemi che ho letto su, sono titubante nella sua attuazione in quanto vi sono anche alcuni obblighi di segnalazione piuttosto pesante per questo sistema pure. I pensare Mi è venuta in mente un modo per aggirare questo, ma vorrei porre la domanda al SO comunità.

Dato che tipico database normalizzato (OLTP) ancora non è sempre la migliore opzione per l'esecuzione di rapporti, una buona pratica sembra avere un database di "segnalazione" (OLAP), dove i dati dal database normalizzato viene copiato, indicizzati estensivamente, ed eventualmente denormalizzati per facilitare interrogazione. Potrebbe la stessa idea essere utilizzato per aggirare le 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 non è certo impossibile e sembra essere un compromesso accettabile per la maggiore flessibilità proposta dal disegno EAV. Questo aspetto negativo esiste anche se uso un negozio non SQL dati (vale a dire CouchDB o simili) per la memorizzazione dei dati principale dal momento che tutti gli strumenti di reporting standard sono in attesa di un back-end SQL per interrogare contro.

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 sul sistema su cui sto lavorando su di esso che sto davvero solo parlando con EAV per una delle entità, non tutto nel sistema.

L'intero nocciolo del sistema è quello di essere in grado di estrarre i dati da più fonti diverse che non sono noti in anticipo e crunch i dati a venire con alcuni dati "più noti", circa una particolare entità. Così ogni "campo" ho a che fare è multivalore e sto anche richiesto di tenere traccia la storia per ciascuno. Il disegno normalizzato per questo finisce per essere 1 tavolo per campo che rende interrogazione che tipo di doloroso comunque.

Ecco i dati di schemi di tabelle e campione 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 -
----------------------------------------------------------------------------------------

Normalizzato design 

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 saranno tirando TUTTI i dati su una persona per tutti i campi in modo da poter generare il record per la tabella dei rapporti. Questo è in realtà più facile nel modello EAV come posso fare una singola query. Nella progettazione normalizzato, finisco per dover fare 1 query al campo per evitare una massiccia prodotto cartesiano di unirsi tutti insieme.

È stato utile?

Soluzione

Breve risposta -. Sì, un database di report è un approccio ragionevole per risolvere i problemi di segnalazione da un modello di dati EAV

Ho passato un certo numero di anni di lavoro con una soluzione di gestione delle informazioni che ha permesso agli utenti finali la massima libertà di definire il proprio modello di dati, sia con lo schema ei dati memorizzati utilizzando un modello EAV. È interessante notare che questo prodotto disponibile oggetti meta-schema utilizzato per soddisfare requisiti di segnalazione (ad esempio grafici per fornire navigazione oggetto, viste di eseguire la proiezione, ecc). Ciò significava che l'utente finale è libero di definire le query usando gli stessi termini e concetti che aveva usato per costruire il modello di dati in prima istanza. L'atto di segnalazione era essenzialmente quello di calcolare il set di dati navigando queste definizioni, e consegnare il risultato verso uno strumento di scrittura rapporto tradizionale, come se si trattasse di dati relazionali.

Uno dei punti di forza di questo approccio è che lo stesso meccanismo che era già in atto per trasformare il modello EAV per qualcosa che l'utente potrebbe lavorare con potrebbero essere riutilizzati e applicato alla funzione di reporting.

Altri suggerimenti

  

In questo schema, prima arriviamo con un sistema che consente agli utenti di memorizzare qualsiasi tipo di dati di sorta, a prescindere dalla sua struttura, e indipendentemente dalla futura destinazione d'uso. Poi, quando è il momento di ottenere i rapporti fuori, dobbiamo capire quello che abbiamo, e come che si riferisce a quello che ci serve.

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 realtà, vieni a pensarci bene: "un sistema che consente agli utenti di memorizzare qualsiasi tipo di dati di sorta" è l'equivalente di un sistema che permette agli utenti di definire solo i loro relvars. Ma quale parte di quel sistema consente agli utenti di definire i vincoli su ogni attributo? Spiacenti, la folla EAV sembra aver perso un aspetto non-così-poco importante della gestione dei dati, a quanto pare ...

Il problema con EAV non è dovuto ad EAV in quanto tale. E 'a causa di progettazione e costruzione di un database senza capire quali sono i requisiti di dati realmente sono, e che cosa logica struttura dei dati devono avere al fine di soddisfare tali requisiti. EAV, e qualsiasi altro sistema che permette agli utenti progettare i propri dati, trasforma questo sulla sua testa.

In questo schema, prima arriviamo con un sistema che consente agli utenti di memorizzare qualsiasi tipo di dati di sorta, a prescindere dalla sua struttura, e indipendentemente dalla futura destinazione d'uso. Poi, quando è il momento di ottenere i rapporti fuori, dobbiamo capire quello che abbiamo, e come che si riferisce a quello che ci serve.

Buona fortuna con quello.

Non v'è alcun problema con EAV spendo abbastanza una grande quantità di tempo l'esecuzione di query da database EAV MASSIVE. Qualcuno che dice la segnalazione da EAV è difficile o impossibile ha 1 di 2 problemi, o hanno un sistema di EAV molto mal progettato o non capiscono come interrogare da uno. ottenendo bei dati del rapporto-in grado da un DB EAV è abbastanza facile una volta che hai fatto un paio di volte. Non c'è alcuna necessità di un database di report o di qualcosa di speciale, solo alcune buone domande.

Se si sta costruendo un DB EAV spendere un sacco di tempo a progettare esso, il design sarà fare o rompere la vostra applicazione e sarà un incubo cercare di risolvere o affrontare un mal progettato uno.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top