Metodologie consigliate per il refactoring di una grande struttura DB basata su ISAM su un RDBMS?

2

Sto incontrando una bella sfida. Abbiamo un vecchio software sviluppato con applicazioni Delphi e un server di database ISAM (ADS) sottostante 1 , utilizzato con molte tabelle gratuite e programmato manualmente referenziario integrità (se così fosse)

La nostra scadenza per spostare quel pasticcio in un moderno RDBMS è il 2020.

Alcuni dei sistemi server DB preferibili sarebbero

  • MariaDB
  • Postgres

Comunque, quale RDBMS è stato scelto alla fine non è davvero il problema che sto chiedendo. Entro 2 anni è abbastanza sportivo, lasciami spiegare perché:

Abbiamo ~ 17000 installazioni di clienti con strutture DB molto diverse (e personalizzate per i loro processi di workflow) sul campo.

ADS consente di (errare) utilizzare le strutture di directory e quelle tabelle libere , dove le applicazioni spesso creano tabelle come

<db_root>/application_dir/DATA/<KeyX>/<KeyY>/<Year>/TableXYZ.adt

o

<db_root>/application_dir/DATA/<Year>/<KeyX>/<KeyY>/TableXYZ.adt

Sebbene questa tecnica consenta un accesso rapido ai dati utilizzando un componente di TTable di Delphi% o di% query basato su SQL, l'integrità referenziale complessiva di tali dati potrebbe contenere insidie, che nessuno nella società è più a conoscenza.

Sono un po 'in dubbio quali sarebbero i punti chiave / le metodologie per affrontare questo problema.

Credo che

  • Raccolta delle statistiche di utilizzo dalle installazioni del cliente 2
  • Analizzare le strutture presenti da installazioni client particolarmente complesse

potrebbe essere utile per supportare decisioni più fondate quali potrebbero essere i "meno dolorosi" modi di procedere per la migrazione.

Scrivere gli strumenti per farlo costerebbe comunque a priori alcuni sforzi degli sviluppatori.

Inoltre sono (e non sono l'unico tra i miei colleghi) non molto fiducioso nel promosso FireDAC tecnologia.
TBH se è la stessa umile e piena di difetti che vedo nel Delphi System e qualsiasi WinAPI correlato, non sono così sicuro che dovremmo seguire quel percorso (ci sono persino i driver per TDataSet , che potrebbe contenere MySQL ).

ODBC non sarà realmente un'opzione, sarebbe apparentemente troppo lento, troppo generico e produrrà troppo ping-pong di rete , con la struttura e il comportamento attuali delle nostre applicazioni.

Quindi, anche la scrittura dei componenti MariaDB , TTable basati su un driver nativo, viene presa in considerazione.

Quali sono le metodologie consigliate per avvicinarti a quel nodo di Gordian e anche per specificare i requisiti essenziali?

1) Vale la pena ricordare che il sistema è già stato migrato da PARADOX a ADS, in sostituzione di un server DB basato su file ISAM, "pochi" anni fa.

2) Abbiamo già un servizio di analisi delle app che potrebbe essere usato per quello.

    
posta πάντα ῥεῖ 16.02.2018 - 20:06
fonte

1 risposta

0

Poiché non sembrano esserci metodologie standard per affrontare il problema, credo che sia meglio seguire i commenti di @ Doc:

... it pays off for seeking solutions where you need to change as few things as possible in the old codebase.

... better solve one problem after another - solving one of those two problems at a time is hard enough on its own

Penso che sia meglio prima migrare il flusso di lavoro dell'applicazione su RDBMS il più vicino possibile all'attuale implementazione.

Lo "schema DB" è attualmente mantenuto con modelli di tabelle vuoti e un meccanismo di controllo delle versioni che consente la migrazione delle tabelle esistenti a versioni più recenti.

Ho sperimentato un po 'con MariaDB, e questi meccanismi possono essere ben fatti usando i modelli appropriati della struttura della tabella e le stored procedure per gestirli.

I "inappropriati" percorsi di directory usati contenenti valori chiave possono essere modificati in nomi di tabelle contenenti le stesse informazioni.

I problemi con l'integrità referenziale mancante possono essere alleviati un po 'usando i trigger generati.

Dopo che questo passo è stato fatto, e tutte le applicazioni continuano a funzionare come previsto, possiamo avvicinarci a un "reale" refactoring della struttura e dello schema del DB complessivo.

    
risposta data 23.02.2018 - 23:37
fonte

Leggi altre domande sui tag