He oído que si tiene una tabla con una columna TEXT que contendrá una gran cantidad de datos de texto, es mejor para el rendimiento mover esa columna a una tabla separada y obtenerla mediante JOINs al registro base.Cuando tienes un campo TEXTO en MySQL o PostgreSQL, ¿deberías ponerlo en una tabla separada?
¿Es esto cierto y, en caso afirmativo, por qué?
con PostgreSQL, desde the manual:
valores muy largos también se almacenan en tablas de fondo de manera que no interfieran con el rápido acceso a los valores de las columnas más cortas.
Así que una columna de caracteres de gran tamaño (como TEXT o VARCHAR sin límite de tamaño especificado) se almacena lejos de los principales datos de la tabla. Por lo tanto, PostgreSQL tiene incorporada su optimización de "ponerlo en una tabla separada". Si está utilizando PostgreSQL, organice su tabla de forma sensata y deje el diseño de los datos en PostgreSQL.
No sé cómo MySQL u otras RDBM arreglan sus datos.
La razón detrás de esta optimización es que la base de datos generalmente mantendrá los datos de cada fila en bloques contiguos en el disco para reducir la búsqueda cuando la fila necesita ser leída o actualizada. Si tiene una columna TEXTO (u otro tipo de longitud variable) en una fila, entonces el tamaño de la fila es variable, por lo que se necesita más trabajo para ir de una fila a otra. Una analogía sería la diferencia entre acceder a algo en una lista vinculada en lugar de acceder a una matriz; con una lista enlazada, tiene que leer tres elementos de uno en uno para llegar al cuarto, con una matriz que acaba de compensar 3 * element_size bytes desde el principio y está allí en un solo paso.
En algunos casos, esto podría ser cierto. La razón es que digamos que su mesa es:
create table foo (
id serial primary key,
title varchar(200) not null,
pub_date datetime not null,
text_content text
);
Entonces haces una consulta como esta:
select id, title, pub_date
from foo;
Usted tendrá que cargar mucho más páginas de disco que tendría si no lo hiciste t tiene el campo text_content en esa tabla. Y la optimización de consultas se trata principalmente de reducir la E/S de disco al mínimo posible.
Desde el MySQL Manual:
Para ver una tabla con varias columnas, a reducir los requisitos de memoria para consultas que no utilizan la columna BLOB, considerar dividir la columna BLOB en una mesa separada y referenciar con una consulta de combinación cuando sea necesario.