salve,
nonmiviene ha scritto:
Hai ragione.
Più o meno E' così:
tabella A, campo indirizzo, record 1 (via G.Garibaldi)
record 7 (via Cavour)
tabella B, campo indirizzo, record 8 (via Giuseppe Garibaldi)
record 11(viale Camillo Cavour)
...
...
Il problema in questione è "trasformare" i record del campo indirizzo della tab. A in quelli della tab. B
Es. il primo record del campo indirizzo della tab. A dovrebbe cambiare da via G.Garibaldi in via Giuseppe Garibaldi (perchè va a leggere quello corretto/simile dalla tab. B)
Non c'è corrispondenza dei campi perchè deve andare a correggere tutti quelli simili ma scritti in maniera diversa rispetto via Giuseppe Garibaldi, es. viale Garibaldi Giuseppe, via Garibaldi, etc.
non la vedo assolutamente facile, visto che in effetti non c'e' riscontro tra le valorizzazioni degli attributi.. per un sistema informativo "Via G. Garibaldi" e "Viale Giuseppe Garibaldi" sono giocoforza 2 valorizzazioni assolutamente diverse in quanto non mi risulta esistano "sistemi intelligenti" in grado di comprendere che in effetti corrispondano alla stessa valorizzazione di attributo..
puoi un po' giocare di pattern matching, ma questo direi al di fuori di una vera e propria istruzione monotonica ed atomica SQL... mi spiego, puoi ad esempio creare e popolare una tabella con i valori DISTINCT di quella che tu vuoi sia quella contenente le valorizzazioni corrette (Indirizzi{Via Giuseppe Garibaldi,Via Camillo Benso conte di Cavour,Via Dante Alighieri} e poi (purtroppo) ciclare la tua tabella Indirizzi "reale" e cercare di indentificare delle ricorrenze in tal senso, modificando il valore dell'attributo in maniera "semi-automatica" nel caso un determimato token venga piu' o meno riconosciuto nella valorizzazione (input:Via G.Garibaldi ~ [circa] token:Via Giuseppe
Garibaldi) ed effettuare la opportuna modifica.. ma, a mio parere, non e' assolutamente semplice definire le "regole" di questo pattern matching.. e chiaramente non lo farei in un batch SQL Server ma predisporrei un apposito applicativo che chiaramente si appoggi su delle tabelle..
ad esempio potresti definire una relazione {tabella#IndirizziCorretti#ChiavePrimaria}->{WorkTb#Token#Pk#Riferimento_a_tabella_corretta}
SET NOCOUNT ON
CREATE TABLE #Indirizzi (
Id int NOT NULL PRIMARY KEY,
Indirizzo varchar(n) NOT NULL
);
CREATE TABLE #Tokens (
Id int NOT NULL PRIMARY KEY,
IdRif int NOT NULL
CONSTRAINT fk_Indirizzi_Tokens
REFERENCES #Indirizzi (Id),
Token varchar(n) NOT NULL
);
INSERT INTO #Indirizzi VALUES ( 1 , 'Via Giuseppe Garibaldi' );
INSERT INTO #Indirizzi VALUES ( 2 , 'Via Camillo Benso conte di Cavour' );
INSERT INTO #Indirizzi VALUES ( 3 , 'Via Dante Alighieri' );
INSERT INTO #Tokens VALUES ( 1 , 1, 'Garibaldi' );
INSERT INTO #Tokens VALUES ( 2 , 2, 'Cavour' );
INSERT INTO #Tokens VALUES ( 3 , 3, 'Alighieri' );
INSERT INTO #Tokens VALUES ( 4 , 3, 'Dante' );
quindi ciclare la tua anagrafica alla ricerca di ogni singolo token (ad esempio "Garibaldi", e qui devi definire una ferrea e consistente logica di validazione dell'attributo) e "sistemare" le occorrenze riscontrate..
se intendi solo effettuare una "sistemata" una tantum delle valorizzazioni puoi anche direttamente modificare la tabella originale, ma se invece intendi approfondire la granularita' del tuo modello, devi provvedere alla normalizzazione della vecchia struttura con una relazione con la nuova tabella contenente i soli indirizzi validi, ma questo diventa un altro discorso..
auguri...
saluti
