Sistema di badge del sito web

Question

Attualmente sto lavorando a un sito web basato su widget, interamente basato sulla socializzazione degli utenti. Dal momento che un sistema di reputazione paga per attirare utenti, ho deciso di implementare uno di questi.

Ora, vorrei sapere alcune soluzioni su come dovrebbe essere implementato nel modo giusto (prendere, ad esempio, il sistema di badge di Foursquare).

Fondamentalmente, ho bisogno di essere in grado di effettuare le seguenti operazioni:

• avere un tavolo distintivi, dove posso aggiungere, modificare ed eliminare distintivi;
• essere in grado di abilitare e disabilitare un badge;
• essere in grado di introdurre un nuovo badge, ma senza scrivere un nuovo codice - è sufficiente fornire alcuni parametri al modulo di aggiunta del badge per quanto riguarda ciò che deve essere seguito affinché un utente possa ricevere un badge;
• essere in grado di dare badge in tempo reale - il che significa che ogni volta che un utente ottiene tutto ciò di cui ha bisogno per ricevere un badge, il sistema dovrebbe sapere immediatamente di dare il badge a quell'utente;
• Inoltre, il sistema non dovrebbe essere sovraccaricato con "ascoltatori di badge" - credo che interrogare ogni richiesta utente con ogni richiesta di badge richieda tempo;

Questi Detto questo, mi piacerebbe sentire le vostre opinioni su come implementare nel modo giusto un sistema distintivo (logica, dello schema di database, metodi etc.)

Answer 1

Si potrebbe considerare l'uso del modulo di Drupal User Badges o anche guardando come imposta il suo schema.

Answer 2

Database & Live-aggiornamento:
creare una tabella con le colonne come condizioni
ex: risponde - voto - risposta optional ecc ...

ogni volta che un utente effettua una invio o quando gli utenti votano (script sul lato client per l'invio), ricevono un punto/ponts (incrementi numerici nelle colonne della tabella).

sul valore di ritorno (scripting lato client per recuperare), sulla base di istruzioni condizionali che sono associati con le colonne della tabella, un badge è guadagnato.
es:
se voti = 50, raggiungono heplful distintivo
se presente = 10, raggiungono collaboratore top distintivo

da scripting lato client voglio dire ajax o JSON, non sono sicuro di come farebbe lo scripting di un'applicazione live feed

Answer 3

la prima cosa che dovresti fare per avere la struttura adeguata per il tuo progetto quindi iniziare a svilupparlo ... avrai sicuramente molti problemi ma puoi chiedere in qualsiasi momento perché il tuo post qui è ju st generale e qualsiasi risposta non aiuterà nel tuo caso.

ma la tua idea è fantastica :)

Answer 4

Questo suona come un grande progetto. La complessità aumenterà abbastanza velocemente, non importa se lo vuoi o no.

La prima cosa che vorrei fare è iniziare creando la documentazione per l'API.

Quando si dispone di documentazione, è possibile tracciare i requisiti per il progetto. Le cose che hai scritto in questione sono un qualche tipo di requisiti, ma sono immagini troppo astratte e troppo grandi.

Quando hai dei requisiti, inizi a pensare all'ingegneria e alla struttura del software.

In questo passaggio, separare le cose a mio parere è la strada da percorrere. Ciò renderà le cose più facili da gestire. Individuazione degli errori dei colli di bottiglia e così via.

Non so quale sarà il trigger nel sistema per "se l'utente deve ricevere un badge". Quindi sto prendendo l'analogia di Foursquare.

Per essere onesti, i ragazzi stanno facendo un lavoro straordinario per elaborare tutte queste richieste in tempo reale. Voglio dire, sembra che stiano controllando se dovrei ricevere un badge su ogni richiesta. Quindi il mio check-in sta facendo scattare alcuni algoritmi sul lato server per rivedere la mia cronologia di check-in e badge, le regole dei badge, combinarli insieme, creare il mio badge meritato e mostrare il mio nuovo badge in risposta. Sembra molto giusto? Bene, lo è!

Non credo che stiano facendo tutto questo lavoro in parallelo. Questo sarebbe troppo lavoro per un server. Anche se il mio badge quadruplo non interagisce con nessun altro utente (molto più semplice), quindi l'elaborazione parallela non è fuori questione.

Quindi la prima idea di come potrebbe funzionare un quadrilatero. Il bilanciamento del carico inoltra la mia richiesta al server non pesante. E lì tutto il lavoro è fatto in parallelo. Maggiore è il carico, più i server sono accesi. Effettua tutti i calcoli per i badge al volo utilizzando solo il database slave. Presenta all'utente il suo badge e invia questi dati al master db. Questo è possibile, perché i badge non interagiscono tra utenti diversi. Un badge: è necessaria una cronologia utente.

Un'altra soluzione sarebbe quella di utilizzare la mappa - ridurre. Utilizza il broker dei messaggi per elaborare revisioni dei badge in parallelo. Si riceve una richiesta Invia un messaggio al broker dei messaggi. Il messaggio è in fase di pubblicazione su multiple workers dove un lavoratore sta controllando solo una specifica regola del badge contro la cronologia utente. Alla fine, il calcolo sarebbe fatto molto più velocemente.

Informazioni sulla struttura DB. Penso che non ci sia modo di esaminare tutto il db per scoprire se l'utente debba ricevere o meno un badge. Vorrei andare con un modo semplice e diretto di gestirlo. Basta creare un buon db strutturato usando chiavi esterne, tipi di colonne corretti, indici nei punti giusti e starai bene. Costruisci un terreno stabile e ottimizza solo quando è necessario.

Se si desidera davvero ottimizzare l'inizio del progetto (che ritengo sia una cattiva idea), terrei tutti i dati relativi ai badge in tabelle separate. Una tabella per un badge con tutte le colonne specifiche relative a quel badge.

L'esempio sarebbe: badge_restaurants (user_id, badge_id, current_level, checkin_count). Per ricevere il nuovo badge del ristorante dovresti controllare solo se l'utente ha effettuato il checkin_count + 1> = qty necessario e sei libero di non guardare oltre.

Naturalmente, questa non è la soluzione perfetta. È possibile aggiungere più astrazione per farlo in modo più sofisticato (non creare centinaia di tabelle).Ancora, badge più complessi ti spingono a creare soluzioni più complesse.