2010-02-08 14 views
26

Ho cercato una soluzione di database per consentire campi e valori definiti dall'utente (che consente un numero illimitato). A prima vista, l'EAV sembrava la soluzione giusta, ma dopo alcune letture non ne sono più sicuro.Database EAV Pro/Contro e alternative

Quali sono i pro e i contro di EAV?

Esiste un metodo di database alternativo per consentire attributi/campi e valori definiti dall'utente?

+0

Vedi http://stackoverflow.com/search?q=%5bdatabase%5d%20%2beav&tab=newest –

risposta

27

Questa non è una risposta esauriente, ma solo alcuni punti sull'argomento.

Dal momento che la domanda è anche etichettato con il tag [sql], lasciatemi dire che, in generale, relational databases non sono particolarmente adatti per la memorizzazione dei dati utilizzando il modello EAV. È ancora possibile progettare un modello EAV in SQL, ma si dovranno sacrificare molti vantaggi che un database relazionale darebbe. Non solo non sarai in grado di applicare l'integrità referenziale, utilizzare i tipi di dati SQL per i valori e imporre attributi obbligatori, ma anche le query di base possono diventare difficili da scrivere. In effetti, per superare questa limitazione, diverse soluzioni EAV si basano sulla duplicazione dei dati, invece di unirsi alle tabelle correlate, che, come potete immaginare, presentano numerosi inconvenienti.

Se si richiede veramente un disegno schematico, "consentendo un numero illimitato di attributi", la soluzione migliore è probabilmente quella di utilizzare una soluzione NoSQL. Anche se i punti deboli di EAV relativi ai database relazionali si applicano anche alle alternative NoSQL, ti verranno offerte funzionalità aggiuntive che sono difficili da ottenere con i tradizionali database SQL. Ad esempio, solitamente i datastore NoSQL possono essere ridimensionati molto più facilmente dei database relazionali, semplicemente perché sono stati progettati per risolvere un qualche tipo di problema di scalabilità e hanno intenzionalmente eliminato funzionalità che rendono difficile il ridimensionamento.

Molte piattaforme di cloud computing (come quelli offerti da Amazon, Google e Microsoft) stanno caratterizzando archivi dati basati sul modello EAV, dove un numero arbitrario di attributi può essere associato con una data entità. Se stai pensando di implementare la tua applicazione sul cloud, puoi considerare questo sia come vantaggio commerciale, sia tecnico, perché la forte competizione tra i grandi venditori sta spingendo i rapporti value-to-cost a livelli molto alti, aumentando continuamente le caratteristiche e abbassando i costi finanziari e di implementazione.

+10

Non vedo come EAV sia un vantaggio tecnico: è più complicato da compilare, interrogare e inserire, e la leggibilità è molto bassa. Quello che sarebbe un "select * from" semplice e veloce diventa una query sql monster slow. E non sto neanche parlando di provare a fare dei report basati su un modello EAV. – guigui42

+0

@ guigui42: Grazie per il tuo commento. Hai un punto, ma la mia risposta non è stata pensata per essere esaustiva. Tuttavia, poiché è stato contrassegnato come accettato dall'OP, ho aggiornato la risposta con alcune ulteriori considerazioni. –

+1

Sono un po 'confuso sulla parte' imporre l'integrità referenziale '. Sto usando EAV e ho molte chiavi esterne. È possibile utilizzare più tipi di dati SQL grazie a UNION ALL e alcuni metadati che mappano gli attributi alla tabella (tipo di dati) in cui sono memorizzati. È possibile migliorare notevolmente la velocità delle query aggiungendo ulteriori colonne indicizzate alla tabella delle entità (come 'type 'per esempio). –

-9

Esiste un metodo di database alternativo per consentire attributi/campi e valori definiti dall'utente?

Un'alternativa è modificare lo schema del database in base all'input dell'utente: ad esempio quando l'utente desidera un nuovo campo, quindi aggiungere una colonna corrispondente al database.

+2

Lo svantaggio di questo è che avrai tonnellate di campi vuoti –

+1

@ Chrishr: Gli scenari in cui ciò è fattibile sono molto limitati a mio avviso. –

+0

Alcuni database supportano colonne "sparse" (ad es. SQL Server) che rendono questo approccio un po 'più funzionale. – codeulike