Base de datos muy grande

[Heent]

Buenas gente, estoy haciendo una base de datos que tendrá muchos registros (unos 400k).
La base de datos contendrá fotos e información sobre ellas. Entonces las imágenes en si las tengo guardadas en carpetas y en mi tabla solo guardo la dirección de la imagen (funciona mejor así no para tantas imágenes?).

Mi preguntas es tarda mucho en realizar consultas con tantos registros (uso MyISAM)? Hay formas de optimizar el tiempo de búsqueda (utilizo indices en los campos por los que busco más)?


Un saludos y muchas gracias!

[gnzsoloyo]

Por empezar, 400.000 registros no llegan ni a la categoría de una base "mediana". menos aún a la de "grande". Son tan pocos que ni cuentan.
En cuanto a la optimización... depende muchísimo de las consultas, depende muchísimo de la sintaxis, los datos que se pidan, las relaciones entre tablas, los indices creados, y un enorme, largo e interminable etcétera.
Hay muchísimo escrito y publicado sobre optimización, y creo que deberías empezar por buscar sobre el tema en Google. Luego veremos sobre la marcha del desarrollo qué problemas encuentras.
Lo que quiero expresar es que hay directivas generales, pero luego la optimización dependerá del caso específico que quieras mejorar. No hay una regla absoluta.

Como advertencias básicas:
1) No uses "SELECT *", a menos que realmente vayas a usar todos los datos devueltos.
2) Los GROUP BY y ORDER BY son asesinos de performance. Sólo es conveniente usarlos si es necesario, y son efectivos sólo si el resultado de la consulta es mas o menos reducido.
3) No uses el WHERE para relacionar las tablas, es antiperformántico. Usa INNER/LEFT/RIGHT JOIN ... ON... Es mucho más eficiente.
4) Crea indices sólo si es necesario para los casos que usas. Crearlos por que sí, consume tiempo de inserciones/actualizaciones que ningun desarrollador tiene en cuenta.
5) Normaliza las tablas todo lo que puedas. Cierto nivel de atomizacion es mucho más eficiente que hacer tablas enormes con exceso de redundancia, aunque las consultas tengan una escrutura más compleja.
6) Mucho, mucho más...

[Heent]

Perdón quería poner 4000k (tampoco se si se consideran muchos o no jejeje).

Muchas gracias por la respuesta ! Me estoy mirando esto de normalización porque no se me da muy bien la verdad.


Un saludo y muchas gracias de nuevo!

[Heent]

Entonces una tabla grande o mediana a partir de cuantos registros se considera?

[gnzsoloyo]

Depende del contexto, del sistema, no hay una definición para afirmar cuál es el límite. Y tampoco es relevante.
En un sistema una tabla "grande" puede tener 10 millones de registros a través de un año, y en otros esos 10 millones los obtiene en cuatro horas. E incluso en el mismo sistema esos 10 millones pueden ser pocos, o muchos en función del uso de la tabla o del impcato de esa tabla en el contexto de toda la base.
Como te dije: Depende del contexto y del sistema.

No veo por qué te preocupa decir si es grande o pequeña.

[Heent]

Gracias, solo era para imaginar si era una tabla muy bestia o no lo que estaba haciendo.

Un saludo!

[angelsds]

"YO" soy partidario de usar mas InnoDB cuando son bases de datos que tendrán relativamente "muchos registros" si quieres saber tú a qué le llamamos base de datos con muchos registros pues la tabla de registros de un banco podría considerarse un registro "pesado" o una tabla de transacciones de una empresa de telecomunicaciones para activar saldo y usar tarjetas de crédito,a eso le podemos llamar "relativamente grande"

lo que dice gnzsoloyo no lo había visto desde ese punto pero es totalmente correcto:

1) solo selecciona los datos que vayas a mostrar y/o utilizar
2) GROUP/ORDER By a una tabla con muchos registros puede retardar el resultado ya que ordenar eso genera un gasto de memoria y se ve influenciado también por las características técnicas del servidor donde esté la base de datos (un desarrollador debe pensar en un sistema que consuma la menor cantidad de recursos).
3) los INNER/LEFT/RIGHT/JOIN son mejores que los WHERE ya que las sentencias con múltiples WHERE son mas largas y tardan mas en ser procesas, los JOIN son mas cortas y mas rápidas de procesar
5) indices no crees a menos q sea estrictamente necesario
6) normalizar al menos en mi país es un estándar que se debe cumplir en base de datos relacionales (no sé si en tu país sea así) además debes ser lo más optimo posible ya que tu trabajo representa tu talento, tu habilidad y lo que eres como profesional.


Debes buscar siempre hacer los querys mas óptimos y lsa estructuras de base mas optimas ya que la base de datos es el centro de todo sistema, si tienes problemas desde allí, tendrás problemas en todo, salu2