[SOLUCIONADO] ¿Cómo funcionan las tablas de las redes sociales?

[mariscos_recio]

Verán, ayer me preguntó un amigo una cosa que hasta el momento no le había dedicado demasiada importancia: es el tema de las bases de datos en redes sociales.Me hizo una pregunta en la que también me dejó a mi en duda, y como curioso que soy no he dudado en preguntar puesto que ayer no localice ninguna pregunta como la que me planteó mi amigo.

La pregunta es la siguiente: "Todos los usuarios de una red social alojan sus datos en tablas de las bases de datos pero no creo que exista un tabla enorme que contenga toda información concreta de todos los usuarios.Es decir, que exista una sola tabla para albergar todos los comentarios de todos los usuarios de una red social otra tabla para albergar todos los mensajes privados que se mandan todos los usuarios y lo mismo con las fotos...pero también creo que podrían tener una tabla de mensajes privados exclusiva para cada usuario, otra exclusiva para los comentarios en su tablón, otra para las fotos que sube...en general, cosas que implican almacenar más de una fila para el mismo usuario(datos de registro de todos los usuarios sería en la misma tabla general).
En este último caso,en el que hayan tablas como las de mensajes privados, fotos, tablón, etc. que sean una tabla para cada usuario, ¿como se nombrarían? Al no poder poner el mismo nombre de tabla a todas ¿debería nombrarlas al estilo userid_tablon(234_tablon), userid_imagenes, userid_privados o parecidos?,¿Hacen eso realmente?,¿Es lo más óptimo?".

Espero que me puedan despejar las dudas porque me ha puesto la cabeza hecha un bombo...pero son dudas que a mi parecer son interesantes...y yo también quiero despejar

Gracias de antemano.

[Malenko]

Las tablas no van por usuario, sino por "concepto": una para los comentarios en muros, otro para los mensajes, otra para los perfiles, etc. Es mucho menos problemático eso que tener tablas para cada usuario, eso es imposible de mantener.

[gnzsoloyo]

Modelo de datos básico para una red social:

[mariscos_recio]

Muchas gracias Malenko y gnzsoloyo por vuestras respuestas.Me han ayudado a aclararme el tema casi en su totalidad.Eso que me respondieron me ha llevado a pensar que podría generar un nuevo problema: que la tabla sea tan pesada que no se puedan almacenar más datos.Para aumentar el tamaño de la tabla por dos o por tres¿Puede que se puedan crear una tabla que sea extensión de otra(para que cuando una se llene pase a otra) y que al hacerse una consulta busque en las dos?Eso es todo.
Gracias.

[JhonErick]

Iniciado por gnzsoloyo

Modelo de datos básico para una red social:

Gracias por el diagrama jejejejej

[gnzsoloyo]

Iniciado por mariscos_recio

Muchas gracias Malenko y gnzsoloyo por vuestras respuestas.Me han ayudado a aclararme el tema casi en su totalidad.Eso que me respondieron me ha llevado a pensar que podría generar un nuevo problema: que la tabla sea tan pesada que no se puedan almacenar más datos.Para aumentar el tamaño de la tabla por dos o por tres¿Puede que se puedan crear una tabla que sea extensión de otra(para que cuando una se llene pase a otra) y que al hacerse una consulta busque en las dos?Eso es todo.
Gracias.

Por lo pronto, entendamos que nadie crearía una tabla única para gestionar una red social, así que habría que ver a qué le llamas "pesada".
Además, eso depende de lo bien hecha que esté la definición de las columnas, la normalización correcta de la misma, y un largo etcétera.
A nivel de motores de tablas, es muy probable que le hardware se te agote antes que MySQL no pueda manejar la tabla, por lo que no veo problemas puntuales allí.
Si puedes explicarnos mejor el escenario y el diseño de lo que vas a hacer, podríamos darte mejores consejos.

[mariscos_recio]

