Cita: pero pensando cuando hayan muchos usuarios subiendo fotos estaría cada uno por su lado haciendo crecer la tabla fotos que crecería de forma exponencial y todo lo exponencial me da miedo
si nos imaginamos 10.000 usuarios con unas 500 fotos cada uno nos darían cinco milloncetes de registros a los que estaríamos continuamente realizando consultas para obtener 500 resultados en el mejor de los casos
por lo que pense que al dar de alta un usuario crear una tabla para sus fotos y asi el numero de elementos por tabla será menor,pero evidentemente lo que crecerán serán las tablas aunque a un ritmo mas lento.
por otra parte, me dices que lo que pretendo no está bien, entonces ¿deberia tenerlo todo en la misma tabla?, ¿no deberia tener miedo por 10.000 consultas a 5 millones de registros en una tabla o debería tenerle mucho miedo y tratar de distribuirlo de otra forma?
Por un lado te digo que deberías tenerle mas confianza a los motores de base de datos. Ten en cuenta que llevan años de desarrollo, y ya tienen vasta experiencia en problemas de esa índole, por cuanto precisamente fueron creados para manejan ingentes cantidades de datos y usuarios haciendo centenares y/o miles de consultas simultáneamente.
Por otro lado, en realidad hay algunos detalles que puede que no estés viendo, tal vez porque te estás centrando en
posibles problemas y no en los problemas que
realmente tendrás y cómo solucionarlos.
El hecho de que una base cuente con millones de registros, ni siquiera es relevante. Lo relevante es en realidad cuánto volumen ocupan esas bases, o mejor dicho esas tablas.
Yo tengo bases operando que cuentan con varios gigabytes de datos almacenados, y aún así recuperar 10.000 registros que necesito entre los más de 150 millones que hay en una de las tablas tarda menos de cinco segundos. Piensalo así: Si un DBMS no puede responder a ese nivel de pedido, ni siquiera se puede usar en un supermercado... Menos aún en la Web donde el acceso es enorme.
Y MySQL es el DBMS más usado en Internet...
En realidad, en un caso como el que planteas, los millones de fotos, tu problema
no está en el almacenamiento de datos de la base (las fotos no se guardan en tablas en ese contexto, sino como archivos en servidor, en las tablas se almacenan direcciones de archivos en el site), porque un millón de registros de fotos pueden ocupar tal vez 100 Mb, dependiendo de algunos detalles. El problema real es
dónde guardar un millón de fotos en el servidor, si cada foto pesa 10 Kb... 10 Gb de archivos... bueno...
¿Se entiende el problema real?
Respecto a los usuarios, el problema tampoco es del DBMS (MySQL en este caso), sino de la implementación de la base y por sobre todas las cosas
es un problema del Webserver, ya que es el WebServer el que debe gestionar ese tráfico. Y mientras más tráfico tengas, más caro te cuesta el alquiler de los hosting.
En otras palabras, tampoco es un problema que la base deba gestionar.
En el punto donde sí impacta en la base de da,tos es en la optimización de consultas (tema muy extenso), la optimización del servidor de MySQL (más extenso y técnico), la optimización del hardware del servidor (que no depende de tí), y la optimización de las aplicaciones (eso sabrás tu de quién depende).
Pero la optimización de consultas (que depende fuertemente del diseño de la base) se puede obtener sin por eso tener que sacrificar normalización, diseño, etc. En ocasiones simplemente sabiendo qué indices deben definirse en qué tablas y con qué campos, la performance de una consulta cambia radicalmente. Esta semana que pasó tuve un caso de esos.
Debía hacer una consulta que cruzaba tres tablas, y el JOIN dos de ellas en ese caso tardaban casi veinte minutos en hacerse. Procedí a usar EXPLAIN (comando que muestra cómo hizo MySQL para procesar la consulta) y me di cuenta que a pesar de mis previsiones estaba haciendo un producto cartesiano... con dos tablas de más de 500.000 registros cada una. O sea que en memoria estaba procesando 250.000.000.000 registros de casi 200 bytes (4.656,6 Gb)... ¡Era una locura!
¿Qué hice?, simplemente definí un índice sobre tres campos críticos de la muestra y otros sobre tablas temporales que usaba y la consulta pasó a procesar casi 90.000 registros en 7,4 segundos...
¿Te percatas de la diferencia?
Bueno, ese es el tema. Los problemas que te enfrentarás serán siempre más sencillos de resolver sobre la base de un buen diseño, con los índices adecuados y con consultas optimizadas.
El resto es tema de hardware y del hosting.
Finalmente, respecto a qué fragmentar, y hasta qué punto atomizar los datos en diferentes tablas, eso lamentablemente sólo te lo enseña la práctica. Dos analistas de datos ante el mismo problema tienen dos (o más) soluciones diferentes, y no por eso alguna está equivocada.
Un dato final: MySQL ha sido el DBMS elegido en su momento por Amazon.com... Te imaginas que es capaz de soportar lo que planeas y mucho más ¿no es así?