Commenti

Autore: Gabriele Del GiovineInviato il: 07 mar 2010 - 11.40

Secondo me c'è una tabella di troppo visto che gli attributi li sistemi tutti nella Child. Si fa prima e funziona meglio usando un GUID come chiave primaria da usare nelle relazioni ed un attributo che identifica la versione (potrebbe essere il TimeStamp). Una view poi fornirebbe l'ultima versione di ogni oggetto.

Autore: AntonioInviato il: 07 mar 2010 - 17.12

Ciao Gabriele

si, ovviamente è possibile fare come dici, cioè un ID+TS nella tabella da storicizzare, ma così facendo non potrai mai più mettere in FK la chiave ID da sola, visto che la chiave principale della tabella è composta da ID+TS insieme.

differentemente dividendo in due tabelle (normalizzando) le due chiavi, riesci a mettere in FK l'ID con una tabella in cui ti serve l'ultimo valore possibile, e in un altra tabella puoi mettere in FK il TS dove ti serve una versione specifica in linea temporale del valore

ovviamente una vista ti fa sempre comodo per fare la TOP sul TS ed avere sempre l'ultimo valore

Autore: Gabriele Del GiovineInviato il: 07 mar 2010 - 22.13

Veramente la PK è composta dal solo GUID che puoi usare direttamente nelle entità che hanno bisogno di conoscere le condizioni di cambio come FK verso la tabella storico cambi. Ovviamente la tabella Storico Cambi ha i due attributi IDCambio e TimeStamp per poter far funzionare la view che restituisce l'ultima configurazione. Ma IDCambio e Timestamp non costituiscono la PK.

Autore: AntonioInviato il: 07 mar 2010 - 22.33

Si è una soluzione come dicevo prima, ma in quel contesto non hai alcun modo di collegare id o ts come FK presso tabelle in cui sia necessario l'ultimo cambio (quindi solo ID) e tantomeno tabelle per cui sia necessario avere in FK il cambio preciso (ID+TS), tralasciando il tutto eventualmente a logica sparsa in SP o DAL... mentre con la soluzione che ho proposto scarico questa logica sul motore di DB

Autore: Gabriele Del GiovineInviato il: 08 mar 2010 - 09.05

Veramente usare le Stored Procedure o le funzioni è uno dei modi più solidi per scaricare la logica all'interno del DB. Inoltre la view con l'ultima cambio comporta lo stesso tipo di attività di programmazione richiesta dalla tua soluzione. Forse non mi sono spiegato bene: non mi serve mai usare IDCambio e timestamp come elementi di chiavi esterne, la Fk è costituita dal GUID registrato nell'entità a sinistra tale che posso recuperare tutte le condizioni di cambio vigenti al tempo in cui è avvenuta la transazione. QUando viene registrata la transazione si interroga la view o meglio si usa la SP o la funzione apposita e si ottiene il GUID da usare come FK.

Saluti.

Autore: AntonioInviato il: 08 mar 2010 - 19.41

Ciao

credo di aver capito la tua soluzione, tu usi 2 attributi (ID+TS) e come chiave un GUID.
Ma questa chiave rappresenta l'occorrenza storica, in quanto ad un GUID corrisponderà sempre una coppia di ID+TS. certo è come proponi che nulla impedisce di usare il GUID per risalire all'ID solo e quindi fare una TOP sul TS per avere l'ultimo da una vista.

la mia soluzione però, esprime questo in modo vincolato con le due sole PK (PK ID, e PK TS) ansicchè usare le SP, che certo sono un modo robusto di introdurre logica nel DB, ma nel mio caso mi eviterei anche quella, tutto qui

ovviamente poi scegliere cosa si preferisce tra aggiungere una tabella con un solo ID, o un paio di righe in una SP è a cura dello sviluppatore di turno. in entrambi i casi il risultato è ottenuto

ciao, Antonio

Antonio Esposito's

Storicizzazione dei dati, un approccio relazionale

Scrivi un commento

Commenti