Database orizzontale e verticale Database

Question

Sto lavorando su un sito di social networking con un albero di famiglia che è GEDCOM-compliant. Dobbiamo decidere se dovremmo usare una struttura di database orizzontale o verticale per i profili utente. Quindi, vorrei sapere se qualcuno può rispondere quando utilizzare una struttura di database orizzontale e quando utilizzare la struttura del database verticale.

Ho trovato alcune risposte per siti di shopping in cui i campi non sono deciso: una struttura di database verticale deve essere utilizzato. Ma io sono confuso su cosa utilizzare per un sito albero genealogico. Dovrei usare verticale o orizzontale?

Answer 1

Presumo si utilizza un database relazionale come MySQL, MS SQL, SQLite, PostgreSQL o Oracle per l'archiviazione?

Gedcom è uno standard per lo scambio di informazioni in modo da sapere quante colonne si avrà. Forse lo standard si amplia con nuove proprietà, in futuro, ma probabilmente non sarà un sacco di nuove proprietà. Si può facilmente estendere un tavolo con un paio di nuove colonne.

Vorrei utilizzare una tabella 'orizzontale' e non un'entità-attribyte-sistema di valori (tabella verticale). sistemi di tavoli verticali tendono ad essere lento. Essi non possono essere correttamente indicizzato e confondere il Query Optimizer.

Diventa una storia diversa quando gli utenti possono definire nuove proprietà nei loro profili, come colo occhio (u) r o Colo preferito (u) r se stessi. Quanto è flessibile vuoi quei profili di essere?

Answer 2

database verticali sono grandi per detawarehousing e leggere / sola segnalazione. Normalmente si rigenerati durante la notte. La loro performance in scrittura è di solito molto male però SELECT sono 10-100 volte più veloce.

Uno scenario tipico per l'utilizzo di un database verticale è di report OLAP quando si crea una (al giorno) snapshot dei dati e quindi eseguire query contro di essa. La maggior parte di beneficio viene dalle query che richiedono solo un numero relativamente piccolo di campi, ad esempio, quando si seleziona solo una manciata di campi da una tabella di larghezza e di grandi dimensioni. Tale interrogazione query su milioni di record (ad esempio calcolo SUM / COUNT / AVG) richiederà solo un paio di secondi.

Il tuo caso non sembra essere un buon candidato per un database verticale.

Answer 3

Sono d'accordo con tuinstoel, sistema di tavoli / EAV verticale è non solo lento, ma anche un po 'di tempo molto complesso. A volte è necessario scrivere alcuni dei vostri metodi API che si occupano di tali tabelle e gli sviluppatori di trattare solo con i metodi per evitare la complessità.

Quindi, se non c'è bisogno di aggiungere altri campi poi rimanere con tavolo orizzontale. Tuttavia si può essere necessario tavolo diverso se anche se si sta andando a sostenere la capacità multilingue. Ma vi consiglio di restare ancora con le tabelle orizzontali.

Sono anche lo sviluppo di un sito che coinvolge profilo utente e sto usando le tabelle orizzontali e se ci saranno diverse lingue supporto necessario, in futuro, allora io modificare solo per i campi in cui la lingua si contano.