Mejores prácticas de base de datos

Question

Tengo una tabla que almacena comentarios, el comentario puede provenir de otro usuario u otro perfil que son entidades separadas en esta aplicación.

Mi pensamiento original era que la mesa tendría ambos campos user_id y profile_id, por lo que si un usuario envía un comentario, se da la user_id deja el profile_id blanco

es este derecho, mal, ¿hay una manera mejor ?

Answer 1

En el pasado he usado una tabla de comentarios centralizada y tenía un campo para la tabla fk a la que hace referencia.

por ejemplo:

comments(id,fk_id,fk_table,comment_text) 

esa manera se puede utilizar consultas UNION para concatenar los datos de diversas fuentes.

SELECT c.comment_text FROM comment c JOIN user u ON u.id=c.fk_id WHERE c.fk_table="user" 
UNION ALL 
SELECT c.comment_text FROM comment c JOIN profile p ON p.id=c.fk_id WHERE c.fk_table="profile" 

Esto garantiza que puede ampliar el número de objetos que tienen comentarios sin crear tablas redundantes.

Answer 2

Si los comentarios son generales para varios objetos que podrían crear una tabla para cada objeto:

user_comments (user_id, comment_id) 
profile_comments (profile_id, comment_id) 

entonces usted no tiene que tener ningún columnas vacías en la tabla de comentarios. También hará que sea más fácil agregar nuevos objetos fuente de comentarios en el futuro sin tocar la tabla de comentarios.

Answer 3

Otra forma de resolver es siempre desnormalizar (copiar) el nombre del comentador en el comentario y también almacenar una referencia de regreso al comentarista a través de un tipo y un campo de identificación. De esta forma, tiene una tabla de comentarios unificada donde puede buscar, clasificar y recortar rápidamente. El inconveniente es que no existe una relación FK real entre un comentario y su propietario.

Answer 4

Cualquiera que sea la mejor solución depende en mi humilde opinión de más que solo la tabla, sino también cómo se utiliza en otra parte de la aplicación.

Suponiendo que todos los comentarios están asociados con algún otro objeto, digamos que extrae todos los comentarios de ese objeto. En su diseño propuesto, extraer todos los comentarios requiere seleccionar de una sola tabla, que es eficiente. Pero eso es extraer los comentarios sin extraer la información sobre el póster de cada comentario. Quizás no quieras mostrarlo, o tal vez ya estén en la memoria.

Pero, ¿y si tuvieras que recuperar información sobre el póster mientras recuperas los comentarios? Luego tiene que unirse a dos tablas diferentes, y ahora el conjunto de registros resultante se está contaminando con una gran cantidad de valores NULL (para un comentario de perfil, todos los campos de usuario serán NULL). El código que tiene que analizar este conjunto de resultados también podría volverse más complejo.

En lo personal, yo probablemente comenzar con la versión totalmente normalizado, y luego desnormalizar cuando empiece a ver los problemas de rendimiento

También hay una solución completamente diferente posible al problema, pero esto depende de si es o no hace sentido en el dominio. ¿Qué pasa si hay otros lugares en la aplicación donde un usuario y un póster se pueden usar de manera intercambiable? ¿Qué pasa si un usuario es solo un tipo especial de perfil? Entonces creo que la solución debería resolverse generalmente en las tablas de usuario/perfil.Por ejemplo (algunos abreviados pseudo-SQL):

create table AbstractProfile (ID primary key, type) -- type can be 'user' or 'profile' 
create table User(ProfileID primary key references AbstractProfile , ...) 
create table Profile(ProfileID primary key references AbstractProfile , ...) 

Entonces, cualquier lugar en su aplicación, donde un usuario o un perfil se pueden utilizar indistintamente, puede hacer referencia al LoginID.

Answer 5

Aquí hay otro enfoque, que le permite mantener la integridad referencial a través de claves externas, gestionar de forma centralizada, y proporciona el más alto rendimiento utilizando herramientas de bases de datos estándar, tales como índices y si realmente necesita, etc partición:

create table actor_master_table(
    type char(1) not null, /* e.g. 'u' or 'p' for user/profile */ 
    id varchar(20) not null, /* e.g. 'someuser' or 'someprofile' */ 
    primary key(type, id) 
); 

create table user(
    type char(1) not null, 
    id varchar(20) not null, 
    ... 
    check (id = 'u'), 
    foreign key (type, id) references actor_master_table(type, id) 
); 

create table profile(
    type char(1) not null, 
    id varchar(20) not null, 
    ... 
    check (id = 'p'), 
    foreign key (type, id) references actor_master_table(type, id) 
); 

create table comment(
    creator_type char(1) not null, 
    creator_id varchar(20) not null, 
    comment text not null, 
    foreign key(creator_type, creator_id) references actor_master_table(type, id) 
);