mysql - segundo - Implementando comentarios y me gusta en la base de datos

cuantas consultas por segundo soporta mysql

Question

Soy un desarrollador de software. Me encanta codificar, pero odio las bases de datos ... Actualmente, estoy creando un sitio web en el que un usuario podrá marcar una entidad como preferida (como en FB), etiquetarla y comentar .

Me quedo atascado en el diseño de tablas de la base de datos para manejar esta funcionalidad. La solución es trivial, si podemos hacer esto solo para un tipo de cosas (por ejemplo, fotos). Pero necesito habilitar esto para 5 cosas diferentes (por ahora, pero también supongo que este número puede crecer, a medida que crezca todo el servicio).

Encontré algunas preguntas similares aquí, pero ninguna de ellas tiene una respuesta satisfactoria, así que vuelvo a hacer esta pregunta.

La pregunta es cómo diseñar de manera adecuada, eficiente y elástica la base de datos, de modo que pueda almacenar comentarios para diferentes tablas , gustos para diferentes tablas y etiquetas para ellos. Algún patrón de diseño como respuesta será el mejor;)

Descripción detallada : Tengo una tabla User con algunos datos de usuario y 3 tablas más: Photo con fotografías , Articles con artículos , Places con lugares . Quiero habilitar cualquier usuario registrado para:

• comentar sobre cualquiera de esas 3 tablas

• Marque cualquiera de ellos como gustado

• etiquetar cualquiera de ellos con alguna etiqueta

• También quiero contar la cantidad de me gusta para cada elemento y la cantidad de veces que se usó esa etiqueta en particular.
  
  

^1er enfoque :

a) Para las etiquetas , crearé una tabla Tag [TagId, tagName, tagCounter] , luego crearé tablas de relaciones de muchos a muchos para: Photo_has_tags , Place_has_tag , Place_has_tag .

b) Lo mismo vale para los comentarios.

c) LikedPhotos [idUser, idPhoto] una tabla LikedPhotos [idUser, idPhoto] , LikedArticles[idUser, idArticle] , LikedPlace [idUser, idPlace] . El número de me gusta se calculará mediante consultas (que, supongo que es malo). Y...

Realmente no me gusta este diseño para la última parte, huele mal para mí;)

^2º enfoque :

ElementType [idType, TypeName == some table name] una tabla ElementType [idType, TypeName == some table name] que será ElementType [idType, TypeName == some table name] por el administrador (me) con los nombres de las tablas que pueden ser del agrado , comentario o etiquetado . Entonces crearé tablas :

a) LikedElement [idLike, idUser, idElementType, idLikedElement] y lo mismo para los comentarios y etiquetas con las columnas adecuadas para cada uno. Ahora, cuando quiero hacer una foto como me gusta, insertaré:

typeId = SELECT id FROM ElementType WHERE TypeName == ''Photo''
INSERT (user id, typeId, photoId)

y para lugares:

typeId = SELECT id FROM ElementType WHERE TypeName == ''Place''
INSERT (user id, typeId, placeId)

y así sucesivamente ... Creo que el segundo enfoque es mejor, pero también siento que falta algo en este diseño ...

Por último, también me pregunto cuál es el mejor lugar para almacenar el contador de cuántas veces me gustó el elemento. Solo puedo pensar en dos maneras:

1. en la tabla del elemento ( Photo/Article/Place )
2. por seleccionar conteo ().

Espero que mi explicación del problema sea más completa ahora.

Answer 1

Considere usar tablas por entidad para comentarios, etc. Más tablas: mejor fragmentación y escalado. No es un problema controlar muchas tablas similares para todos los frameworks que conozco.

Algún día necesitarás optimizar las lecturas de dicha estructura. Puede crear fácilmente tablas agrandantes sobre las base y perder un poco en las escrituras.

Una gran mesa con diccionario puede volverse incontrolable algún día.

Answer 2

Definitivamente vaya con el segundo enfoque, donde tiene una tabla y almacena el tipo de elemento para cada fila, le dará mucha más flexibilidad. Básicamente, cuando algo se puede hacer lógicamente con menos tablas, casi siempre es mejor ir con menos tablas. Una ventaja que me viene a la mente ahora sobre su caso particular, considerar que desea eliminar todos los elementos que le gustan de un determinado usuario, con su primer enfoque debe emitir una consulta para cada tipo de elemento, pero con el segundo enfoque se puede hacer con solo una consulta o considere cuándo desea agregar un nuevo tipo de elemento, con el primer enfoque implica crear una nueva tabla para cada tipo nuevo pero con el segundo enfoque no debe hacer nada ...

Answer 3

Esta es una idea general, por favor, no presten mucha atención al estilo de los nombres de campo, sino más a la relación y estructura

