[MySQL] Consiglio struttura db per promozioni

[fermat]

salve!
vi chiedo consiglio su come strutturare delle tabelle per le promozioni.
cioè, gli amministratori scelgono il valore del premio, la data di inizioni e fine della promozione e le azioni che l'utente deve fare.
di azioni ce ne sono varie tra cui l'admin deve scegliere; ad esempio:
-fare X like su fb
-fare X acquisti
-fare X acquisti e X like
-ecc......

gli admin devono scegliere il regalo e quanti acquisti e/o like devono fare.
come impostare le tabelle?
io per ora ho messo una tabella con questo:
-id
-credito (premio)
-data inizio
-data fine
-attiva (non sono sicuro che serva)

solo che sono indeciso su come proseguire.
mi date un consiglio??

[bomberdini]

Ciao sicuramente una tabella Promozione come hai fatto con campi (id, credito, dataInizio, dataFine)

Poi queste azioni... cosa sarebbero potresti descriverle meglio per capire se vale la pena fare una tabella per le azioni. A cosa servono e che sono?

Un altra cosa importante. Chi utilizzera questo db quali informazioni vorra ricavarci? un buon progetto lo si vede se e' in grado di rispondere e soddisfare le richieste di chi lo usa, altrimenti e' un po vago

[franzauker2.0]

Se le promozioni non sono tante (e non dovrebbero esserlo) e se adotti come requisito che ogni azione abbia esattamente un parametro (anche 2 o 10, ma in numero fisso), puoi codificare le azioni in una stringa

FAILIKE=100;FAIACQUISTI=15;
fai 100 like e 15 acquisti

FAILIKE=27;
significa fai 27 like

Questo ha senso se le azioni possibili sono molte e possono essere anche create a runtime

Se sono poche puoi codificarle direttamente come attributi (colonne) della tabella.

-id
-credito (premio)
-data inizio
-data fine
-attiva (serve,serve)
- quantilike
- quantiacquisti
- quantisolcazzo

[fermat]

intanto grazie per la risposta.

le azioni sono le cose che deve fare l'utente nel periodo di tempo stabilito dagli admin per acquisire un credito.
ad esempio:
-se entro il 30 aprile fai 5 acquisti ti verrano dati 10 crediti
oppure
-se entro il 3 marzo fai tre acquisti e 5 like hai 5 euro di credito

come già detto il credito che si "vince", il tempo, i like e/o gli acquisti da fare devono essere scelti dagli amministratori (li metto come voci del form).

lato utente dovrà comparire la descrizione della promo (aggiungerò un campo TEXT alla tabella promozioni così gli admin scriveranno la descrizione), quanti like e/o acquisti mancano e quando la promo scadrà.

in sostanza il gioco su fa su like e/o acquisti, ma gli admin possono scegliere se bastano solo il like, solo gli acquisti o servono entrambi.
è questo mi complica la vita.

spero di essermi spiegato meglio!!

[fermat]

@franzauker2.0

il set di azioni e le promozioni non saranno tante.
quello che mi complica, come ho detto, è l'incrocio LIKE-ACQUISTI.
la tua soluzione in pratica prevede di parsare la stringa di tipo:
FAILIKE=100;FAIACQUISTI=15;

e poi calcolarsi da qualche altra parte (un'altra tabella) i LIKE-ACQUISTI fatti dall'utente prima della scadenza.
se ho capito bene non è un pò scomodo??

[bomberdini]

Allora una prima idea di soluzione potrebbe essere la seguente :

2 Entita e una relazione quindi 3 tabelle.

Tabella " Promozione "
con attributi : IdPr , credito, dataInizio , dataFine

Tabella " Azione "
con attributi : IdAz, nome, descrizione

Tabella per la relazione " Richiede "
con attributi : idPromozione, idAzione che saranno chiavi esterne rispettivamente per le tabelle Promozione e Azione.

In questo modo se una promozione richiede piu azioni lo rappresenteresti cosi :

RICHIEDE
IdPromozione IdAzione
1 1
1 1

E una query che volesse recuperare una promozione X quali Azioni richiede potrebbe essere strutturata nel seguente modo :

Select r.idAzione
From richiede as r
Where r.idPromozione = X

[bomberdini]

Il modo di rappresentare la tabella richiede si e' impaginato male...

Te lo riscrivo :

RICHIEDE
              IDPROMOZIONE    IDAZIONE
                      1                    1
                      1                    2

[fermat]

potrebbe essere una buona impostazione.

potrei emulare questa struttura per collegare la promozione al cliente.
una tabella di raccordo che avrà idCliente e idPromozione, così da collegare l'utente alla promozione.

poi dovrei salvare i like e gli acquisti, e volendo potrei sempre mettere due campi in questa tabella:
-idCliente
-idPromozione
-countLike
-countAcquisti

che ne dici?

[bomberdini]

Sicuramente puoi aggiungere un entita cliente e relazionarla con promozione come hai detto tu e funzionerebbe.

Per quanto riguarda countLike e countAcquisti se il significato che intendi e' ad esempio numero di Like da dover mettere per poter usufruire della promozione quindi un informazione che hai a priori allora magari potresti metterlo come attributo nella tabella Promozione.
Se invece sono informazioni che non hai a priori ma che devi calcolare e' buona norma non farli attributi ma calcolarli con query.
Comunque e' ragionevole pensare che possano essere info che hai a priori

[fermat]

no aspetta.
da una parte ci sono quanti like e acquisti deve fare l'utente, e lo impostano gli admin in fase cdi creazione della promozione.

dall'altro devo salvare quanti like e acquisti hanno fatto gli utenti prima della scadenza, in modo da dargli il credito quando hanno raggiunto l'obiettivo.
mi domandavo dove salvare queste info.
pensavo nella tabella di raccordo cliente-promozione.