tablas porque para optimizar optimización lenta las grandes dañan datos cuello consultas cantidades botella bases sql database database-design

para - porque se dañan las tablas en mysql



Diseño de la base de datos de noticias como en Facebook (4)

¿Cómo haría que las noticias alimentaran un diseño de base de datos "amigable", de modo que no fuera extremadamente costoso obtener todos los elementos (consultas) para ponerlos en las noticias? La única forma en que puedo pensar involucraría la UNIÓN de casi todas las tablas (representando grupos, notas, amigos, etc.) y obteniendo las fechas y tal, que parece que sería una consulta realmente costosa para cada usuario, y Sería bastante difícil guardar en caché algo así con todos siendo diferentes.


En primer lugar, considere la realización de un prototipo de rendimiento para comprobar su presentimiento de que la unión sería demasiado costosa. Es posible que optimice prematuramente algo que no sea un problema.

Si se trata de un problema real, considere una tabla diseñada exclusivamente para contener los datos del feed de eventos, que deben actualizarse en paralelo con las otras tablas.

Por ejemplo, cuando crea un registro de notas, también crea un registro de eventos en la tabla de eventos con la fecha, la descripción y el usuario involucrados.

Considere la posibilidad de indexar la tabla de eventos según UserId (o UserId y Date). También considere borrar los datos antiguos cuando ya no sean necesarios.

Este no es un esquema normalizado, pero puede ser más rápido si obtener un evento de alimentación es una operación frecuente.


Es difícil responder a esta pregunta sin un esquema, pero mi corazonada es que una UNIÓN que involucre 10 o más tablas correctamente indexadas no es nada:
Una aplicación LAMP típica como WordPress o PHPBB ejecuta más de 10 consultas por vista de página sin problemas. Entonces no te preocupes


UNION = caro, porque el conjunto de resultados completo está sujeto a una operación DISTINCT. UNION ALL = más económico, porque efectivamente se trata de múltiples consultas para las cuales se añaden los resultados de cada una de ellas.

Depende del volumen de datos o del curso.

El principal impulsor de la eficiencia serían las consultas individuales que están unidas, pero no hay ninguna razón por la que seleccionar los 10 registros (por ejemplo) más recientes de cada una de las 10 tablas lleve más de una fracción de segundo.