Práctica recomendada para una tabla de "comentarios" en una base de datos relacional

Question

Suponga que desea compilar una base de datos para alguna aplicación web. Esta base de datos ya contiene muchas tablas y es posible que tenga que ampliarla en el futuro.

Además, desea que el usuario final pueda comentar cualquier tipo de objeto en la base de datos.

Me gustaría encontrar una solución para esto sería lo suficientemente genérica para que no tenga que extenderla cada vez que agrego una nueva tabla en la base de datos.

pensé en lo siguiente:

Nombre de la tabla: Comentario

columnas:

• id: El ID de un comentario
• user_id: la identificación de la usuario que realiza el comentario
• object_table_name: la pestaña le donde el objeto comentado es
• object_id: id del objeto comentado en la tabla object_table_name.
• texto: el texto
• fecha: la fecha

Esta tabla especie de resolver mi problema, lo único que me preocupa es que el aspecto relacional de la misma es más bien débil (no puedo hacer object_id una clave foránea, por ejemplo). Además, si algún día necesito cambiar el nombre de una tabla, tendré que cambiar todas las entradas correspondientes en la tabla de comentarios.

¿Qué opinas de esta solución? ¿Hay algún patrón de diseño que me ayude?

Thanks.-

Answer 1

¿No es ese limpiador?

mesa comment_set

• Identificación

mesa comentario

• Identificación
• comment_set_id -> clave externa a comment_set
• USER_ID
• fecha
• texto

tabla existente foo

• ...
• comment_set_id -> clave externa a comment_set

tabla existente barra de

• ...
• comment_set_id -> clave externa a comment_set

Answer 2

está mezclando datos y metadatos, que no es el mejor patrón de diseño. Deberían estar separados.

Sin embargo, dado que los comentarios no parecen ser muy importantes de todos modos, su solución está bien. Lo peor que puedes terminar es perder comentarios sobre tus objetos.

Algunas bases de datos, más notablemente, PostgreSQL, admiten la cláusula COMMENT solo para casos como este.

Actualización:

Si desea hacer un comentario sobre registros individuales en cada mesa, que está bien tener una tabla de este tipo.

object_table_name no tiene que cambiar si cambia el nombre de una tabla, ya que son datos, no metadatos.

No puede escribir una consulta SQL nativa que obtendrá los comentarios para el registro de cualquier tabla (desconocida en el momento del desarrollo de la consulta), aunque puede crear las consultas dinámicas para hacerlo.

En este caso, deberá mantener sus datos y metadatos sincronizados (UPDATE la tabla de comentarios cuando RENAME la tabla a la que se refieren).La primera es una declaración DML (datos de cambios), la segunda es DDL (metadatos de cambios).

También asegúrese de que todos los PRIMARY KEYs tengan los mismos tipos (igual que object_id).

Answer 3

Lee sobre EAV. Puede hacer que toda su base de datos sea así. Pero entonces será un infierno trabajar con esa información.

¿Por qué no desea colocar un atributo de comentario para cada entidad de base de datos que debe admitir comentarios? De esta forma, puede obtener todos los datos que necesita en una sola consulta, y muchos programas de GUI para bases de datos le proporcionarán la finalización completa del código en SQL, lo que evitará errores que pueden ocurrir fácilmente al operar con cadenas. De esta forma, el código depende en gran medida del código de procedimiento, lo que no es correcto para los sistemas de bases de datos.

Answer 4

Puede enumerar los nombres de la tabla en una tabla separada, de modo que los cambios en los nombres no afecten al sistema de ninguna manera importante. Simplemente actualice la tabla de enumeración.

Aunque te estás alejando de la integridad referencial, puedo ver otra forma de lograr lo que quieres.

Answer 5

Por lo general, prefiero mantener los comentarios con las filas a las que se aplican. Suponiendo que su base de datos almacena de manera eficiente los campos VARCHAR vacíos, no debe pagar una penalización por esto. No hay nada que "ampliar" cuando implementa este enfoque, el mantenimiento del comentario se convierte en parte de las consultas que ya está utilizando para actualizar las filas.

La única ventaja del enfoque de una sola tabla de notas es que permite realizar búsquedas sencillas en las notas para diferentes tipos de entradas de la base de datos.

Answer 6

Asumiendo MS SQL, y si el volumen es relativamente pequeño, como parece sugerir, entonces valdría la pena explorar Extended Properties. Los he usado con éxito en el pasado y parecen ser un accesorio permanente.