architecture - hashtags - ¿La mejor manera de almacenar los criterios de identificación?

architecture hashtags 2018

Question

He estado pensando en cómo implementar la función de insignia similar a SO en un nuevo sitio web. ¿Cuál es la mejor manera de almacenar criterios para insignias?

Dos ideas:

• Todo el código
• ''Segundo sistema'': cree una meta arquitectura para definir insignias y sus criterios. Almacene información en la base de datos y solicite un código para averiguar las insignias y sus criterios.

¿Hay mejores formas?

Answer 1

Estoy de acuerdo con Will en este caso.

Crea "eventos" en las páginas para que cada evento ocurra, es decir. un usuario borra una publicación, consultará el módulo de evento con el evento, digamos, EVENT_USER_DELETE_POST y luego puede seleccionar ese evento y generar una consulta basada en él. A continuación, puede decidir si se otorga una insignia o no.

Esto mantendrá las dos lógicas separadas y mantendrá un diseño modular. Debería ser muy fácil de implementar de esta manera.

El único inconveniente es que si el evento no fue "capturado", entonces un usuario puede haber obtenido un criterio de identificación, pero aún no ha sido recompensado. Sin embargo, esto nunca debería ocurrir. La única situación en la que puedo pensar es si la base de datos se manipula manualmente.

Answer 2

Reglas.

Crea eventos en el sistema y usa reglas dentro de un procesador de secuencia de eventos.

Específicamente, digamos que tiene una insignia "hecha 10 publicaciones". No ejecute "select count (*) desde publicaciones donde user =: user" para cada publicación. Por el contrario, tiene una regla simple que observa cada publicación y "cuenta" almacenando el estado de las reglas en el perfil del usuario.

De esa manera "hizo 10 publicaciones" es tan barato como "hizo 1,000,000" publicaciones.

Esto también hace que el sistema sea mucho más extensible.