ereditarietà di tabelle singole, EAV o NoSQL?

Question

Sto cercando un buon approccio per il modello di dati della mia applicazione. La maggior parte dei thread si concentra sui prodotti di e-commerce e il mio scenario è leggermente diverso.

L'obiettivo è memorizzare gli articoli ricevuti dai clienti e riportarli su di essi. Sebbene i report iniziali siano semplici elenchi (questi sono i tuoi articoli e le loro coppie chiave/valore) voglio prepararmi per le query future sulle raccolte nel loro insieme, quindi sono incerto sull'EAV come approccio.

Ogni elemento è di tipo (ricorrente) e ogni articolo avrà una quantità flessibile di coppie chiave/valore. Abbiamo circa 15 tipi di articoli e non è molto probabile che crescano rapidamente.

La quantità di coppie chiave/valore sarà bassa, tra 4 e 20 ed è (per fabbisogno) non basata sul tipo di articolo, ma sul cliente gli articoli appartengono a.

Per chiarire, un cliente potrebbe desiderare che memorizzi le condizioni dell'articolo in cui un altro potrebbe desiderare che io memorizzi il colore o un ID di sostituzione. Dipende davvero. Quindi è molto probabile che avrò comunque valori NULL nel mio insieme, poiché ogni tipo di oggetto otterrà comunque tutte le chiavi/i valori di quel cliente. Questo mi fa pensare Ereditarietà tabella singola (con valori NULL) è accettabile, ma dovrebbe essere campo_1 campo_2 ecc. Con una sorta di mappatura perché il cliente deciderà il nome della chiave desiderata. Quale non mi sembra giusto?

Un insieme di articoli del cliente (e le relative chiavi/valori) sarà solitamente> 20 e < 500, quindi i set di dati per cliente non sono certamente enormi.

Forse sarebbe un buon approccio andare (semi) EAV in MySQL per l'applicazione stessa (creazione del cliente e dei campi desiderati) ma spostare i record degli articoli raccolti come un "documento" in un database NoSQL (Redis et tutto) per ulteriori elaborazioni?

O è complicare troppo le cose che possono/dovrebbero essere risolti in un RDBMS?

Mi sono imbattuto anche in questo http://backchannel.org/blog/friendfeed-schemaless-mysql che sembra una soluzione ma non è sicuro visto che i miei numeri sono così bassi.

Answer 1

Avendo fatto progetti in tutti e tre gli approcci che elencherai, non so che posso darti una direzione difficile e veloce, ma posso offrire qualche consiglio su come procedere e scegliere l'approccio giusto.

Punte:

1. Cercate di non mescolare le tecnologie, se potete. Per esperienza personale ho trovato che questo è molto difficile. Inoltre leggerete abbastanza spesso con siti di grandi dimensioni che hanno bisogno di ridimensionare il loro sempre con il, mantenendo l'architettura semplice. Cominceranno con un mix di qualcosa come MySQL e MongoDB e poi abbandoneranno MongoDB solo per mantenere le cose semplici.

2. La tua domanda sembra essere affetta da un po 'di paralisi dell'analisi. "Potrei fare XYZ, ma ciò significa che l'ABC non è possibile." Suggerirei di fissare alcuni punti/fatti sul vostro sistema e quindi iniziare a costruire prototipi. Sembri avere buone idee, ma non saprai quanto sono brave fino a quando non inizi a costruire.

3. Realizzare che tutte le decisioni hanno conseguenze.Il primo 80% della tua soluzione sarà probabilmente abbastanza veloce e facile. L'ultimo 20% consisterà in compromessi e potrebbe essere piuttosto brutto. Preparati per quello e sii d'accordo.

4. Dalla mia esperienza l'approccio del database di documenti (NoSQL) è ancora un po 'rischioso. Dall'aver fatto un anno solido di sviluppo del documento, la cosa più difficile è stata la modellazione dei dati. Se vuoi andare su quella strada, assicurati di studiare la modellazione dei dati. Ti farà risparmiare un sacco di dolore.