Me gusta o vota por publicaciones

Estoy haciendo un pequeño programa donde los usuarios hacen publicaciones o escriben blogs. En esas publicaciones, a otros usuarios les puede gustar o no la publicación como en Facebook o votar a favor o en contra de la publicación como en stackoverflow. Me gustaría conocer una buena estructura de base de datos que se usa comúnmente y el programa funciona eficientemente con esa estructura. Tengo dos opciones

primero

Enviar:

id   head   message   datepost   likes   dislikes
1     ab    anchdg     DATE      1,2,3   7,55,44,3

De la manera anterior, ides el postid. En la columna de me gusta, se 1,2,3encuentra la identificación del usuario a quien le gustó o votó la publicación o el blog. 7,55,44,3es la identificación de los usuarios a los que no les gustó o rechazaron la publicación o el blog.

Segundo

Enviar:

id    head  message   datepost
1     ab    anchdg     DATE

Gustos:

id    postid    userid
1       1         1
2       2         2

No me gusta:

id    postid    userid
1       1         7
2       1         55

De esta manera, tengo que crear dos tablas separadas para Me gusta y No me gusta para obtener Me gusta de la publicación. De esta manera, las tablas, es decir, Likesy Dislikesse llenarán en gran medida. Esto puede hacer que la mesa sea pesada y el procesamiento lento.

Entonces, ¿me gustaría saber cuál es la forma mejor y estándar de lograr esta tarea?

El problema que enfrenta se conoce como "formas normales" de bases de datos, especialmente la primera forma normal. https://en.wikipedia.org/wiki/First_normal_form .

Su base de datos con los ID de usuario concatenados (primera versión) no está en la primera forma normal.

Vea https://en.wikipedia.org/wiki/Database_normalization para saber por qué y cómo la normalización generalmente se considera buena.

En su primer ejemplo, la consulta para "al usuario 4 ya no le gusta la publicación" se vuelve complicada. Tendrá que realizar operaciones de cadena, que deberán tener en cuenta los efectos secundarios y los casos de esquina (el usuario es el único usuario "que le gusta", el usuario es el último usuario que le gusta, el usuario está en el medio de la cadena de usuario que le gusta). Esto me parece mal. No lo hagas Utiliza un diseño normalizado.

re: la base de datos se vuelve pesada

Si tiene una publicación que tiene 4 millones de me gusta, en el diseño de la base de datos 1 tendría una fila con una columna de "me gusta" que tiene al menos 4 millones de caracteres de ancho (porque necesitará la coma como caracteres de separación). A continuación, deberá realizar operaciones de cadena en cadenas de cuatro millones de dígitos. Esto es muy poco productivo y lento.

Por otro lado, las bases de datos están diseñadas para manejar millones de filas. Tenemos bases de datos con varios cientos de millones de filas y count (): las operaciones son rápidas. Extremadamente rápido. Entonces no, esto no será un cuello de botella en el rendimiento.

El siguiente problema sería la legibilidad y la mantenibilidad.

Por ejemplo, dime qué hacen estas 2 declaraciones:

select count(*)
from posts
inner join likes on posts.postid = likes.postid
where postid = 7

select len(likes) - len(replace(likes, ',', ''))
from posts
where postid = 7

La segunda forma es mucho mejor porque puede agregar o quitar fácilmente un Me gusta / No me gusta.

Pero debe modificar su segunda solución utilizando una tabla para me gusta o no.
Las columnas de la tabla like / dislike deben ser id, postid, userid y otra para el valor de like o dislike, por ejemplo, 1 para dislike y -1 para like.

Establezca post_id y user_id como clave principal compuesta y funciona bien.

El tamaño de la mesa crecerá con el tiempo. pero solo tienes dos columnas reales. El id y el valor de like / dislike. El postid y userid solo están vinculados a él y se almacenan en su usuario y tabla de publicación.