¿Qué es más eficiente: una sola tabla larga o una tabla distribuida? ¿y por qué?

Question

Esta pregunta es sobre rendimiento y agradecería si las respuestas son específicas para el caso que proporciono.

¿Cuál es más apropiado para el rendimiento?

• crear una tabla con demasiados campos
• creación de más de una tabla y la distribución de los campos similares a ellos

CASO: Un patrón 1 Amplia Web CMS Módulo

: Largo pero una tabla

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

Cleary, la mayoría de los CMS de código abierto como joomla usan el patrón anterior. Pero creo que ese patrón es que mata el espíritu de RDBMS. Podemos separar fácilmente el contenido, la configuración y la meta de un artículo en particular en diferentes tablas. Al igual que el siguiente

Patrón 2: Muchos, pero relacionados mesa

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

Nota: Las relaciones en este caso es uno-a-uno

¿Cuál es el modelo adecuado a seguir? ¿Por qué elegir una tabla larga pero única, o por qué no elegir tablas distribuidas, en una sola tabla?

Answer 1

Las únicas posibles causas plausibles para tener datos no normalizados (una tabla con muchas columnas) que se me ocurre, son:

• pereza por escrito SQL JOIN s
• posibles mejoras de rendimiento sobre los estados de lectura

me gusta ir a la versión normalizada todo el tiempo, debido a que:

• puedo estar seguro de la integridad de los datos
• puedo extraer fácilmente la información de la base de datos (por ejemplo, la cantidad de mensajes tienen alguna meta, el número de los metas distinta existen, etc)

Answer 2

Creo que la clave de rendimiento en 'moderno' - No sé mucho sobre el significado de 'moderno', pero - la aplicación basada en RDBMS no solo depende de esquema de base de datos.

• Propiedades de la base de la estrategia: el uso de memoria, tamaño de búfer de clave, consulta el tamaño de caché, etc.
• de distribución de datos/procesamiento: de partición, el procesamiento de la rejilla.
• Estrategia de caché: utilizando el motor de caché incorporado u otro (como memcached).rendimiento
• hardware

Por lo tanto, la estimación de rendimiento no es un problema sencillo. Incluso una tabla con 100 campos puede instalarse en la memoria, pero incluso la tabla de dos campos puede no serlo. Una consulta para filas de 5M se puede hacer en menos de un minuto, pero en algún momento la misma consulta no finaliza durante 10 minutos en filas de 10M (¡solo dos veces!) - depende del entorno que mencioné anteriormente.

Por lo tanto, creo que no podemos elegir la mejor práctica para casos completos. Para su ejemplo, la clave está colgada en el gusto de DBA. (no es broma)