[Struttura DB] Creazione di una schedule

[cypi]

Ciao,
devo implementare una sorta di shedule nel mio DB. In pratica ho una serie di attività che durano dal mese x a quello y, e ogni mese all'attività serve un dato numero di risorse. Una cosa tipo il file allegato.

Inizialmente avevo previsto di inserire per ogni record inizio, fine e necessità, ma se queste variano di mese in mese l'input diventa lungo. Per cui devo fare in modo che l'utente compili la riga come se fosse un file excel.
Il problema è: come strutturo il DB? Creo un field per ogni mese (su 10 anni avrei 120 field )? Avete idee più pratiche?

[motogpdesmo16]

Credo sia una relazione n:n traducibile in due 1:n??

Entità 1: Attivita (Id_Attivita , Descrizione, campo1, campo2, campon)
Entità 2: Tempo (Id_Tempo , Mese, Anno)
Entità 3: Attivita_Tempo (Id_Attivita , Id_Tempo , Durata)

Che ne pensi?

[cypi]

E' più o meno quello che avevo fatto all'inizio, tranne che per il fatto che ho messo mese di inizio e mese di fine, invece che durata, ma la gente si lamenta che se l'attività dura 12 mesi e ogni mese cambia il numerino deve inserire 12 record differenti.

Per cui dovrei cambiarla. Ma non trovo nessun altro modo che non implichi uno spreco infinito di risorse.

[motogpdesmo16]

Originariamente inviato da cypi
E' più o meno quello che avevo fatto all'inizio, tranne che per il fatto che ho messo mese di inizio e mese di fine, invece che durata, ma la gente si lamenta che se l'attività dura 12 mesi e ogni mese cambia il numerino deve inserire 12 record differenti .

Per cui dovrei cambiarla. Ma non trovo nessun altro modo che non implichi uno spreco infinito di risorse.

Beh è un problema dell'utente, non dell'architetto del DB! Non è colpa tua se c'è una durata diversa di attività per ogni mese
Tuttavia potresti a livello di interfaccia utente dare una doppia possibilità:
-definire la durata mese per mese (1 record salvato)
-definire la durata in un range di tempo che va dal mese x al mese y (quindi n record salvati, transazionalmente spero).

Potrebbe essere una buona idea?

[cypi]

transazionalmente ??

Gli utenti sono il male dei programmatori

Una doppia interfaccia potrebbe essere un'idea. Magari dopo manipolo i dati per inserirli nel DB come fa comodo a me. Penso che si possa fare.

[motogpdesmo16]

Originariamente inviato da cypi
transazionalmente ??

Gli utenti sono il male dei programmatori

Una doppia interfaccia potrebbe essere un'idea. Magari dopo manipolo i dati per inserirli nel DB come fa comodo a me. Penso che si possa fare.

O i programmatori hanno in mente un'interfaccia sempre troppo complessa per gli utenti??

Comunque per "transazionalmente" intendevo dire che l'operzione di insert di più record deve essere inserita in transazione. Tenendo conto che all'operazione di salvataggio si scatenerà, indicativamente, qualcosa del genere:

INSERT INTO T1 (campo1, campo2) VALUES (valore1, 1) --query per gennaio
INSERT INTO T1 (campo1, campo2) VALUES (valore2, 2) -- query per febbraio
...
...

Se una di queste ti va in errore, allora deve essere annullata l'operazione anche di tutte le altre inserite (rollback) altrimenti avresti dei dati non allineati.

[cypi]

OK. Ho capito.
Questo sicuramente.

Sai, faccio il programmatore di secondo/terzo mestiere. Se parli troppo tecnico mi perdo.