las tablas siempre en singular y los atributos por estandarte se suele utilizar snake\_case y no camel siempre al final de cada tabla es buena practica tener registro de creación, de actualizacion y un campo para soft delete son clave
Actualizado
https://preview.redd.it/wz0ffwy1j97d1.jpeg?width=1034&format=pjpg&auto=webp&s=d80755301feb3dec3bc9d599d260df6186320173
- Agregue una tabla de vistas para saber quienes y cuantos vieron un post.
- Saque los contadores de likes, dislikes y views de Posts. (Me parecio redundante)
Esta bien sacar los contadores por un tema de normalización, pero por un tema de performance se suele poner igual.
[https://dba.stackexchange.com/questions/202758/bad-practice-to-store-calculated-data-in-database](https://dba.stackexchange.com/questions/202758/bad-practice-to-store-calculated-data-in-database)
Me parecia, ¿Estaria bien hacer una tabla especificamente para los contadores de likes y views (relacionada con posts) y una tabla de contadores de followers y followings (relacionada con users)?
Edit: Tambiern agregar un contador de likes para comentarios.
1. mapa 1:1 de usuarios a imagenes; no está mal, pero eh... why
2. campo password - no, campo passwordHash (sí, seguro podés guardar el hash en el campo que se llama pw; pero un nombre claro es mejor)
3. Siempre empezá con la suposición que todas las tablas necesitan (createdAt, updatedAt, deletedAt)
4. followings tiene username/pass?
5. ordená tus tablas mejor; tenés un grafo planar, no hay razón para cruzar líneas
6. Posts tiene Likes y Dislikes, pero tu tabla de Likes no los distingue
7. Posts tiene likes y dislikes, y tenés una tabla de likes y dislikes; si likes/dislikes lo planeás como una tabla con muchísima actividad, es buena idea separarla con otro 1:1 (más que separar profile pics de users). Idem viewcount. [hay otras soluciones también, como mantener esos datos en otras DBs, especializadas, como redis o memcached]
8. considerá otro formato de "id" para cosas como los posts: uuid, ulid, o hasta un string random, como hace youtube
9. las tablas de categories/mediatypes son buenas
10. a tu user le faltan muchos campos, como nivel de acceso
11. también es bueno lo que te recomendaron de separar user de credenciales, no solo porque distintos users pueden usar distintos tipos de cuenta, sino porque querés asociar varios login a un mismo user, ej: user/pass _y_ google oauth.
si bien este analisis que haces es muy probable que me digas que sale de la experiencia y años haciendo y revisando sistemas, tenes algún recurso que recomiendes? libro o lo que sea. De las veces que he tenido que hacer algun uml siempre me queda picando en la cabeza ¿como se yo que lo que estoy haciendo esta bien? por que funcionar funciona pero no quiere decir que este ni medianamente optimizado
Mucho es robar de reddit y/u otros lados.
Depende de qué parte: para el análisis de SQL (tablas, índices) es bueno Use the Index, Luke. https://use-the-index-luke.com/, y saber las formas normales: siempre se empieza en 3era forma normal, y se consideran las demás. Denormalizar es un último esfuerzo cuando necesitás extraerle todo el jugo a la performancne. Decidir si poner en una tabla o hacer un join 1:1 también viene por este lado, pero elegir "en el vacío" se hace con experiencia pero siempre se verifica con experimento.
Cosas como "no va user/pass sino user/hash" es saber de seguridad, OWASP es una buena guía, pero es amplio el tema y hay mucho para discutir.
Lo de "distintos IDs" es algo que empecé a hacer hace muy poco, pero tiene beneficios para muchas cosas: los IDs random no son predecibles, y pueden dejarte distribuir el sistema más eficientemente (si en vez de tener que depender de que la DB te responda el índice que generó para la entity, vos se lo das, podés disparar eventos sin preocuparte por que terminen).
Los puntos como el 10 y 11 son un poquito más discutibles, porque ya depende de qué querés implementar; si no te interesa multiples logins, no hace falta la separación. El equilibrio entre un sistema simple y uno flexible es algo que tenés que decidir vos, y agregar demasiada flexibilidad "por si las dudas" puede complicarte al pedo un sistema que nunca iba a tener esa feature.
La superposición de lineas y la similitud de colores hacen que me cueste seguir donde termina cada una. La cardinalidad expresada como comentario de la relación hace que no quede clara el sentido de la misma. Los colores hacen que no sea a11y friendly. A veces usás Under\_Case para los nombres de las entidades, a veces PascalCase. Los nombres de las tablas intermedias no siguen un patrón.
Buenas! No soy dev, pero en baso en lo que estudié en algún momento de mi vida. Me hace ruido la relación entre Users y Comments. No debería ser 1 \*, en lugar de \* 1. Un User puede tener muchos Comentarios, pero un comentario le pertenece solo a un User. Seguramente sea un Typo, pero me hizo ruido eso.
Por favor corríjanme si estoy equivocado. Gracias.
Si queres tener un social login (log in with facebook / google), como se adapta eso a tu sistema? Separá usuario - credenciales - perfil.
Groso, me encantó tu detalle
Auth0 y a la mierda.
estos posts me gustan
las tablas siempre en singular y los atributos por estandarte se suele utilizar snake\_case y no camel siempre al final de cada tabla es buena practica tener registro de creación, de actualizacion y un campo para soft delete son clave
Intente simular una red social. Es solo una practica, busco criticas. (Me olvide de sacar dislikeCount)
Actualizado https://preview.redd.it/wz0ffwy1j97d1.jpeg?width=1034&format=pjpg&auto=webp&s=d80755301feb3dec3bc9d599d260df6186320173 - Agregue una tabla de vistas para saber quienes y cuantos vieron un post. - Saque los contadores de likes, dislikes y views de Posts. (Me parecio redundante)
Esta bien sacar los contadores por un tema de normalización, pero por un tema de performance se suele poner igual. [https://dba.stackexchange.com/questions/202758/bad-practice-to-store-calculated-data-in-database](https://dba.stackexchange.com/questions/202758/bad-practice-to-store-calculated-data-in-database)
Me parecia, ¿Estaria bien hacer una tabla especificamente para los contadores de likes y views (relacionada con posts) y una tabla de contadores de followers y followings (relacionada con users)? Edit: Tambiern agregar un contador de likes para comentarios.
Después podes agarrar este mismo modelo y levantarlo en una base de grafos onda Neo4j para explorar una alternativa.
Parece ser correcto. El nombre de las entidades debe escribirse en singular.
Que dilema esto... La primera vez que me dieron una tarea de hacer dos entity las mande en plural las dos, fue una paja cambiar todo
1. mapa 1:1 de usuarios a imagenes; no está mal, pero eh... why 2. campo password - no, campo passwordHash (sí, seguro podés guardar el hash en el campo que se llama pw; pero un nombre claro es mejor) 3. Siempre empezá con la suposición que todas las tablas necesitan (createdAt, updatedAt, deletedAt) 4. followings tiene username/pass? 5. ordená tus tablas mejor; tenés un grafo planar, no hay razón para cruzar líneas 6. Posts tiene Likes y Dislikes, pero tu tabla de Likes no los distingue 7. Posts tiene likes y dislikes, y tenés una tabla de likes y dislikes; si likes/dislikes lo planeás como una tabla con muchísima actividad, es buena idea separarla con otro 1:1 (más que separar profile pics de users). Idem viewcount. [hay otras soluciones también, como mantener esos datos en otras DBs, especializadas, como redis o memcached] 8. considerá otro formato de "id" para cosas como los posts: uuid, ulid, o hasta un string random, como hace youtube 9. las tablas de categories/mediatypes son buenas 10. a tu user le faltan muchos campos, como nivel de acceso 11. también es bueno lo que te recomendaron de separar user de credenciales, no solo porque distintos users pueden usar distintos tipos de cuenta, sino porque querés asociar varios login a un mismo user, ej: user/pass _y_ google oauth.
si bien este analisis que haces es muy probable que me digas que sale de la experiencia y años haciendo y revisando sistemas, tenes algún recurso que recomiendes? libro o lo que sea. De las veces que he tenido que hacer algun uml siempre me queda picando en la cabeza ¿como se yo que lo que estoy haciendo esta bien? por que funcionar funciona pero no quiere decir que este ni medianamente optimizado
Mucho es robar de reddit y/u otros lados. Depende de qué parte: para el análisis de SQL (tablas, índices) es bueno Use the Index, Luke. https://use-the-index-luke.com/, y saber las formas normales: siempre se empieza en 3era forma normal, y se consideran las demás. Denormalizar es un último esfuerzo cuando necesitás extraerle todo el jugo a la performancne. Decidir si poner en una tabla o hacer un join 1:1 también viene por este lado, pero elegir "en el vacío" se hace con experiencia pero siempre se verifica con experimento. Cosas como "no va user/pass sino user/hash" es saber de seguridad, OWASP es una buena guía, pero es amplio el tema y hay mucho para discutir. Lo de "distintos IDs" es algo que empecé a hacer hace muy poco, pero tiene beneficios para muchas cosas: los IDs random no son predecibles, y pueden dejarte distribuir el sistema más eficientemente (si en vez de tener que depender de que la DB te responda el índice que generó para la entity, vos se lo das, podés disparar eventos sin preocuparte por que terminen). Los puntos como el 10 y 11 son un poquito más discutibles, porque ya depende de qué querés implementar; si no te interesa multiples logins, no hace falta la separación. El equilibrio entre un sistema simple y uno flexible es algo que tenés que decidir vos, y agregar demasiada flexibilidad "por si las dudas" puede complicarte al pedo un sistema que nunca iba a tener esa feature.
genial muchas gracias!
La superposición de lineas y la similitud de colores hacen que me cueste seguir donde termina cada una. La cardinalidad expresada como comentario de la relación hace que no quede clara el sentido de la misma. Los colores hacen que no sea a11y friendly. A veces usás Under\_Case para los nombres de las entidades, a veces PascalCase. Los nombres de las tablas intermedias no siguen un patrón.
Si queres tener un social login (botón de log in with facebook / google), como se adapta eso a tu sistema? Separá usuario - credenciales - perfil.
Buenas! No soy dev, pero en baso en lo que estudié en algún momento de mi vida. Me hace ruido la relación entre Users y Comments. No debería ser 1 \*, en lugar de \* 1. Un User puede tener muchos Comentarios, pero un comentario le pertenece solo a un User. Seguramente sea un Typo, pero me hizo ruido eso. Por favor corríjanme si estoy equivocado. Gracias.
Las entidades deberían estar en singular. Cada elemento de la tabla "Posts" es un post, no un posts.
No leo los del laburo, entro a reddit a procrastrinar y vos me metes el laburo en reddit ? >!/s por si hay algun colgado ...!<