Con pesada me refería a que llegue al límite de almacenamiento(como podría ser FAT32 que lo limita a 4GB).Se que hoy día ese tamaño máximo de almacenamiento se ha superado pero evidentemente tendrá que tener un límite de almacenamiento máximo(impuesto por el hardware y también por el software).Entonces me refería a eso, en el caso de que las tablas estuvieran en un ordenador con un sistema de almacenamiento FAT32, por ejemplo, ¿que se debería hacer para que cuando la tabla de usuarios,por ejemplo, llegue a los 4GB pasara a introducir los datos de los nuevos usuarios registrados a otra tabla que tendría exactamente las mismas columnas(id, email, etc.),claves primarias,etc.?
Son dudas que se me plantean, solo por interés personal para mejorar en bases de datos.

[gnzsoloyo]

El tamaño de 4Gb afecta en alguna medida solamente a las tablas de timpo MyISAM, pero no a las InnoDB (ambos motores de tablas usados por MySQL).
Las InnoDB resuelven ese problema porque los datos se almacenan en un único archivo binario que se segmenta en tamaños configurables.
Normalmente crea segmentos de 1Gb por bloque, por lo que si el espacio es suficiente, puede almacenar tantos como necesite.
Además de eso está el particionamiento, los sistemas distribuidos y un enorme etcétera del que te irás enterando a medida que avances en este asunto.
Todos esos problemas ya fueron resueltos hace muchos años. Sölo tienes que usar lo que te conviene.
Yo he trabajado con bases que ocupaban 18 a 30 Gb y la base ni pestañeaba...

[mariscos_recio]

Gracias gnzsoloyo.Me ha quedado todo claro. Hasta las próximas dudas :)

[patofeo]

Entiendo lo que el pregunta, el pregunta en cuanto al volumen, generalmente las redes sociales, los buscadores o webs que manejan millones y millones de registros, usan modulos especiales en los motores de busqueda, que son distintos de los normales, con indices que funcionan distinto!!

[gnzsoloyo]

No exactamente...
Primero, con confundas los motores de búsquedas con las busquedas en motores de bases de datos. Son cosas diferentes. Un motor de búsquedas no es una base de datos, pero usa bases de datos.
Segundo, el hecho de que tengas módulos especiales en la capa de datos, ORM, o frameworks de lo que sea, no implica que no exista un DBMS por detrás, y que no exista una base de datos como las descriptas.
De hecho, si te fijas en la web de donde salió ese gráfico, aclara que tanto Facebook como Twitter tienen un esquema de bases de datos (al menos inicialmente) donde se cumple el diseño propuesto en ese DER.

[Malenko]

Iniciado por mariscos_recio

Con pesada me refería a que llegue al límite de almacenamiento(como podría ser FAT32 que lo limita a 4GB).Se que hoy día ese tamaño máximo de almacenamiento se ha superado pero evidentemente tendrá que tener un límite de almacenamiento máximo(impuesto por el hardware y también por el software).Entonces me refería a eso, en el caso de que las tablas estuvieran en un ordenador con un sistema de almacenamiento FAT32, por ejemplo, ¿que se debería hacer para que cuando la tabla de usuarios,por ejemplo, llegue a los 4GB pasara a introducir los datos de los nuevos usuarios registrados a otra tabla que tendría exactamente las mismas columnas(id, email, etc.),claves primarias,etc.?
Son dudas que se me plantean, solo por interés personal para mejorar en bases de datos.

Pero el tema de la FAT no tiene que ver nada con el gestor de base de datos ni su arquitectura, sino con el lugar donde se almacena. Para estos temas se suelen usar cabinas de discos. Y sobre el tamaño de las bbdd dependiendo del ambito 4GB no son "nada". Una de las BBDD de mi lugar de trabajo tiene unos 300 GB y solo almacena información de los últimos 3 meses (el resto de meses se pasa a un historico que se almacena aparte por temas de rendimiento y backup).

[gnzsoloyo]

Eso me recuerda a uno de mis profesores de BBDD, quien trabaja en uno de los principales bancos nacionales de Sudamérica. Si mal no recuerdo, el backup de transacciones "normal" que ese banco tenía en toda su red era de unos 16 Tb diarios, hace alrededor de cinco años atrás.
Eso sí podría calificarse de algo "grande"