¿Es posible trabajar con una base de datos mysql sin relacionar?

[gnzsoloyo]

Retomo el tema, porque estoy viendo la estructura de la base que pasaste, analizando tabla a tabla, a medida que dispongo de tiempo.

Hay, como te dije, varios errores que se ven a simple vista, algunos conceptuales y otros por desconocimiento bastante profundo de las características de MySQL.

1) Existe una enorme cantidad de relaciones circulares en esa base.
Esto significa que hay tablas que se relacionan con tablas por aparentes FK, donde la segunda a su vez parece relacionarse con la anterior también por claves. esas relaciones reflexivas son de cumplimiento imposible cuando se generan FK reales, y no tienen sentido cuando se diseñan datos.
Una relación circular del tipo A -> B -> A se considera un error de diseño grave.

2) Hay tablas como USUARIO que muestran mala normalización.
Contienen datos que deberían definirse como perfiles de aplicación, y en consecuencia pertenecen a tablas diferentes (tipo, nivel de acceso, p.e.).
Lo usual en un sistema fuerte de permisos es que los permisos se administren en perfiles, los cuales a su vez permitan determinar los accesos.

3) No existen restricciones en la tabla que impidan duplicar usuarios con diferentes perfiles.
Esto puede permitir fallas de seguridad si se saltean las restricciones de la aplicación, y dado que no hay validaciones extra, es perfectamente factible.
Solo a modo de ejemplo, el DNI de un profesor debería ser UNIQUE, pero no lo es, con lo que puedes ingresar N profesores con el mismo documento, o N veces el mismo profesor con diferentes documentos.
No hay NADA que proteja la integridad de esa tabla.

4) Diferentes tablas con solapamiento de atributos.
Tablas como la de usuario, invitado y productor, representan diferentes categorizaciones de una misma entidad, y deberían componer un sistema jerárquico, a fin de no multiplicar tablas y claves, lo que a su vez obliga a poblar ciertas tablas con N claves, cuando podrían ser menos.
Además si se concentra todo en un esquema de herencia, si bien exige que existan tablas relacionales, simplifica las consultas y las optimiza.

5) Existen tablas con aparentes FK que representan valores de rango diferente.
En otras palabras, están definidas de forma diferente a su clave referida, con lo que pueden presentarse inconsistencias imposibles de detectar.

6) El diseñador de esa base desconoce cómo funciona la representación numérica en los tipos de dato de de MySQL.
Está suponiendo que el valor entre paréntesis siguiendo al tipo de dato (p.e. INT (11) )se refiere a la longitud de la cifra a almacenar, lo que no es cierto, y el manual de referencia es muy claro en eso.
Ese valor tiene otro uso y NO RESTRINGE el rango almacenable del numero en ese campo. Además poner uno menor al máximo del tipo de columna puede generar errores en vistas y backups indetectables.

7) Ciertos campos parecen haber sido definidos al voleo (azar), sin analizar los requisitos de los datos.
Tal es el caso de de los textos para los mensajes, rutas de acceso a videos y documentos, números de teléfono; en otros casos se desconoce técnicas básicas para administrar bajas lógicas en una BBDD, como son los campos "papelera", que parecen referirse a que un determinado registro ha sido borrado de su despliegue.

Puedo seguir extendiéndome, hay mas hilo para cortar, pero creo que esto te puede dar una idea.
A mi juicio es una base hecha por alguien que tal vez sepa de programación, pero que no sabe ni trabaja en bases de datos de uso productivo con el profesionalismo que se espera.
Yo replantearía el diseño, lo desengancharía de la aplicación y procuraría asegurarle la consistencia con un correcto normalizado y restricciones de integridad.

Nunca puedes confiar en que los programadores respeten las restricciones si estas no están protegidas en la base misma.

Espero que esto te ayude.