BuzzerBeater Forums

Ritorno sulla questione del DB di valutazioni perchè mi ci sto intrippando! =)

La questione e' delicata perchè se vuoi tanti inserimenti devi garantire dei controlli ..o ci potrebbero finire dentro tutti i miei parenti. Pochi utenti certificati = pochi inserimenti.
E non dimentichiamoci che diventa un DB di giocatori e skills.. senza pesanti filtri uno, usandolo, potrebbe arrivare a conoscere tutti i giocatori della tua squadra.
Dunque un sistema con filtri che non ti permettono di vedere le skills dei giocatori inseriti, diventa simile al sistema attuale di BB (il "Valore di Mercato:" ).
Insomma non e' banale e non so se ne vale la pena!

non si deve inserire nessun riferimento ai giocatori.

il db va organizzato così a mio avviso:
- sono inseriti nel db solo skill, altezza, potenziale, età del giocatore e prezzo. questi dati possono essere combinati con un algoritmo open source (da trovare, ce ne sono) in una chiave univoca (stile firma elettronica) insieme alla data di immissione (usata solo per generare la chiave e non memorizzata nel db)
- essendo univoca ^^ la chiave impedisce qualsiasi doppia immissione (che sballerebbe i dati, ognuno deve poter immettere quel che vuole, ci si deve fidare ovviamente, altrimenti siamo scemi)
- non sapendo la data, è difficile risalire al giocatore a meno di ricerche archeologiche che non riesco ad immaginare

Ritorno sulla questione del DB di valutazioni perchè mi ci sto intrippando! =)

La questione e' delicata perchè se vuoi tanti inserimenti devi garantire dei controlli ..o ci potrebbero finire dentro tutti i miei parenti. Pochi utenti certificati = pochi inserimenti.
E non dimentichiamoci che diventa un DB di giocatori e skills.. senza pesanti filtri uno, usandolo, potrebbe arrivare a conoscere tutti i giocatori della tua squadra.
Dunque un sistema con filtri che non ti permettono di vedere le skills dei giocatori inseriti, diventa simile al sistema attuale di BB (il "Valore di Mercato:" ).
Insomma non e' banale e non so se ne vale la pena!

non si deve inserire nessun riferimento ai giocatori.

il db va organizzato così a mio avviso:
- sono inseriti nel db solo skill, altezza, potenziale, età del giocatore e prezzo. questi dati possono essere combinati con un algoritmo open source (da trovare, ce ne sono) in una chiave univoca (stile firma elettronica) insieme alla data di immissione (usata solo per generare la chiave e non memorizzata nel db)
- essendo univoca ^^ la chiave impedisce qualsiasi doppia immissione (che sballerebbe i dati, ognuno deve poter immettere quel che vuole, ci si deve fidare ovviamente, altrimenti siamo scemi)
- non sapendo la data, è difficile risalire al giocatore a meno di ricerche archeologiche che non riesco ad immaginare

e se lo stesso giocatore viene venduto 2 volte come fai?

e poi il prezzo di vendita non è ricavabile in nessun modo automatico, quindi va comunque messo a manina con tutti i rischi del caso (ci si deve fidare)

sbaglio o la fugata esterna preoccupa parecchio quelli in alto??

Comunque, pensavo, se proprio vogliamo diventare i padroni dell'universo (e senza neanche far la fatica di farsi gli inserimenti a mano) basta realizzare un programmetto che ciclicamente carica la prima pagina delle aste in corso e si salva tutto nel DB.. nomi giocatori, offerta , skills. Tutto opportunamente inserito, con un ciclo di toh, un minuto.. così non e' neanche "scaricamento massivo di dati", e' solo una pagina aperta ogni minuto.
E dopo si che possiamo solo raccomandare l'anima a <scelta facoltativa>!

Non capisco a cosa serva un DB di transazioni di mercato se non e' inserita la data della transazione.
Due anni fa non c'era la stessa economia di oggi. E neanche 7 giorni fa!

Ritorno sulla questione del DB di valutazioni perchè mi ci sto intrippando! =)

La questione e' delicata perchè se vuoi tanti inserimenti devi garantire dei controlli ..o ci potrebbero finire dentro tutti i miei parenti. Pochi utenti certificati = pochi inserimenti.
E non dimentichiamoci che diventa un DB di giocatori e skills.. senza pesanti filtri uno, usandolo, potrebbe arrivare a conoscere tutti i giocatori della tua squadra.
Dunque un sistema con filtri che non ti permettono di vedere le skills dei giocatori inseriti, diventa simile al sistema attuale di BB (il "Valore di Mercato:" ).
Insomma non e' banale e non so se ne vale la pena!

non si deve inserire nessun riferimento ai giocatori.

il db va organizzato così a mio avviso:
- sono inseriti nel db solo skill, altezza, potenziale, età del giocatore e prezzo. questi dati possono essere combinati con un algoritmo open source (da trovare, ce ne sono) in una chiave univoca (stile firma elettronica) insieme alla data di immissione (usata solo per generare la chiave e non memorizzata nel db)
- essendo univoca ^^ la chiave impedisce qualsiasi doppia immissione (che sballerebbe i dati, ognuno deve poter immettere quel che vuole, ci si deve fidare ovviamente, altrimenti siamo scemi)
- non sapendo la data, è difficile risalire al giocatore a meno di ricerche archeologiche che non riesco ad immaginare

e se lo stesso giocatore viene venduto 2 volte come fai?

e poi il prezzo di vendita non è ricavabile in nessun modo automatico, quindi va comunque messo a manina con tutti i rischi del caso (ci si deve fidare)

le skill non è necessario metterle a mano
se io sto vendendo un giocatore mi loggo al sito del DB, inserisco l'ID del giocatore e tutti i dati del giocatore (tranne il prezzo di vendita) si possono prendere in automatico

probabilmente è fattibile, ma non con BBAPI