numero maximo de talas en mysql

[juanito1712]

estoy en medio de una aplicacion en la que me ha surgido una duda

basemonos en facebook ya que casitodos lo conocemos

supongamos que al dar de alta un usuario se crea para ese usuario
un tabla para los mensajes del tablon
una tabla para todas fotos del usuario
una tabla para todos los comentarios de todas las fotos del usuario
y asi y asi....

eso es correcto?
por cada usuario crear 4 o 5 tablas para gestionar todo su material, o deberia organizarlo de otro modo?

digo esto porque no se si mysql tiene un limite de tablas por base de datos o pierde rendimiento con tanta tabla

[juanito1712]

algun administrador puede cambiar el titulo o avisar a alguien para que lo cambie?
es donde pone talas por tablas

[gnzsoloyo]

supongamos que al dar de alta un usuario se crea para ese usuario
un tabla para los mensajes del tablon
una tabla para todas fotos del usuario
una tabla para todos los comentarios de todas las fotos del usuario
y asi y asi....

eso es correcto?
por cada usuario crear 4 o 5 tablas para gestionar todo su material, o deberia organizarlo de otro modo?

Noooo...
Te conviene volver a revisar el modelo entidad-relación y fundamentos de bases de datos.
Nadie en su sano juicio crearía un esquema de tablas por cada usuario... Sería lo mismo que crear una tabla Facturas por cada cliente que compra en un supermercado... ¿Te imaginas el caos de esa base?


Ya que mencionas Facebook, la estructura base es más o menos:

[juanito1712]

no termino de comprender esto
las tablas my?
no son una tabla para cada usuario?

[gnzsoloyo]

No. Eso no existe.
Tienes que mirar el sistema completo:¿Quienes lo componen? ¿Cómo se relacionan con otros? ¿Que acciones pueden realizar? ¿Qué tipo de data pueden participar? ¿Cómo se registra e identifica esa data en cada usuario? ¿Cómo pueden acceder a ella los participantes relacionado con un usuario...?
Todas estas cosas son muchísimo más sencillas si entiendes el modelo relacional y si conoces algo de fundamentos de base de datos.
¿Qué es lo que has leído del tema? ¿Qué has estudiado de Bases de Datos?

PD: los nombres de las tablas en ese diagrama tienen nombres imaginarios o ideales que se ponen para que los que los estudian puedan entender a qué se refieren. "Me" es la tabla "Usuario", "My_Messages" es "Mensajes", etc.

[juanito1712]

estudie una asignatura de administracion de bases de datos cuando hice el grado pero los diagramas que usabamos no eran como estos y me cuesta comprender este
a ver si no me equivoco
1-ahi cada cuadro es una tabla
2-PK es la clave primaria de esa tabla
3-FK es la clave ajena relacionada
4-PF no se lo que es
5-los conetores:el cono es el muchos y la cruz el 1

[juanito1712]

y no encuentro el customer_id
es el my_id de me?

[gnzsoloyo]

PF se refiere a Primary Key que es a la vez Foreign Key. Es el caso de tablas que no poseen clave propia sino que la heredan de otra. En el modelo E-R corresponden a las entidades débiles.
Por el resto, andas bastante bien. Lo que parece que se te escapa es el concepto de "entidad" lógica y su transformación a tabla física.

Respecto al diagrama, puede que te refieras al diagrama lógico, que es donde se comienza a bocetar la estructura del sistema:



Este diagrama describe las entidades que surgen del relevamiento del sistema. Pero es inaplicable al modelo físico, es decir, al esquema de tablas. Desde allí faltan varios pasos antes de tener una base creada.



En este caso, como para que se entienda, la tabla Libros_Autores no aparece en el DER lógico, allí esta tabla es en realidad un conector de relación con cardinalidad N:N.

¿Se percibe la diferencia?

[gnzsoloyo]

Iniciado por juanito1712

y no encuentro el customer_id
es el my_id de me?

Las FK no necesariamente reciben el mismo nombre del campo original. Es conveniente que lo tengan, pero la decisión de usarlo es del diseñador, no es obligatoria.
Usar el mismo nombre facilita la escritura de consultas.

[juanito1712]

