Newsgroup: it.comp.lang.delphi
Titolo: Registrazione di un calendario

Salve a tutti.
Quello che pongo è + un problema teorico che altro, ma ci sto ragionando un
po a tempo perso e finora non ho trovato una soluzione accettabile.
Mi spiego con un breve esempio....
Immaginiamo di avere un record master al quale devo legare n date.
Lo scopo è poi avere, data una specifica data, una lista di record nelle cui
n date collegate esiste la data indicata.
Considerate che n è un valore abbastanza variabile ( [1..1000] e che il
numero di record master supera i 500.000....
Ergo, una struttura relazione di tipo standard, basata su una relazione 1-n
tra record master e date comporterebbe la scrittura di n records per ogni
record master con conseguente crescita del db senza contare il tempo
necessario all'inserimento sul db di tutte queste date.
Quindi, sto cercando una soluzione alternativa.
In prima istanza avevo pensato di aggiungere un campo alla record master che
contenesse queste info compresse in qualche modo, ma si tozza col fatto che
una query sql che volesse ottenere lo scopo potrebbe essere costretta a
ciclare sui records e i tempi di ricerca sarebbe molto elevati.
Immaginiamo che un record possa avere un numero massimo di 1000 date di
dettaglio
A questo punto la data potrebbe essere codificata con un solo intero a 16
bit che sarebbe un offset a partire dalla data di inserimento sul db del
record, fermo restando che
16bit * 1000 sono 16000 bit...., ovvero 128000 bytes.
Un numero cosi alto di bytes potrebbe essere registrato solo un un blob.
E qui, se il db non permette la ricerca sui blob, siamo di nuovo al punto di
partenza.
La mia domanda è: qualcuno sa se esiste un algoritmo, design patterns o
altro che permette di gestire un caso del genere?
In questi giorni sto nei casini alla n-esima potenza e appena mi sblocco
faccio qualche ricerca, ma se qualcuno avesse qualche idea, spunto etc,
apprezzerei.
Tnx
A

Quindi, sto cercando una soluzione alternativa.
La relazione non è 1 a molti, ma molti a molti e si risolve, in
termini fisici, con una tabella di dettaglio contenente i campi data e
identificativo del record come chiave primaria.  Potrai, poi,
impostare un indice secondario sul solo campo data.  Tieni presente
che le operazioni su DB sono influenzate dal modo in cui sono
organizzati gli indici.  Se gli indici sono fatti bene (e con una
selettività mirata), anche la presenza di milioni di record non
costituisce un grosso problema (500.000 è una quantità assolutamente
trattabile).
-- 
Andrea Laforgia - a.laforgia(at)
libero.it
"There are three kinds of people in this world; 
 those who are good at maths and those who aren't".

In primis, che fine hai fatto??
Poi, Tnx x la risposta.
Ma allora non esiste proprio un modo diverso di gestire sta cosa?
A

Ma allora non esiste proprio un modo diverso di gestire sta cosa?
Di alternative se ne potrebbero trovare parecchie.  Il problema è che,
secondo me, sarebbero tutte più inefficienti.  Non vedo problemi
particolari nell'avere qualcosa del tipo:
Master   Dettaglio
--------------------------
RecID    Data        RecID
--------------------------  
[1] ---> [14/08/2003][1]
         [15/08/2003][1]
         [16/08/2003][1]
[2] ---> [13/08/2003][2]
         [14/08/2003][2]
         [15/08/2003][2]
[3] ---> [15/08/2003][3]
         [16/08/2003][3]
         [17/08/2003][3]
select RecID from Dettaglio where DATA = '2003/08/15'
Data        RecID
-----------------
[15/08/2003][1]
[15/08/2003][2]
[15/08/2003][3]


Di alternative se ne potrebbero trovare parecchie.  Il problema è che,
Lo sapevo che non l'avevi plonkato.. eh eh.. siete dei veri amici :-)
-- 
Morde. 
(morde at programmer dot net)

eh eh.. siete dei veri amici :-)
E` solo che ho reinstallato FA dopo molto tempo e ho perso tutte le
impostazioni del kill-file.  Quando dico che plonko, lo faccio per
davvero ;-)
