Quale è più efficiente: una tabella singola lunga o una tabella distribuita? e perché?

Question

Questa domanda riguarda esclusivamente le prestazioni e sarei grato se le risposte siano specifiche per il caso che fornisco.

Qual è il livello di prestazione più appropriato?

• creazione di una tabella con troppi campi
• creando più di una tabella e distribuzione di campi simili a loro

CASE: un vasto Web CMS Modulo

Modello 1: Lungo ma un tavolo

cms 
----------------------------------------------- 
Id 
Title 
Description 
Images 
Order 
Status 
Publish 
meta_keywords 
meta_description 
meta_author 

Cleary, la maggior parte dei CMS Open Source come joomla usano il modello sopra. Ma penso che quel modello sia lo che uccide lo spirito di RDBMS. Possiamo facilmente separare il contenuto, la configurazione e il meta di un particolare articolo in tabelle diverse. Come il seguente

Motivo 2: Molti, ma correlati Tabella

Cms_content   cms_meta  cms_configuration 
--------------------------------------------------------------------------- 
Id     id    id   
Title    content_id  content_id 
Description   keywords  status 
Content    description  order 
Images    author   publish 

Nota: Le relazioni in questo caso è uno-a-uno

Quale è il modello corretto da seguire? Perché scegliere un tavolo lungo ma uno, o perché non scegliere tabelle distribuite, sul tavolo singolo?

Answer 1

Le uniche possibili cause plausibili per avere dati denormalizzati (una tabella con molte colonne) posso pensare, sono:

• pigrizia iscritto SQL JOIN s
• possibili miglioramenti delle prestazioni su enunciati read

mi piace andare per la versione normalizzata per tutto il tempo, perché:

.210
• posso essere sicuro di integrità dei dati
• posso estrarre facilmente informazioni da DB (ad esempio, quanti messaggi hanno qualche meta, quanti METAS distinti ci sono, ecc)

Answer 2

Penso che la chiave di prestazioni su "moderno" - Non conosco molto il significato di "moderno", ma - L'applicazione basata su RDBMS non dipende solo dallo schema del database .

• impostazioni database: strategia memoria utilizzo, dimensione buffer delle chiavi, interrogare dimensione della cache ecc
• distribuzionea dati/trasformazione: suddivisione, elaborazione griglia.
• Strategia cache: utilizzando il motore cache incorporato o altro (come memcached).prestazioni
• Hardware

Quindi, la stima delle prestazioni non è un problema semplice. Anche una tabella con 100 campi può essere installata in memoria, ma anche la tabella a due campi potrebbe non essere possibile. Una query per le righe 5M può essere eseguita in un minuto, ma a volte la stessa query non termina per 10 minuti su 10 milioni di righe (solo due volte!) - dipende dall'ambiente che ho menzionato sopra.

Quindi, penso che non possiamo scegliere la procedura migliore per casi interi. Per il tuo esempio, la chiave è appesa al gusto di DBA. (non scherzo)