2009-11-16 10 views
29

He estado navegando este sitio para la respuesta, pero todavía estoy un poco inseguro cómo planificar un sistema similar en su estructura y aplicación de base de datos.Logros/sistema Placas

En PHP y MySQL estaría claro que algunos logros se obtienen inmediatamente (cuando se toma una acción especializada, en el caso SO: llenó todos los campos de perfil), aunque sé SO actualizaciones y asigna insignias después de una cierta cantidad de hora. Con tantos usuarios & insignias ¿no sería esto crear problemas de rendimiento (en términos de escala: alto número de usuarios de ambos & insignias).

Así que la estructura de la base Asumo haría algo tan simple como:

Badges  | Badges_User  | User 
---------------------------------------------- 
bd_id  | bd_id   | user_id 
bd_name | user_id   | etc 
bd_desc | assigned(bool) | 
      | assigned_at  | 

Pero como algunas personas han dicho que sería mejor tener un enfoque de estilo incrementales por lo que un usuario que tiene 1.000.000 mensajes en el foro suele ralentizar cualquier función hacia abajo.

¿Sería entonces otra tabla para los pases que podría ser incremental o simplemente un campo de 'progreso' en la tabla anterior badges_user?

Gracias por leer y por favor, se centran en la escalabilidad del sistema deseado (al igual que miles de usuarios y de 20 a 40 tarjetas de proximidad).

EDITAR: para solucionar un poco de confusión que tenía asignado_ como fecha/hora, los criterios para otorgar la insignia estarían mejor ubicados dentro de las consultas/funciones preparadas para cada insignia, ¿no es así? (Mejor flexibilidad)

+0

se comprueban más que otros, así algunas insignias más populares? – bluedaniel

+3

¿Podría aclarar la necesidad de "asignado (bool)"? ¿No es algo redundante ya que no tendrías un mapeo en el primer caso a menos que se te haya asignado el distintivo? ¿Y por qué importaría la cantidad de publicaciones en el foro? – Fredrik

+0

mi primer error! Supongamos que está asignando insignias dependiendo de la cantidad de publicaciones realizadas, es decir, premiando publicaciones altas con buenas insignias -> incentivo para que los usuarios interactúen – bluedaniel

Respuesta

7

Creo que la estructura que ha sugerido (sin el campo "asignado" según los comentarios) funcionaría, con la adición de una tabla adicional, diga "Submissions_User" ", que contiene una referencia a user_id & un campo de incremento para el conteo de envíos. Entonces todo lo que necesitarías es un "oyente de eventos" según el this post y creo que estarías configurado.

EDIT: Para las insignias de logros, ejecute el detector de eventos en cada presentación (sólo para el usuario que realiza la presentación, por supuesto), y la adjudicación ningún logro relevante en el acto. Para las insignias basadas en el tiempo, ejecutaba un trabajo CRON todas las noches. Recorra una vez la lista completa de usuarios y otorgue distintivos según corresponda.

+0

Ok, este es el mejor método, y en términos de implementación, como en mi pregunta SO otorga insignias después de un tiempo determinado, por lo que cada pocas horas y luego es [foreach (insignia)] -> do todos los usuarios o [foreach (usuario)] -> hacer todas las insignias, ¿esto hace la diferencia? Entonces, ¿podría establecer insignias que es menos probable que se otorguen a intervalos más largos, tal vez? pensamientos ... y acepto como una respuesta – bluedaniel

7

en relación con el boceto que incluyó: deshacerse de la columna booleana en badges_user. no tiene sentido allí: esa relación se define en términos del predicado "user user_id obtuvo la insignia bd_id en assigned_at".

en cuanto a su pregunta general: defina el esquema como relacional sin tener en cuenta primero la velocidad (que le librará de la mitad de posibles problemas de perfusión, posiblemente a cambio de diferentes problemas de perfusión), indexe correctamente (lo que es correcto depende de los patrones de consulta), luego, si es lento, deriva un diseño (aún relacional) de aquel que es más rápido. como usted puede necesitar tener algunos agregados precalculados, etc.

4

creo que este es uno de esos casos en los que el muchos-a-muchos mesa (Badges_User) es apropiado.
Pero con una pequeña alteración insignias de manera que no asignados no se almacena.

Asumo assigned_at es una fecha y/u hora.
El valor predeterminado es que el usuario no tiene las insignias.

Badges  | Badges_User  | User 
---------------------------------------------- 
bd_id  | bd_id   | user_id 
bd_name | user_id   | etc 
bd_desc | assigned_at  | 
      |      | 

De esta manera solo se almacenan las insignias realmente otorgadas.
Una fila de Badges_User solo se crea cuando un usuario obtiene una insignia.

Saludos
        Sigersted

+1

Humm ... Veo que es lo mismo que da5id sobre ... – Sigersted

7

Me gustaría mantener una estructura de tipo similar a lo que tiene

Badges(badge_id, badge_name, badge_desc) 
Users(user_id, etc) 
UserBadges(badge_id, user_id, date_awarded) 

y luego agregar mesa (s) de seguimiento dependiendo de lo que desea realizar un seguimiento y @ qué nivel de detalle ... luego puede actualizar la tabla en consecuencia y establecer activadores para "otorgar" las insignias

User_Activity(user_id, posts, upvotes, downvotes, etc...) 

También puede realizar un seguimiento de las estadísticas de la otra dirección demasiado y premios insignia de activación

Posts(post_id, user_id, upvotes, downvotes, etc...) 


Algunos otros aspectos positivos son hechas here

Cuestiones relacionadas