Modelado de Datos para una Red Social Básica en SQL
Resumen
¿Cómo estructuramos los datos para una red social?
Para crear una red social de manera eficiente, es crucial entender cómo estructurar los datos que vamos a almacenar. La organización y relación de estos datos serán el eje central para asegurar un funcionamiento óptimo de nuestra aplicación. El objetivo es desarrollar una red social sencilla, construida desde lo más básico para tener flexibilidad en futuras expansiones.
¿Qué entidades y propiedades necesitamos?
En cualquier red social, identificar las entidades y sus propiedades es el primer paso. Aquí, las principales entidades son los usuarios y las publicaciones (posts).
Usuarios: Almacenan propiedades esenciales como nombre y ID, permitiendo gestionar la información personal y las interacciones del usuario.
Publicaciones (Posts): Cada publicación también tendrá un ID y estará relacionada con un usuario específico que actúa como autor de dicha publicación.
¿Cómo se relacionan las entidades?
El pilar de una red social son las interrelaciones entre las diferentes entidades:
Un usuario publica un post: Esta relación es esencial para vincular las publicaciones con sus creadores. Cada publicación debe tener un campo que identifique al usuario que la creó.
Seguir a otros usuarios: Un usuario puede seguir a múltiples usuarios, y a su vez, puede ser seguido por otros. Esta relación es de "muchos a muchos".
Likes en publicaciones: Los usuarios pueden expresar su agrado por cualquier número de publicaciones, y viceversa, cualquier publicación puede recibir likes de diferentes usuarios. Nuevamente, se trata de una relación "muchos a muchos".
¿Cómo convertir estas relaciones en tablas?
Dado que la estructura de datos es bastante relacional, es conveniente usar un sistema de bases de datos relacional, como MySQL. Construir tablas coherentes y organizadas es fundamental para garantizar la eficiencia en las consultas.
-- Tabla para los usuariosCREATETABLE Users ( id INTPRIMARYKEY, name VARCHAR(100), email VARCHAR(100));-- Tabla para las publicacionesCREATETABLE Posts ( id INTPRIMARYKEY, user_id INT, content TEXT,FOREIGNKEY(user_id)REFERENCES Users(id));-- Tabla para la relación de seguir usuariosCREATETABLE UserFollows ( follower_id INT, followee_id INT,FOREIGNKEY(follower_id)REFERENCES Users(id),FOREIGNKEY(followee_id)REFERENCES Users(id));-- Tabla para los likes en las publicacionesCREATETABLE PostLikes ( post_id INT, user_id INT,FOREIGNKEY(post_id)REFERENCES Posts(id),FOREIGNKEY(user_id)REFERENCES Users(id));
¿Cómo gestionar la autenticación de usuarios?
La autenticación es un elemento crítico para la seguridad. Separar la autenticación de la entidad del usuario evita comprometer datos sensibles como contraseñas.
-- Tabla para la autenticación de usuariosCREATETABLE Auth ( user_id INTPRIMARYKEY, email VARCHAR(100), password_hash VARCHAR(255),FOREIGNKEY(user_id)REFERENCES Users(id));
Mantener credenciales de acceso en una tabla separada garantiza que incluso si acceden indebidamente a la tabla de usuarios, la información crítica permanece segura.
Este enfoque estructurado no solo mejora la organización de nuestros datos, sino que también asegura la escalabilidad y seguridad del sistema. Prepárate para escribir código y llevar nuestra aplicación al siguiente nivel. ¡Ánimo, el aprendizaje y el descubrimiento apenas comienza!
Hice este pequeño diagrama, tengo un poco de dudas de la entidad user_follow
Usar el nombre de la tabla mas el _id es algo que no recomiendo :D no digo que este mal, cada quien tiene su forma de trabajar, pero creo que todo se puede simplificar con el campo "id", por ejemplo: post ( id, id_usuario ), usuario ( id )
lo suelo hacer por comodidad al momento de hacer las consultas
Gracias por el diagrama ER pero creo que en el user_follow sería N:N en lugar del 1:N que pusiste ahí, pasaría lo mismo con los likes y con auth, no?
Creo que de acuerdo a la clase del profesor Carlos, decia que el password deberia ir en la tabla Auth, por que es una tabla de logeo
Por fin un curso con sql gracias.
Genial, los otros cursos los habia hecho con mongo, seguir practicando!!
Me hubiera gustado mas que fuera con mongo
Puedes encontrar otro curso con este mismo profesor utilizando MongoDB.
Esto suena super bien. ya es el 3er curso con el profesor y todo es genial
Cuales más tiene?
Con este modelo solo podemos dar like a un post, que cambio harían para dar diferentes reacciones por ejemplo dislike?
Yo cambiaría el nombre de la tabla por post_reaction e incluiría un campo para ingresar la reacción.
Diagrama Entidad-Relación
Increíble 🤯
usando
No me quedó claro la parte de la Tabla Auth, en el minuto 5:56, cuando indica que es para no exponer datos de la tabla usuario, solo se hace una réplica de la tabla usuario y la llamamos Auth, creo que la diferencia es, que no se van a parsear (comparar) todos los datos, confírnmenme por favor
Si miras bien, ambas tablas no tienen los mismos campos, ya que en auth se guardan las contraseñas cifradas y en la tabla user no se hace esto, ya que es peligroso hacer peticiones a user y traer los datos privados de nuestros usuarios.
que tan factible seria hacer lo mismo pero en una base de datos no relacional por ejemplo con mongodb? cuales serian las implicaciones?
Aclarando que soy principiante con mongo haría lo siguiente, un documento por usuario y dentro de este documento todo organizado con arrays👉 un array de posts, un array de id de likes hacia, otro array de likes desde, otro array con follow hacia y otro con follow desde.
Seguramente a alguien se le ocurre algo mejor y sumamos conocimiento 🤗
Asi es, yo tambien lo haría igual. Mi pregunta va tambien enfocada a si cambiaría mucho la lógica por entre base de datos relacional vs basada en documentos
Excelente que haya hecho el diagrama de Entidad-Relación antes de comenzar. Este era el problema que tenia en los otros cursos. Se hacía todo en el aire y a veces no sabias que estabas haciendo al ir directo al codigo.
Gracias por eso.
Aqui mi aporte para entender mejor la estructura de datos
Esto se puede hacer con mongoDb?
no deberias!
las relaciones no, pero puedes referenciar datos y un propiedad llamada populate para organizar tu información, el curso de Node js con este mismo profesor explican esa parte
Genial que sea con SQL y bases de datos relacionales, el curso anterior fue con Mongo y pues SQL sigue siendo muy importante entonces es bueno aprender a usarlo con Node.
En bases de datos relacionales, una tabla pivote (o tabla intermedia) es una tabla que se usa para resolver relaciones muchos a muchos (M:N) entre dos entidades.
📌 ¿Por qué son necesarias?
Las bases de datos relacionales no permiten relaciones directas de muchos a muchos, por lo que se necesita una tabla intermedia para descomponer la relación en dos relaciones de uno a muchos (1:N).
🔹 Ejemplo: Relación muchos a muchos
Tenemos una base de datos para cursos y estudiantes. Un estudiante puede inscribirse en varios cursos y un curso puede tener varios estudiantes.
❌ Problema
No podemos simplemente agregar una columna en la tabla de estudiantes con los cursos porque un estudiante puede estar en muchos cursos, y lo mismo para los cursos con estudiantes.
✅ Solución: Usar una tabla pivote
Creamos una tabla intermedia llamada Inscripciones para gestionar la relación:
de las mejores clases que he visto <3
como aprender mas de relaciones ? hay algún tipo de curso en plazi para eso ?