Estructura de la base de datos para un sistema de comentarios del sitio web

Question

Actualmente estoy trabajando en un sitio web que necesita un sistema de comentarios. Como este sitio web es nuevo, y la estructura de la base de datos aún no se ha escrito en piedra, me gustaría algunas sugerencias sobre cómo manejar mejor un sistema de comentarios como este:

• Los comentarios deben ser capaces de ser colocados en cualquier cosa. Incluyendo elementos en tablas futuras.
• Los comentarios se deben consultar de forma rápida (¿y fácil?).

Sé que esto por sí solo no es mucho para seguir, así que aquí está la idea: cada universidad tiene colegios, cada universidad tiene edificios, y cada edificio tiene habitaciones. Todos los usuarios deberían poder comentar cualquiera de estos cuatro elementos (y los que podamos agregar más adelante), pero me gustaría evitar hacer una tabla de comentarios para cada artículo.

La solución que he encontrado hasta ahora parece funcionar, pero estoy abierto a otras ideas también. Mi solución es usar UUID como la clave principal para cada elemento (universidad, colegio, edificio, habitación), y luego tener el ID de referencia en la tabla de comentarios sea ese UUID. Aunque no creo que pueda crear un sistema de claves externas para vincular todo, creo que nada se romperá ya que solo los elementos disponibles pueden tener comentarios, por lo tanto, un elemento no puede tener comentarios, o si se elimina, el los comentarios simplemente nunca serán devueltos.

University: 
    UniversityID - CHAR(36) //UUID()  & primary key 
    ... 

Comments: 
    CommentID - CHAR(36)  //UUID()  & primary key 
    CommentItemID - CHAR(36) //UUID of item & indexed 
    CommentUserID - INTEGER 
    CommentBody - TEXT 

Y luego consultas aparecerán como:

SELECT * FROM University, Comments WHERE UniversityID = CommentItemID; 

Entonces, ¿qué piensan ustedes? ¿Escalará este sistema con grandes cantidades de datos, o hay una mejor (tal vez la mejor práctica o patrón)?

Gracias de antemano.

Edité 1: He alterado la definición del Comentario para incluir una clave principal y una columna indexada para abordar los problemas planteados hasta el momento. De esta manera, el sistema también puede tener comentarios de comentarios (no estoy seguro de cuán confuso sería esto en el código práctico, pero tiene una cierta completitud matemática que me gusta). Sin embargo, quería mantener el sistema lo más similar posible hasta que haya aceptado una respuesta.

Las dos respuestas hasta ahora de Sebastian Good y Bryan M. han sugerido una doble clave primaria de dos enteros que son algo como ItemID y TableID. Mi única duda con este método es que tendría que tener una nueva tabla que enumerara los TableID y sus correspondientes nombres de tabla de cadena, o introducir variables globales en mi código haciendo referencia a ellos. A menos que haya otro método que me falta, esto parece un código extra que puede evitarse.

¿Qué piensan todos?

Answer 1

Bueno, ya que nadie parece querer responder, creo que seguiré con mi método. Sin embargo, aún estaré dispuesto a tomar otras sugerencias.

Answer 2

Simplemente tomaría un enfoque más tradicional de la relación de clave externa entre los comentarios y lo que sea que estén obligados a hacer.

UNIVERSITY 
    UniversityID // assuming primary key 

COMMENTS 
    CommentID // assuming primary key 
    TypeID // Foreign Key 
    Type // Name of the table where the foreign key is found (ie, University) 

Esto me parece un poco más limpio. Algunos sobre el uso de una clave externa de otra tabla como la clave principal para sus comentarios no se sintieron bien.

Answer 3

Si usa un UUID, es difícil saber de qué tabla proviene. Si solo desea mirar desde la entidad hasta los comentarios, como en su consulta, funcionará bien. Si desea ver un comentario y descubrir en qué estaba, tendrá que buscar todas las tablas posibles (universidades, edificios, etc.) para averiguarlo.

Una posibilidad que le permite usar enteros secuenciales simples para las claves de sus entidades base (que a menudo es deseable para legibilidad, fragmentación de índices, etc.) es hacer que la clave de su tabla de comentarios contenga dos columnas. Uno es el nombre de la tabla a la que se aplica el comentario. El segundo es la clave de esa mesa. Esto es similar al enfoque sugerido por Bryan M., aunque tenga en cuenta que no podrá definir las claves externas de la tabla de comentarios para todos los posibles padres. Sus consultas funcionarán en ambos sentidos, si es necesario, y no tendrá que preocuparse por los UUID, ya que la combinación de nombre de tabla + ID será única en toda la base de datos.