entidad lógica y su transformación a tabla física.?

[gnzsoloyo]

Una entidad del sistema puede estar representada en la base por una o muchas tablas. Es parte del proceso de normalización e implementación.
Para darte un ejemplo: Una factura de un negocio puede quedar almacenada en dos o más tablas, dependiendo del sistema, pero en el DER sólo aparece una entidad.

[juanito1712]

cuando dices entidad te refieres por ejemplo a usuario
y que puede estar representado en muchas tablas, a que en el primer diagrama por ejemplo, el usuario esta representado por su registro en la tabla contacts, por sus registros relacionados en photos. etc etc etc

[gnzsoloyo]

No necesariamente. Los contactos de un usuario son entidades separadas, pero dependientes de él (un contacto de un usuario existe como tal si el usuario existe), a esas se les denomina precisamente entidades débiles porque dependen de otra para existir. Además, los contactos no forman parte del modelo lógico, porque se expresan en él como una relción de la entidad Usuario consigo misma, con cardinalidad N:N.
Caso diferente son los teléfonos, correos electrónicos que posea, blogs, websites. Todos ellos pertenecen al usuario, son datos que se pueden considerar como parte de sus datos estrictamente personales, pero si puede haber más de uno por cada usuario, o ninguno, no se los almacena dentro del mismo registro del usuario porque habría que poner muchos campos que no siempre tendrían información (sólo en quien use todos). Entonces se recurre a la normalización de bases de datos (leer).

[juanito1712]

ole tus pelotas, jajajaja, muchisimas gracias por ahora, ya volvere cuando haya asimilado todo lo que hay en esa pagina de la wiki y en algunas cuantas mas vinculadas ;)

[gnzsoloyo]

OK, Repasa todo y luego vemos...
Suerte

[juanito1712]

pff creo que estoy terminando peor que cuando empezé y ademas siento que me salgo por la tangente

iamginemos un hosting de imagenes

en un principio lo que veo lógico y he hecho siempre es

una tabla usuarios con todos los usuarios
una tabla fotos con todas las fotos de todos los usuarios, con una clave ajena que indique cual es el usuario

pero todo lo que he hecho hasta ahora no esperaba una cantidad considerable de usuarios como para preocuparme por el rendimiento ya que el servidor iba a soportar perfectamente todas las bases de datos que tendría, lo malo que esta es la primera vez que tengo que pensar a lo grande y tengo miedo debido a ninguna experiencia en algo de este tamaño

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?

[gnzsoloyo]

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í?

[juanito1712]

Una respuesta así necesitaba, muchísimas gracias
lo que comentas de las fotos y como almacenarlas para no alcanzar los límites del sistema operativo ya me lo había planteado y encontrado la solución, simplemente lo estaba omitiendo.

Si que había leído unas cuantas veces en la documentación deMYSQL que sus limites son mas bien impuestos por el sistema operativo que por el propio motor, pero a todo lo que hacían referencia era a tamaños totales de las bases de datos.

Pero es lo que digo, nunca me he enfrentado a algo tan grande y no sabia como reaccionará ni tampoco conozco las posibilidades reales de mysql, lo que tenia mas bien era miedo.

También estoy pensando que será mas cómodo tenerlo todo en una tabla y si llegado el momento viese otra arquitectura diferente que mejorase el rendimiento ajustarlo, que tenerlo todo desmembrado y querer reunirlo.

Muchísimas gracias de nuevo

[gnzsoloyo]

También estoy pensando que será mas cómodo tenerlo todo en una tabla y si llegado el momento viese otra arquitectura diferente que mejorase el rendimiento ajustarlo, que tenerlo todo desmembrado y querer reunirlo.

Trata de normalizar lo más que te de la experiencia y el análisis. Modificar las bases de datos cuando ya están trabajando implica migrar modelos y las migraciones son un verdadero dolor de cabeza. No sólo deberás modificar la base, sino todas las consultas que la aplicaciones hagan a las tablas que afectes.
Por eso se suele enseñar en las cátedras de BBDD que una base de datos trabajando no modifica jamás. Yo lo hice dos veces, y te aseguro que tenían razón.

[juanito1712]

