Newsgroup: it.comp.lang.delphi
Titolo: Gestione turni[un po' ot]

Ho gia' chiesto in altri ng ma non mi hanno degnato di 
risposta alcuna quindi posto qui, perdonate semi ot.
Mi ero preso l'impegno di creare un software che gestisse i 
turni della settimana e poi loro son saltati fuori che lo 
vogliono per i vari giorni dell'anno e fare le statistiche a 
fine anno... quindi mi sono inventato di sana pianta questa 
soluzione:
Prima di tutto gli faccio pianificare i turni per ogni 
giorno della settimana(e questo glielavevo fatto!).
Poi siccome i turni si ripeteranno in maniera quasi sempre 
uguale avevo pensato di generare in una tabella del db 
l'intero periodo interessato(il periodo se lo scelgano 
loro),in maniera tale che avessero un planning salvato e poi 
quando uno va in ferie o avvengono cambiamenti nei turni se 
li cambiano manualmente(ci saranno procedure di sostituzioni 
automatiche etc...)
Oppure potrei anche fargli salvare i turni di giorno in 
giorno... boh non ne ho la minima idea,ma perche' esistono 
le persone che cambiano le carte in tavola!!!???
non mi piacciono per niente come soluzioni...
avete consigli o sapete dove posso trovare informazioni  a 
riguardo?
Esistono dei componenti in delphi che gestiscano robe del 
genere?
Ciao && grazie

 automatiche etc...)
senza approfondire troppo, io fossi al posto tuo adotterei la soluzione di 
un "buon" database (che abbia almeno i trigger e stored procedures, tanto 
per capirci), cercando di mettere buona parte della logica che gestisce i 
turni proprio a livello di database. Per esempio:
TABELLA: PERSONE
- ID (primary key)
- COGNOME
- NOME
- ECC
TABELLA: ATTIVITA
- ID (primary key)
- TIPO (stringa, ad es: "turno", "ferie", "malattia", "permesso")
TABELLA: TURNI
- ID (primary key)
- DATAORA_INIZIO
- DATAORA_FINE
- FK_PERSONA (foreign key su 
PERSONE.ID
)
- FK_ATTIVITA (foreign key su 
ATTIVITA.ID
)
La tabella ATTIVITA è read-only cioè ha dei trigger che impediscono 
l'aggiunta, eliminazione o modifica dei record.
Poi crei delle stored procedures utili tipo:
  TURNI_SOVRAPPOSTI(InizioTurnoA, FineTurnoA, InizioTurnoB, FineTurnoB)
che restituisce un valore boolean a seconda che i due turni si 
sovrappongano o meno. 
Oppure:
  TURNI_ADIACENTI(InizioTurnoA, FineTurnoA, InizioTurnoB, FineTurnoB)
se l'inizio del secondo coincide con la fine del primo o viceversa. 
E sarà utile anche:
  TURNO_VALIDO(InizioTurnoA, FineTurnoA)
che restituisce TRUE se InizioTurnoA < FineTurnoA
Poi imposti le regole, per esempio a livello di riga:
  "accetta le modifiche/inserimento di record solo se il turno è valido"
e anche a livello di database, per esempio:
  "in TURNI non può essere aggiunto un nuovo record con lo stesso 
   valore di FK_PERSONA se i turni del nuovo record si sovrappongono
   a quelli già esistenti"
(un turno 00:00 - 08:00, in realtà è 00:01 - 08:00)
-- 
Mauro Falzari
"Chi sarà ricorso a un veleno per pensare,
ben presto non potrà più pensare senza veleno".
  (Charles Baudelaire, in "Le poëme du haschish", Parigi 1890)

 turni proprio a livello di database. Per esempio:
<snip>
grazie per le info dettagliate che mi hai dato tuttavia mi 
rimane il dubbio su questa cosa:l'utente deve salvarsi 
giorno per giorno i turni effettuati o generare un periodo 
che andra' a modificare ogni tanto?

 a modificare ogni tanto? 
Il software che sta sopra al db si occuperà di generare gli orari in base a 
turni o in base a profili personalizzati (operaio, impiegato, turnista, 
caporeparto...). Si può tener conto anche delle festività fisse e mobili 
(vedi calcolare la data della Pasqua). 
Molto superficialmente (bisogna appunto valutare a fondo, sulla base della 
situazione e dei risultati che si vogliono ottenere, *prima* di iniziare a 
scrivere del codice), ricollegandomi all'esempio precedente, si potrebbe 
aggiungere alla tabella TURNI
un campo
- VERIFICATO (boolean, con valore di default FALSE)
Per esempio con le regole che: 
  "non si può cambiare VERIFICATO da FALSE a TRUE per i turni ancora da 
   effettuarsi (ovvero quelle righe in cui DATAORA_FINE è < alla data/ora 
   corrente)"
  "quando VERIFICATO = TRUE, i campi DATAORA_INIZIO e DATAORA_FINE non
   possono essere modificati"
Questi sono solo degli esempi molto semplici, giusto per farti capire che 
io partirei da delle idee di base, generali, per scendere mano a mano nei 
dettagli. Il punto è che una volta stabilite le linee di base, tutto ne 
consegue, per cui quelle non possono più essere cambiate in corso d'opera. 
Per questo ti consiglio di valutare (senza perderti ad approfondire troppi 
dettagli, però) prima quale scenario si può adattare meglio alle tue 
esigenze, e poi realizzare pian piano i dettagli nel modo di volta in volta  
più conveniente (sempre tenendo presente le linee guida). A livello di 
dettagli, gli errori sono facili da correggere perchè investono di solito 
aree limitate, mentre gli errori sulle "linee guida" richiedono molto più 
tempo per essere corretti (se non il rifacimento di gran parte di tutto il 
lavoro...) 
-- 
Mauro Falzari
"La teoria è quando si sa tutto ma non funziona niente. 
La pratica è quando funziona tutto ma non si sa il perchè. 
In ogni caso si finisce sempre a coniugare la teoria con la 
pratica: 
non funziona niente e non si sa il perchè".
  (Albert Einstein)