Este pseudocódigo obtendrá todos los comentarios de la foto con ID 5
SELECCIONAR * DE acciones
DONDE acciones.id_Stuff = 5
AND actions.typeStuff = "foto"
Y actions.typeAction = "comment"

Este pseudocódigo obtendrá todos los "Me gusta" o usuarios a los que les haya gustado la foto con ID 5.
(Puede usar count () para obtener solo la cantidad de me gusta)

SELECT * FROM actions
WHERE actions.id_Stuff = 5
AND actions.typeStuff="photo"
AND actions.typeAction = "like"

Answer 4

La solución más extensible es tener una sola tabla "base" (conectada a "me gusta", etiquetas y comentarios) y "heredar" todas las otras tablas de la misma. Agregar un nuevo tipo de entidad implica simplemente agregar una nueva tabla "heredada"; luego se conecta automáticamente a toda la maquinaria de tipo / etiqueta / comentario.

El término de relación de la entidad para esto es "categoría" (ver la sección de Guía de métodos de ERwin : "Relaciones de subtipo"). El símbolo de categoría es:

Suponiendo que un usuario puede querer varias entidades, se puede usar una misma etiqueta para más de una entidad, pero un comentario es específico de la entidad, su modelo podría verse así:

Por cierto, hay aproximadamente 3 formas de implementar la "categoría ER":

• Todos los tipos en una tabla
• Todos los tipos de concreto en tablas separadas.
• Todos los tipos concretos y abstractos en tablas separadas.

A menos que tenga requisitos de rendimiento muy estrictos, el tercer enfoque es probablemente el mejor (es decir, las tablas físicas coinciden con las entidades del diagrama 1: 1).

Answer 5

Mire los patrones de acceso que va a necesitar. ¿Alguno de ellos parece haber hecho particularmente difícil o ineficiente mi opción de diseño o la otra?

Si no favorece el que requiere menos tablas

En este caso:

1. Agregar comentario: o eliges una tabla muchos / muchos particular o insertas en una tabla común con un identificador específico conocido para lo que se quiere, creo que el código del cliente será un poco más simple en tu segundo caso.
2. Buscar comentarios para el elemento: aquí parece que usar una tabla común es un poco más fácil, solo tenemos una consulta única parametrizada por tipo de entidad
3. Buscar comentarios de una persona sobre un tipo de cosa: simple consulta en cualquier caso
4. Encuentre todos los comentarios de una persona sobre todas las cosas: esto parece un poco retorcido de cualquier manera.

Creo que su enfoque "discriminado", opción 2, genera consultas más simples en algunos casos y no parece mucho peor en los demás, así que me gustaría ir con eso.

Answer 6

Ya que "odias" las bases de datos, ¿por qué estás tratando de implementar una? En cambio, solicita ayuda de alguien que ama y respira estas cosas.

De lo contrario, aprende a amar tu base de datos. Una base de datos bien diseñada simplifica la programación, la ingeniería del sitio y suaviza su funcionamiento continuo. Incluso un diseñador d / b experimentado no tendrá una previsión completa y perfecta: se necesitarán algunos cambios de esquema en el futuro a medida que surjan patrones de uso o cambien los requisitos.

Si se trata de un proyecto de un solo hombre, programe la interfaz de la base de datos en operaciones simples utilizando procedimientos almacenados: add_user, update_user, add_comment, add_like, upload_photo, list_comments, etc. No incruste el esquema en ni siquiera una línea de código. De esta manera, el esquema de la base de datos se puede cambiar sin afectar ningún código: solo los procedimientos almacenados deben conocer el esquema.

Puede que tenga que refactorizar el esquema varias veces. Esto es normal. No te preocupes por hacerlo perfecto la primera vez. Simplemente hágalo lo suficientemente funcional como para crear un prototipo de un diseño inicial. Si tiene el lujo del tiempo, utilícelo un poco, y luego elimine el esquema y vuelva a hacerlo. Siempre es mejor la segunda vez.

Answer 7

hasta donde yo entiendo. Se requieren varias tablas. Hay una relación de muchos a muchos entre ellos.

• Tabla que almacena los datos del usuario como nombre, apellido, fecha de nacimiento con un campo de identidad.
• Tabla que almacena tipos de datos. estos tipos pueden ser fotos, acciones, enlaces. cada tipo debe tener una tabla única. por lo tanto, existe una relación entre sus tablas individuales y esta tabla.
• cada tipo de datos diferente tiene su tabla. por ejemplo, actualizaciones de estado, fotos, enlaces.
• la última tabla es para muchas a muchas relaciones, almacenando una identificación, identificación de usuario, tipo de datos e identificación de datos.