Best practice per la deprecazione dei dati

Question

Best practice per la deprecazione dei dati

#1 da (1 voti)

0

Ho ereditato un progetto di oltre 10 anni che è stato tramandato da molti sviluppatori. Inutile dire che ci sono molti casi in cui esiste una proprietà di classe o oggetto che nessuno sa a cosa serve o perché esiste. Il codice base e DB scema hanno un disperato bisogno di potatura.

Ovviamente cerco codice, tabelle di database, viste e stored procedure prima ancora di prendere in considerazione la rimozione di qualcosa. Ma dopo aver esaurito tutti i controlli, ho bisogno di andare avanti in qualche modo. Non voglio seguire il percorso degli sviluppatori precedenti che hanno creato molte tabelle "_datestamp" e copie DB nel caso in cui i dati siano necessari in seguito.

C'è una pratica comune per questo?

Il mio pensiero iniziale è quello di creare una tabella DeprecatedObjects in cui avrei una struttura che abbia: ObjectName, ObjectProperty, ObjectPropertyType, ObjectPropertyValue, DeprecatedDate

L'idea è che ho un posto singolo che posso usare nel caso in cui scopro 6 mesi dopo che alcune proprietà venivano lette direttamente da uno dei miei tavoli e ora sono necessarie di nuovo. Mi dà anche un modo semplice per rimuovere oggetti e dati che sono stati deprecati per molti anni.

Questo progetto è in .NET quindi sarebbe bello se ci fosse qualche libreria che già lo fa in un modo standard.

Chiarimento

Quando parlo di "deprecating", intendo che voglio rimuovere classi e proprietà dalle definizioni dell'oggetto e dal database di backup. Ho alcuni oggetti con proprietà multiple che nessuno sa a cosa servono. Per peggiorare le cose, alcuni dei nomi sono decisamente sbagliati (e fuorvianti).

Quindi il mio obiettivo è trovare un modo pulito per iniziare a ripulire il mio grafico degli oggetti, ma ancora eseguire il backup dei dati nel caso in cui ne avessi bisogno in futuro.

c# object-oriented-design deprecation

posta Origin 04.09.2017 - 10:20

fonte

1 risposta

Leggi altre domande sui tag c# object-oriented-design deprecation

Accesso costante statica tramite interfaccia o classe astratta in java senza istanziazione Classe per elenco riepilogato di oggetti complessi

score 1 · Answer 1

Suppongo che tu ti stia riferendo a controllare questa tabella DeprecatedObjects ogni volta che viene utilizzata una particolare tabella / colonna e se non è presente, la aggiungi in modo da avere una chiara idea di cosa viene usato e cosa no . Ho ragione?

Potrebbero esserci librerie che potrebbero dirti quali metodi e classi sono usati, ma penso che il database sia un problema molto più complicato in quanto dipende strongmente dalla tua interfaccia. Quindi il secondo approccio sarebbe quello di aggiungere una sorta di sistema di registrazione che chiarisca quali tabelle e colonne sono usate, e personalmente non mi fiderei di alcuna libreria per farlo per me.

Probabilmente è qualcosa che potresti fare da solo che non avrebbe nemmeno un strong impatto sul tuo programma (con una piccola avvertenza che spiegherò tra un secondo). Ogni volta che viene utilizzata una tabella / colonna, controlla questa tabella DeprecatedObjects e, se non esiste, aggiungila. In 6 mesi di utilizzo intensivo del client, hai una lista che probabilmente descriverà ogni colonna e tabella utilizzata nel tuo database.

Questo sarebbe un controllo orribilmente inefficiente ogni volta, quindi l'avvertenza è di precaricare l'elenco in memoria all'avvio del programma. In questo modo, consumerebbe solo la memoria e non rallenterebbe il programma in modo grave. Ricordati di aggiornare il tuo elenco in memoria quando vengono aggiunti nuovi elementi. Potrebbe essere una buona idea eseguire un controllo della memoria prima e dopo la modifica per vedere se l'impatto della memoria è significativo (saltare da 100 Mb di memoria a 5 GB potrebbe essere un po 'eccessivo).

Inoltre, assicurati di documentarlo completamente. Se dovessi abbandonare il progetto o essere licenziato, non vorrai che questo sistema si trovi nella confusione che tenta di risolvere.