#3 ese número debe de ser alto, a veces la baja es el único mecanismo que tiene el trabajador para llevar a cabo las tareas de autocuidado tan necesarias.
Hablo por mí, y lo que hay a mí alrededor en un entorno academico y altamente especializado. Hay gente a la que no se le permite coger vacaciones porque el trabajo es muy urgente. Y cuando termina un trabajo urgente, llega otro, y cuando se revisa el primer trabajo urgente, hay que arreglarlo urgentemente porque no está bien...
Rehacer software con nuevas tecnologías es mi pasión, tal vez pueda aportar cómo ingeniero informático y desarrollador full stack.
Eso sí, creo que el futuro de meneame debería ser open source y si somos capaces, distribuido.
mantengamos la fé en la humanidad, los multimillonarios también tienen capacidad de aprendizaje, un poco obsoleta porque no les hace falta, pero ahí está.
#130 Me autorespondo, y la conclusion que saco es que es una autentica pena que este proyecto no sea libre.
--------------------------
A simple vista, el **volcado del esquema de Menéame (8 years ago)** que compartiste parece ser un diseño relativamente *limpio* y que, en general, *respeta* las formas normales, aunque con algunas particularidades típicas de un proyecto grande y veterano. No se observan dependencias obvias que violen la 3FN (por ejemplo, no se ve que se dupliquen datos de una tabla en otra).
Dicho esto, hay algunos *detalles* que vale la pena comentar:
1. **Escaso uso de FOREIGN KEY**
- Algunas tablas sí utilizan claves foráneas (por ejemplo, `sub_statuses` y `subs_copy`), pero en muchas otras solo hay índices y no FK declaradas de forma explícita (por ejemplo, `links` y `comments` se relacionan por ID pero no con constraint `FOREIGN KEY`).
- Esto no necesariamente rompe la 3FN; muchas veces en proyectos antiguos se dejaban las relaciones controladas por la lógica de la aplicación. Pero hoy en día se recomienda usar las FK en la base de datos para garantizar la **integridad referencial**.
2. **Uso de columnas ENUM**
- Se ven varios `enum(...)` para campos como `link_status`, `comment_type`, `ban_type`, etc. En algunos diseños se prefiere tener una tabla aparte (por ejemplo, `comment_types`) y referenciarla. Sin embargo, en MySQL es frecuente usar ENUM para agilizar o simplificar.
- No rompe la normalización, aunque puede complicar extensiones futuras (añadir valores a un ENUM requiere ALTER TABLE).
3. **Tablas con muchos campos “metadata”**
- Por ejemplo, en `links` se guardan columnas como `link_url_title`, `link_content`, `link_thumb`, etc. No es necesariamente un problema de normalización, porque son datos propios de la entidad “link”.
- Mientras no repitas esos mismos campos en otras tablas, no hay violación de 3FN.
#1 xaxipiruli 
