Buongiorno a tutti,
sto sviluppando un'applicazione di gestione ticket per un helpdesk online.
Quando un utente crea un ticket, lo script va a creare una tabella nel database denominata "ticketN"
N è un numero progressivo automatico da 0 a 99999.
Mi servirebbe una query che cancelli tutte le tabelle presenti nel database chiamate in quel modo.
Qualcuno ha qualche idea a proposito?
Grazie a tutti, ciao!
Vedo già qualche errore nell'approccio...nel senso di critica costruttiva.
Visto che sei ancora in fase di progettazione, perché non dai una struttura scalabile al database in modo da rendere tutto indicizzabile e molto più performante e veloce come gestione?
Intendo dire che potresti avere una tabella indice nella quale trovi l'id del ticket, data (d.m.Y H:i:s), l'id del richiedente, l'id dell'assegnatario, urgenza, stato (aperto/chiuso) ed eventualmente la lingua (it, en, fr ecc..), una tabella con il contenuto dei ticket (id ticket collegato col prima, testo, data ultimo aggiornamento, id staff nel caso in cui il ticket possa essere spostato da un responsabile all'altro).
Eventualmente puoi creare una funzione di prunning che in pratica cancella o fa il back-up prima di cancellare i ticket più vecchi di tot giorni/mesi/anni. In pratica servirebbero due tipi di pulizia "automatica":
- il primo, che sposta i ticket chiusi da oltre 15-30gg in una tabella "semi-morta" in modo da poter essere ancora interrogati ma allo stesso tempo permette una ricerca veloce nella tabella attiva (quella con i ticket in lavorazione). idem per la tabella dei contenuti dei ticket, usi un cronjob e non ci pensi più
- il secondo, che va a fare il back-up in un file .sql una volta ogni tot mesi di questa tabella semi-morta prendendo come intervallo "fino ad oggi meno 30 giorni" ed a back-up riuscito elimina le stesse voci. Anche qui imposti un cronjob e tutto va in automatico.
In pratica con qualche semplice query avrai un sistema scalabile e performante. Scalabile perché all'id ticket puoi collegare future tabelle di commenti interni tra i componenti dello staff, eventuale report sul carico di lavoro e gradimento dello staff, molto probabile anche una parte contabile se l'azienda decide di fatturare una certa tipologia di ticket ecc ecc...tutte cose che possono essere sviluppate nel futuro. Performante perché invece di avere un database di 100.000 tabelle col rischio di trovare errori tipo "db.table not found" avrai semplicemente una tabella di 100.000 records per gli id dei ticket ed una di 500.000 per le risposte ai ticket (media di 5 risposte/ticket). Non ti preoccupare sulla quantità di records in una tabella, su un server medio ho un database che gira bene con 3Gb di dati (db mysql: la tabella più "corposa" balla tra 900.000 e 1.200.000 records).
In pratica, se fossi in te, darei al tuo database una struttura tipo:
- tickets: id(int, autoincrement), data (datetime), user_id (int), staff_id (int), urgenza_id (int), stato_id (int), language_id (int)
- tickets_contents: content_id (int, autoincrement), ticket_id (int), testo (text oppure blob), data_testo (datetime, on_update(CURRENT_DATETIME)), staff_id (int)
- tickets_old: la stessa identica struttura di tickets, qui vengono messi da parte i ticket di primo back-up
- tickets_contents_old: idem prima
Tralascio di proposito le tabelle linkate come users, staff, tabella stati_ticket (1 = chiuso; 2 = aperto, 3 = chiuso ma ritorno, ecc ), tabella urgenze_ticket (1 = urgentissimo, 2 = urgente ma non troppo, 3 = normale, 4 = fai con calma) e tutte le altre tabelle che possano "contornare" tutto quanto.
