Newsgroup: it.comp.software.database
Titolo: Consiglio su peseudo schema - Prenotazioni ...

dall'admin del software quindi scelta random diciamo
spero di essermi spiegato grazie ciao

 <<altri campi>>
Qualcosa non mi convince qui...
Proviamo ad ipotizzare qualche dato di esempio:
ID_PK  IDStruttura  datainizio  datafine
1      1            1-1-06      2-1-06
2      1            3-1-06      5-1-06
3      1            1-1-06      2-1-06
Il db potrebbe accettare le righe 1 e 3, dato che non c'è violazione
della pk. Domanda: è sempre la stessa prenotazione, magari inserita
per sbaglio due volte nel sistema? O sono due prenotazioni distinte?
Guardando esclusivamente la tabella, semplicemente non riusciresti a
saperlo, dato che la pk (un contatore autoincrementante) non serve
al suo scopo, che è appunto "identificare".
Un database relazionale non è un semplice sistema di stoccaggio dati,
ma è l'implementazione di un modello di dati.
Una buona pk identifica, nel db e nella realtà, una riga del db, in
questo caso una (e sottolineo UNA) prenotazione.
Prova a pensare: come faresti _NELLA REALTA'_ a riferirti ad una
prenotazione? Esempio: "Esiste già una prenotazione all'hotel Xyz dal 5
al 10 marzo?". Ecco la vera PK! IDStruttura + IntervalloDate.
A questo punto io declasserei la vecchia ID prenotazione ad un semplice
"ticket" di prenotazione, un banale handle per la stampa e l'imputazione
dati.
Avevo altre cose da dire, anche sulle altre tabelle, ma ho finito
il tempo :-(
Ciao

 ha scritto nel messaggio 
news:VL0Of.17251$PR2.3...@twister2.libero.it...

Sono assolutamente d'accoro con te diciamo che quello è un problema che ho 
curato poco .
Quello principale o quelli principale sono la parte restante del mio 
messaggio
Ovvero la parte per il calcolo maggiorazioni / sconti per una particolare 
data
e per il calcolo sconti per data (pre stabilite) consecutive esempio un 
weekendetc.
aspetto l'altra parte :-)
ciao

 
Per questo dovresti usare un'altra tabella, magari inventandoti una
sintassi ad hoc per identificare queste date.
tab Specials
  type TEXT PRIMARY KEY -- 'weekend', 'natale', 'capodanno'
  descr TEXT
  spec INTEGER
Ovviamente il tutto dovra' essere poi coordinato da una applicazione
esterna.
Saluti  Manlio Perillo

"Manlio Perillo" <manlio_p...@SPAMlibero.it> ha scritto nel messaggio 
news:jmTOf.20988$A83.5...@twister1.libero.it...

Assolutamente si.
Ok si più o meno stavo arrivando anche io a questa soluzione volevo proprio 
un confronto per capire se esistevano soluzione più "corrette" se così
si possono chiamare il nome della tabella perà mi sembra più azzeccato il 
uto :D
grazie ciao

 aspetto l'altra parte :-)
Sicuramente conviene far fare il più possibile al motore del db, ed il
meno possibile lato programma.
Allora se non ricordo male abbiamo:
- un prezzo base
- un modificatore per struttura in + o - legato alle "stagionalità"
- uno sconto "quantità" legato agli scaglioni di giorni prenotati
- la possibilità finale dell'amministratore di mettere un prezzo a mano
Tabelle:
Strutture { Struttura, PrezzoBase }
VariazioniStagionali { DataInizio, DataFine, VariazionePercentuale }
ScaglioniSconto { GiorniDa, GiorniA, Sconto }
Prenotazioni { Struttura, DataDa, DataA, PrezzoFinale }
(In Prenotazioni.PrezzoFinale puoi inserire il prezzo calcolato dalla
vista o uno diverso)
Viste:
Preventivi { Prenotazioni.Struttura, Prenotazioni.DataDa,
Prenotazioni.DataA, GGPrenotati, Strutture.PrezzoBase, ScontoStagione,
ScontoPerScaglione, PrezzoCalcolato }
Intanto divertiti ad implementare questo nucleo di schema, soprattutto la 
vista; se fai bene ti risparmierai un sacco di lavoro di programmazione.
Poi si può ulteriormente espandere secondo le esigenze.
Ciao