sip, cambiar el modelo significa rehacer la aplicación y migrar todos los datos, pero bueno, si lo hago mal y tengo que hacerlo, a la siguiente ya veras como no cometo ese mismo error.

Habrá que hacerle honor a la gran verdad de tu firma no?

[gnzsoloyo]

Si, tienes razón...

[valans5]

Retomo el hilo, porque me parece muy interesante lo tratado aquí y las explicaciones de gnzsoloyo de 10.

Pero me genera las mismas dudas que el compañero, no por el hecho de que se realicen un elevado número de consultas en poco tiempo, sino por el hecho de que en muy breve espacio de tiempo, varios usuarios quieran crear un nuevo registro, otros usuarios borren varias imágenes (y sus registros dentro de la BBDD) y muchos consulten la BBDD.

En dicho caso ¿No se obtendría mayor rendimiento con una tabla por usuario? De esta forma el índice de simultaneidad sobre una misma tabla sería mínima en comparación con una sola tabla para, por ejemplo, 10.000 usuarios.

Y en el caso de que siga siendo recomendable usar una sola tabla, ¿sería conveniente bloquearla cada vez que se va a crear o eliminar un registro?


Gracias!

[gnzsoloyo]

¿No se obtendría mayor rendimiento con una tabla por usuario?

En realidad no. Las complicaciones de usar tablas por usuarios impactarían directamente en la aplicación, además de hacer imposible usar integridad referencial en ciertas tablas críticas, como las de mensajería, porque no puedes definir una FK que apunte a dos o más tablas diferentes.
Si implementases una tabla por usuario, el resto de la integridad referencial y la consistencia la deberás administrar por medio de programación, con lo que deberías aumentar la cantidad de consultas, verificaciones y posiblemente actualizaciones.
Pero lo central es que esto:

el hecho de que en muy breve espacio de tiempo, varios usuarios quieran crear un nuevo registro, otros usuarios borren varias imágenes (y sus registros dentro de la BBDD) y muchos consulten la BBDD.

Hace años que se solucionó: Eso se realiza con lo que se deominan transacciones o TRANSACTION, que permiten controlar estas cosas.

[valans5]

Iniciado por gnzsoloyo

En realidad no. Las complicaciones de usar tablas por usuarios impactarían directamente en la aplicación, además de hacer imposible usar integridad referencial en ciertas tablas críticas, como las de mensajería, porque no puedes definir una FK que apunte a dos o más tablas diferentes.
Si implementases una tabla por usuario, el resto de la integridad referencial y la consistencia la deberás administrar por medio de programación, con lo que deberías aumentar la cantidad de consultas, verificaciones y posiblemente actualizaciones.
Pero lo central es que esto:

Hace años que se solucionó: Eso se realiza con lo que se deominan transacciones o TRANSACTION, que permiten controlar estas cosas.

Gracias!

El primer punto ya lo tengo bastante claro.

Con respecto al segundo, he estado leyendo sobre el tema, principalmente del manual de usuario de MySQL y he llegado a este párrafo (Estaba leyendo sobre las transacciones):

InnoDB tables use row-level locking so that multiple sessions and applications can read from and write to the same table simultaneously, without making each other wait or producing inconsistent results. For this storage engine, avoid using the LOCK TABLES statement, because it does not offer any extra protection, but instead reduces concurrency. The automatic row-level locking makes these tables suitable for your busiest databases with your most important data, while also simplifying application logic since you do not need to lock and unlock tables. Consequently, the InnoDB storage engine in the default in MySQL 5.5 and higher.

Viene a decir que InnoDB utiliza el bloqueo de filas por lo que varias sesiones y aplicaciones pueden leer y escribir en la misma tabla al mismo tiempo, sin hacer esperar a cada uno o producir resultados inconsistentes. Para este motor de almacenamiento, se debe evitar el uso de la declaración de bloquear tablas, ya que no ofrece ninguna protección adicional, sino que reduce la concurrencia...

Entonces, haciendo uso de tablas InnoDB, no tendría problemas, ya que sólo bloquearía la fila que está siendo utilizada.

[gnzsoloyo]

Mas o menos.
El tema principal sigue siendo que lo haces por TRANSACTIONs. Es como se controla esto en todos los DBMS.