Redgate Hub
introduktion
Der er flere grunde til, at du muligvis skal sammenligne tabeller eller resultater.
- nogle gange skal man bare vide, om tabellerne indeholder data, der er ens eller forskellige; Ingen detaljer: bare ja eller nej. Dette er typisk med testkrav, hvor du bare skal vide, om din rutine eller batch producerer et resultat med de rigtige data i den. når de er forsynet med særlige vales for parametrene. Det er enten forkert eller rigtigt
- lejlighedsvis skal du vide, hvilke rækker der er ændret uden måske at være særlig om, hvilke kolonner der er ændret, og hvordan.
- der er tidspunkter, hvor du har et stort bord med hensyn til både kolonner og rækker, og du har brug for noget, der specifikt viser de kolonner, der ændrede deres værdi. Du vil måske også have dette, når du sporer en fejl i en rutine, der ellers kan kræve, at du spilder tidsscanning ‘ved øje’.
Vi vil tackle disse tre ret forskellige opgaver i
Hvis to tabeller har et andet antal rækker, kan de selvfølgelig ikke være de samme. Der er dog tidspunkter, hvor du skal vide, om Table_B indeholder alle rækkerne af Table_A uden forskelle. Hvis du ønsker flere detaljer, kan du endda ønske at kende rækkerne i enten tabel, der ikke er fælles, eller de fælles rækker, som angivet med den primære nøgle, der var forskellige. Hvorfor holde sig til at sammenligne kun to tabeller? Der er måder at sammenligne så mange som du har brug for. (som for eksempel når du sammenligner metadataene i flere database snapshots). Ja, der er mange variationer
du har værktøjer og funktioner til at gøre disse ting, sikkert?
der er altid plads til værktøjer som f.eks. Meget afhænger af omstændighederne og typen af opgave. Problemet med at foretage revisioner af ændringer i data i et live-system er et separat emne, ligesom synkronisering af tabeller og databaser. Sammenligning af dokumenter er også uden for rækkevidde. Jeg vil højst sandsynligt bruge tskl-teknikker til at sammenligne tabeller, når:
udvikling…
i løbet af udviklingen af en database sammenlignes mange tabeller. Det er ikke kun de store ting: hver bordværdsat funktion har for eksempel brug for en testsele i build-scriptet, der sørger for, at det gør, hvad du synes, det skal gøre under alle tænkelige testforhold, og inkorporerer alle de grimme kantsager, hvor det tidligere er blevet fanget af testerne. Hver gemt procedure har brug for en test for at sikre, at den proces, den udfører, gør præcis, hvad der er beregnet og intet andet.
der var en tid, hvor build-aktiviteten var temmelig afslappet, men når du har en natlig build-og integrationstest, er det bedst at automatisere det helt og slippe af med opgaven.
ETL
når du automatiserer indlæsningen af data i et system, skal du ofte teste forskellige forhold. Har du brug for at opdatere eksisterende versioner af rækkerne samt indsætte de nye? Har du brug for en fælde for at forhindre duplikatposter eller endda slette eksisterende poster?
opsætning af testdata.
scripts i denne artikel bruger alle en tabel fra den ærværdige pubber database. Vi skal bruge forfattertabellen, men vil øge antallet af rækker lidt til 5000 for at få en størrelse, der er lidt mere realistisk. Jeg har givet kilden til tabellen med artiklen.
I then created a copy of the table …
|
1
2
3
4
5
6
|
SELECT * INTO authorsCopy
FROM authors
GO
ALTER TABLE dbo.authorsCopy Tilføj begrænsning PK_AUTORSCOPY primær nøgle grupperet
(au_id) på primær
gå
|
og derefter ændret nogle af rækkerne.
|
1
2
3
4
5
|
Opdater forfatterekopi sæt adresse=ting(adresse,1,1,”)
hvor au_id i (
vælg top 10 au_id
fra authorscopy f
bestil via telefon)
|
så nu skal de to tabeller overvejende være de samme med et par mindre ændringer i adressefeltet
test for at se om tabeller er forskellige.
Nogle gange vil du bare vide, om tabeller er de samme. Et eksempel på dette ville være at kontrollere, at en TVF fungerer korrekt ved at sammenligne resultatet med resultatet af en eksisterende tabel med de korrekte resultater. Den sædvanlige måde at gøre dette på er med CHECKSUM()gruppen af funktioner i en server, fordi de er meget hurtige.
brug af Checksums
Du kan bruge funktionenBINARY_CHECKSUM til at kontrollere, om tabeller er de samme: godt, omtrent det samme. Det er hurtigt, men det er ikke perfekt, som jeg vil demonstrere om et øjeblik. Hvis du for eksempel har en række tests, er det generelt tilstrækkeligt.
|
1
2
3
4
5
6
7
8
9
|
if (
vælg checksum_agg(binary_checksum(*))
fra forfatterne)=(
vælg checksum_agg(binary_checksum(*))
fra forfatterskopi)
vælg ‘de er sandsynligvis de samme’
andet
vælg ‘de er forskellige’
|
for at dette skal fungere, må din tabel ikke have TEXT, NTEXT, IMAGE or CURSOR (eller a SQL_VARIANT med nogen af disse typer) som basistype. I dag er dette i stigende grad sjældent, men hvis du har nogen form for komplikation, kan du tvinge enhver kolonne med en af de ikke-understøttede typer til en understøttet type. I praksis bruger jeg generelt en rutine, der kontrollerer metadataene og gør det automatisk, men det er ikke smukt.
i en arbejdsversion vil du sandsynligvis gerne angive listen over kolonner, især hvis du skal gøre en eksplicit tvang af datatyper, eller hvis du kun kontrollerer bestemte kolonner,
hverken BINARY_CHECKSUM() eller dens almindelige søster CHECKSUM() er helt nøjagtige til at fortælle dig, om noget har ændret sig i en række eller tabel. Vi viser dette ved at se på det engelske sprogs almindelige ord, indeholdt i en tabel kaldet CommonWords.. Du forventer, at de alle har et andet checksum, men det er ikke tilfældet.
|
1
2
3
4
5
6
7
8
9
|
vælg streng, binary_checksum(streng) som “checksum”
fra almindelige ord
hvor binary_checksum(streng) i
(
vælg binary_checksum(streng)
fra almindelige ord
gruppe af binary_checksum(streng)
have count(*) > 2)
ORDER BY BINARY_CHECKSUM(string)
|
… giver resultatet …
bevæbnet med disse oplysninger kan vi hurtigt demonstrere, at forskellige strenge kan have den samme værdi som samme kontrolsum
|
1
2
3
|
vælg binary_checksum(‘Reed The Nerd’),
binary_checksum(‘sagsøgt reden’),
BINARY_CHECKSUM(‘stud the oust’)
|
All these will; have the same checksum, as would …
|
1
2
3
|
SELECT
BINARY_CHECKSUM(‘accosted guards’),
BINARY_CHECKSUM(‘accorded feasts’)
|
….mens…
|
1
2
3
|
vælg binary_checksum(‘dette ligner meget det næste’),
binary_checksum(‘dette ligner meget det næste’),
binary_checksum(‘dette ligner meget det næste’)
binary_checksum (‘dette ligner meget det næste’)
|
… giver dig forskellige kontrolsummer som denne…
|
1
2
|
———– ———– ———–
-447523377 -447522865 -447654449
|
The sister function CHECKSUM() …
|
1
2
3
4
|
SELECT CHECKSUM(‘This looks very much som det næste’),
CHECKSUM(‘dette ligner meget det næste’),
CHECKSUM(‘dette ligner meget det næste’)
|
… finder dem alle de samme, fordi det bruger den aktuelle sortering, og min sortering til databasen er case-ufølsom. CHECKSUM() sigter mod at finde strenge lige i checksum, hvis de er ens i en streng sammenligning.
|
1
2
|
———– ———– ———–
-943581052 -943581052 -943581052
|
så det bedste du kan sige er, at der er en stor sandsynlighed for, at tabellerne vil være de samme, men hvis du skal være helt sikker, så brug en anden algoritme.
Hvis du ikke har noget imod forskel i tilfælde i tekststrenge, kan du bruge CHECKSUM() i stedet for BINARY_CHECKSUM()
den store værdi af denne teknik er, at når du først har beregnet det kontrolsum, du har brug for, kan du gemme det som en værdi i kolonnen i en tabel i stedet for at have brug for den originale tabel, og derfor kan du gøre hele processen jævn hurtigere og tager mindre tid. Hvis du gemmer checksumværdien returneret af CHECKSUM() sørg for at tjekke MOD live bordet med et checksum genereret med samme sortering.
Her er et simpelt eksempel på ‘hvad er ændret’ rutine.
|
1
2
3
4
5
6
7
8
10
11
12
13
14
15
|
– vi opretter en ‘checksum’ tabel ‘på farten’ ved hjælp af Vælg ind.
vælg
au_ID,
BINARY_CHECKSUM(au_id, au_lname, au_fname, telefon, by , lynlås,) som
i auchk
fra forfatterskopi
Bestil af au_ID
/ * nu sætter vi en begrænsning bare for at kontrollere at vi ikke har vundet lotteriet (meget usandsynligt , men ikke helt umuligt, at vi har to rækker med samme checksum) * /
Alter Table auchk Tilføj begrænsning isitunik unik ()
update authorscopy set au_fname=’Arthur’
hvor au_id=’327-89-2366′
vælg authorscopy.*
FROM authorscopy
INNER JOIN AuChk ON authorscopy.au_ID=AuChk.au_ID
WHERE <>BINARY_CHECKSUM(authorscopy.au_id, au_lname, au_fname, phone, , city, , zip, )
|
…which gives…
|
1
2
3
|
au_id au_lname au_fname phone address city state zip contract
———– ——— ——— ———— ————— ————- —– —– ——–
327-89-2366 Mendoza Arthur 529275-5757 15 Hague Blvd. Little Rock of 98949 1
|
og så rydder vi bare op.
|
1
2
3
|
/* og vi bare pop det tilbage til, hvad det var, som en del af nedrivningen */
update authorscopy set au_fname=’Arnold’
hvor au_id=’327-89-2366′
|
selvfølgelig kan du bruge en trigger, men nogle gange vil du måske bare have en daglig eller ugentlig rapport om ændringer uden indtrængen af en trigger i en tabel.
en generel mulighed er at sammenligne versionen af de to tabeller, da dette gør datatype oversættelsen til strenge for dig. Det er langsommere end Checksummetoden, men mere pålidelig.
1
2
3
4
5
6
7
8
9
10
IF CONVERT(VARCHAR(MAX),(
SELECT *
FROM authors ORDER BY au_id FOR XML path, root))
=
CONVERT(VARCHAR(MAX),(
SELECT *
FROM authorscopy ORDER BY au_id FOR XMLpath, root))
SELECT ‘they are the same’
ELSE
vælg’ de er forskellige ‘
|
1
2
3
4
5
6
7
8
9
10
|
IF CONVERT(VARCHAR(MAX),(
SELECT *
FROM authors ORDER BY au_id FOR XML path, root))
=
CONVERT(VARCHAR(MAX),(
SELECT *
FROM authorscopy ORDER BY au_id FOR XMLpath, root))
SELECT ‘they are the same’
ELSE
vælg’ de er forskellige ‘
|
Her kan du angive sammenligningstypen ved at angive sorteringen.
eller du kan gøre dette ved at sammenligne data i tabeller ..
|
1
2
3
4
5
6
7
8
9
10
|
IF BINARY_CHECKSUM(CONVERT(VARCHAR(MAX),(
SELECT *
FROM authors ORDER BY au_id FOR XML path, root)))
=
BINARY_CHECKSUM (CONVERT(VARCHAR(MAX),(
SELECT *
FROM authorscopy ORDER BY au_id FOR XML path, root)))
vælg ‘de er stort set de samme’
ELSE
vælg ‘de er forskellige’ Vælg ‘de er forskellige’
|
… Ved at beregne et kontrolsum af tabellen. Dette giver dig mulighed for at gemme kontrolsummen for den tabel, du sammenligner med.
Find hvor forskellene er i en tabel
den enkleste opgave er, hvor tabellerne har et identisk antal rækker og en identisk tabelstruktur. Nogle gange vil du vide, hvilke rækker der er forskellige, og hvilke der mangler. Du skal selvfølgelig angive, hvad du mener med ‘det samme’, især hvis de to tabeller har forskellige kolonner. Den metode, du vælger at foretage sammenligningen, bestemmes generelt af disse detaljer.
foreningen alle … gruppe efter teknik
den klassiske tilgang til sammenligning af tabeller er at bruge enUNION ALL forSELECT udsagn, der inkluderer de kolonner, du vil sammenligne, og derefterGROUP BY disse kolonner. For at dette skal fungere, skal der naturligvis være en kolonne med unikke værdier i GROUP BY, og den primære nøgle er ideel til dette. Hverken tabel er tilladt dubletter. Hvis de har forskellige antal rækker, vises disse som forskelle.
|
1
2
3
4
5
6
7
8
10
11
12
vælg distinkt au_id
fra
(
vælg au_id
fra
(
vælg au_id, au_lname, au_fname, telefon, Adresse, By, stat, lynlås, kontrakt
fra forfattere
Union alle
vælg au_id, au_lname, au_fname, telefon, Adresse, By, stat, lynlås, kontrakt
fra forfatterskopi) BothOfEm
gruppe af au_id, au_lname, au_fname, telefon, Adresse, By, stat, lynlås, kontrakt
have COUNT(*)<2) f
|
Hvis en af tabellerne har et duplikat, vil det give dig et falsk resultat, som her, hvor du har to tabeller, der er meget forskellige, og resultatet fortæller dig, at de er de samme! Af denne grund er det en god ide at inkludere de kolonner, der udgør den primære nøgle, og kun inkludere rækkerne en gang!
|
1
2
3
4
5
6
7
8
10
11
12
13
14
15
16
17
18
20
21
22
23
|
vælg count(*), address_id,theaddress,thepostcode
fra
(
select Adresse_id,adresse,Postkode
fra
(
værdier
(9, ‘929 Augustine lane, Staple Hill afdeling South Gloucestershire UK’,’BS16 4LL’),
(10, ’45 Bradfield road, Derbyshire UK’,’DE6 1KN’)
) Tablea(Address_id,theaddress,thepostcode)
union alle
vælg address_id,theaddress,thepostcode
fra
(
værdier
(8, “‘Pippins”, 20 Gloucester PL, CHIRTON afdeling, Tyne & Wear UK’,’NE29 7AD’),
(8, ”’The Pippins”, 20 Gloucester Pl, Chirton Ward, Tyne & Wear UK’,’NE29 7AD’),
(9, ‘929 Augustine lane, Staple Hill Ward South Gloucestershire UK’,’BS16 4LL’),
(10, ’45 Bradfield road, Parwich Derbyshire UK’,’DE6 1QN’)
) TableB(Address_ID,TheAddress,ThePostCode)
)f
GROUP BY Address_ID,TheAddress,ThePostCode
HAVING COUNT(*)<2
|
… giving …
|
1
2
3
4
|
TheCount Address_ID TheAddress ThePostCode
———– ———– ————————- ————
(0 række(r) berørt)
|
teknikken kan bruges til at sammenligne mere end to tabeller. Du skal bare UNION ALLtabellerne du skal sammenligne og ændreHAVING klausul for at filtrere kun de rækker, der ikke er i alle tabellerne.
brug undtagen
Du kan nu bruge den meget renere og lidt hurtigereEXCEPT.
|
1
2
3
|
vælg * fra forfattere
vælg * fra forfatterskopi
|
Dette viser alle rækker i forfattere, der ikke findes i authorscopy. Hvis de er de samme, ville det returnere ingen rækker
|
1
2
3
4
5
6
8
9
10
11
12
13
14
|
au_id au_lname au_fname telefonadresse bystat lynlås kontrakt
———– ———– ——— ———— ————————– ———– —– —– ——–
041-76-1076 Sosa Sonja 000-198-8753 29 Second Avenue Omaha CT 23243 0
187-42-2491 Mc Connell Trenton 0003090766 279 Haag måde San Diego NY 94940 1
220-43-7067 ræv Judith 000-137-9418 269 East Haag Street Richmond VA 55027 0
505-28-2848 Hardy Mitchell 001-2479822 73 green Milton drive Norfolk VA 69949 1
697-84-0401 Montes Leanne 000-018-0454 441 East Oak Parkvej San Antonio MD 38169 1
727-35-9948 lang Jonathon 000-8761152 280 Nobel Avenue Anchorage La null 1
875-54-8676 sten Keisha 000-107-1947 763 hvid Fabien måde Fremont ND 08520 0
884-64-5876 Keller Steven 000-2787554 45 hvid Nobel Boulevard Milvaukee NY 29108 1
886-75-9197 Ellis Marie 001032-5109 35 øst anden Boulevard Chicago IL 32390 1
975-80-3567 Johanna 001-028-0716 17 nye Boulevard Jackson nd 71625 0
(10 række(r) berørt)
|
Jeg bruger kun select * for at holde tingene enkle for de Artikel. Du specificerer normalt alle de kolonner, du vil sammenligne.
Dette fungerer kun for tabeller med det samme antal rækker, fordi hvis forfattere havde ekstra rækker, ville det stadig sige, at de var forskellige, da rækkerne i forfattere, der ikke var i authorsCopy, ville blive returneret. Dette skyldes, at EXCEPT returnerer alle forskellige værdier fra forespørgslen til venstre for EXCEPT operand, der ikke også findes fra forespørgslen til højre
Dette viser forhåbentlig hvad jeg mener
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
Vælg adresse_id,adresse,Postkode
fra
(værdier
(9, ‘929 Augustine lane, Staple Hill afdeling South Gloucestershire UK’,’BS16 4LL’),
(10, ’45 Bradfield road, Parbyshire UK’,’DE6 1KN’)
) TableA(Address_ID,TheAddress,ThePostCode)
undtagen
vælg address_id,theaddress,thepostcode fra
(værdier
(8, “‘the Pippins”, 20 Gloucester pl, chirton afdeling, Tyne & brug UK’,’ne29 7AD’),
(8, “‘Pippins”, 20 Gloucester pl, chirton afdeling, Tyne & Wear UK’,’NE29 7AD’),
(9, ‘929 Augustine lane, Staple Hill Ward South Gloucestershire UK’,’BS16 4LL’),
(10, ’45 Bradfield road, Parwich Derbyshire UK’,’DE6 1QN’)
) TableB(Address_ID,TheAddress,ThePostCode)
|
…yields …
|
1
2
3
4
|
Address_ID TheAddress ThePostCode
———– ———————————————- ———–
(0 række (r) berørt)
|
…mens …
|
1
2
3
4
5
6
7
8
10
11
12
13
14
|
vælg Adresse_id,adressen,Postkoden fra
(værdier
(8, “‘Pippinerne”, 20 Gloucester Pl, Chirton afdeling, Tyne & brug UK’,’NE29 7AD’),
(8, “‘Pippinerne”, 20 Gloucester Pl, Chirton afdeling, Tyne & brug UK’,’ne29 7AD’),
(9, ‘929 Augustine Lane, hæfteklammer Hill afdeling syd Gloucestershire UK’,’BS16 4LL’),
(10, ’45 Bradfield road, parbyshire UK’,’DE6 1KN’)
) tabelb(Address_id,Theaddress,thepostcode)
undtagen
vælg Address_id,Theaddress,Thepostcode
fra
(værdier
(9, ‘929 Augustine lane, Staple Hill afdeling South Gloucestershire UK’,’BS16 4LL’),
(10, ’45 Bradfield road, Parbyshire UK’,’DE6 1KN’)
) TableA(adresse_id,adresse,Postkode)
|
..results in …
|
1
2
3
4
5
|
Address_ID TheAddress ThePostCode
———– ————————————————————- ———–
8 ‘The Pippins’, 20 Gloucester Pl, Chirton Ward, Tyne & Wear UK NE29 7AD
(1 row(s) affected)
|
Denne funktion af EXCEPTkunne bruges til fordel, hvis du især ønsker at kontrollere, at TableAer indeholdt i TableB. Så hvor tabellerne har et andet antal rækker, kan du stadig sammenligne dem.
du vil måske ikke sammenligne alle kolonner. Du skal altid angive de kolonner, du ønsker at sammenligne for at bestemme ‘ensartethed’. Hvis du kun ønskede at sammenligne adressen for eksempel, ville du bruge …
|
1
2
3
|
Vælg adresse fra forfattere
undtagen
Vælg adresse fra forfatterekopi
|
den ydre sammenføjningsteknik
der er også teknikken til den ydre sammenføjning. Dette er en mere generel teknik, der giver dig yderligere faciliteter. Hvis du for eksempel bruger den fulde ydre joinforbindelse, kan du få de uovertrufne rækker i begge tabeller. Dette giver dig et’ før ‘og’ efter ‘ billede af ændringer i dataene. Det bruges mere generelt i synkronisering til at fortælle dig, hvilke rækker du skal slette, indsætte og opdatere.
We’ll just use the technique to get the altered rows in authorsCopy
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
SELECT authors.au_id, authors.au_lname, authors.au_fname, authors.phone, authors.address, authors.city, authors.state, authors.zip, authors.kontrakt
fra forfattere
venstre ydre JOIN authorsscopy
on authors.au_ID = AuthorsCopy.au_ID
and authors.au_lname =authorsCopy.au_lname
and authors.au_fname =authorsCopy.au_fname
and authors.au_fname = authorsCopy. au_fname
and authors. au_fname = authorsCopy. au_fname
and authors.telefon = authorsCopy.telefon
og COALESCE (forfattere.adresse,”)=COALESCE(authorsCopy.adresse,”)
og COALESCE (forfattere.by,”) =COALESCE (forfatterskopi.by,”)
og COALESCE (forfattere.stat,”) =COALESCE (authorsCopy.stat,”)
og COALESCE (forfattere.lynlås,”) =KOALESCE (forfatterskopi.”)
og forfattere.kontrakt =forfatterskopi.kontrakt
hvor authorsCopy.au_ID er NULL
|
som du kan se, er der vanskeligheder med null kolonner med denne tilgang, men det er så hurtigt som de andre, og det giver dig lidt mere alsidighed til dine sammenligninger.
lokalisering af forskellene mellem tabeller
du har muligvis brug for en hurtig måde at se, hvilken kolonne og række der er ændret. En meget genial måde at gøre dette på blev offentliggjort for nylig. Det brugte KML. ‘Sammenlign tabeller og rapporter forskellene ved at bruge Pivot dataene’ (redaktørens note: link forældet). Det er smart, men for langsomt. Det samme kan gøres udelukkende i SF. Grundlæggende udfører du en kolonne for kolonne sammenligning af data baseret på den primære nøgle ved hjælp af et nøgle/værdipar. Hvis du gør hele bordet på en gang, er det ret langsomt: det bedste trick er at gøre dette kun på de rækker, hvor du ved, at der er forskel.
|
1
2
3
4
5
6
7
8
10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
63
64
|
angivelse @temp table(au_id varchar(11) primær nøgle) /*dette indeholder de primære nøgler til rækker, der er ændret * /
indsæt Til @Temp(au_ID) – Bestem hvilke rækker der er ændret
vælg au_ID
fra-brug undtagen teknik, som er den hurtigste i vores test
(
vælg au_id, au_lname, au_fname, telefon , by, stat, lynlås,
fra forfattere
undtagen
vælg AU_ID, au_lname, au_fname, telefon, Adresse, By, stat, lynlås, kontrakt
fra authorscopy
)f-nu vælger vi bare de kolonner,der er ændret
vælg lefthand.au_id, lefthand.name, lefthand.værdi som original, højre hånd.værdi som ændret
fra (- nu lægger vi bare de to tabeller ud som nøgleværdipar ved hjælp af strengversionerne af dataene
vælg forfattere.au_id, ‘au_lname’ som ‘name’, au_lname som ‘value’
fra forfattere indre JOIN @Temp altered on altered.au_id=authors.au_id
UNION
SELECT authors.au_id, ‘au_fname’ som ‘navn’, au_fname som ‘værdi’
fra forfattere indre join @temp ændret på ændret.au_id=forfattere.AU_ID
Union
vælg forfattere.au_id, ‘telefon’, telefon
fra forfattere indre join @temp ændret på ændret.au_id=forfattere.au_id
UNION
vælg forfattere.au_id, ‘adresse’,adresse
fra forfattere indre JOIN @Temp ændret på ændret.au_id=forfattere.au_id
UNION
vælg forfattere.au_id, ‘by’ som ‘navn’,by som ‘værdi’
fra forfattere indre JOIN @Temp ændret på altered.au_id=authors.au_id
Union
vælg authors.au_id, ‘State’,State
fra authors Inner Join @temp altered on altered.au_id=authors.au_id
Union
vælg authors.Inner JOIN @Temp altered on altered.au_id=authors.au_id
UNION
vælg authors.au_id, ‘contract’,CONVERT(CHAR(1), contract)
fra authors INNER JOIN @Temp altered on altered.au_id=authors.au_id) LeftHand
INNER JOIN (
vælg authorscopy.au_id, ‘au_lname’som ‘name’, au_lname som ‘Value’
fra authorscopy Inner join @temp altered on altered.AU_ID=authorscopy.au_id
Union
vælg authorscopy.au_id, ‘au_fname’,au_fname
fra authorsCopy INNER JOIN @Temp altered on altered.au_id=authorsCopy.au_id
UNION
vælg authorsCopy.au_id, ‘phone’,phone
fra authorsCopy INNER JOIN @Temp altered on altered.au_id=authorsCopy.au_id
UNION
vælg authorscopy.au_id, ‘adresse’,adresse
fra Authorscopy Inner join @temp altered on altered.au_id=authorscopy.au_id
Union
vælg authorscopy.au_id, ‘by’ som ‘navn’,by som ‘værdi’
fra forfattercopy INNER JOIN @Temp altered on altered.au_id=authorsCopy.au_id
UNION
vælg authorsCopy.au_id, ‘State’,state
fra authorsCopy INNER JOIN @Temp altered on altered.au_id=authorsCopy.au_id
UNION
vælg authorscopy.au_id, ‘lynlås’,lynlås
fra Authorscopy Inner join @temp altered on altered.au_id=authorscopy.au_id
Union
vælg authorscopy.au_id, ‘kontrakt’, konverter(CHAR (1),Kontrakt)
fra authorsCopy INNER JOIN @Temp altered on altered. au_id=authorsCopy. au_id) rightHand
på lefthand.au_ID=righthand.au_ID
og lefthand.name=righthand.name
hvor lefthand.værdi<>højre hånd.værdi
|
i vores eksempel ville dette give:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
au_id navn original ændret
———– ——– —————————- ————————————
041-76-1076 adresse 29 Second Avenue 9 Second Avenue
187-42-2491 adresse 279 Haag måde 79 Haag måde
220-43-7067 adresse 269 East Haag Street 69 East Haag Street
505-28-2848 adresse 73 Green Milton Drive 3 Green Milton Drive
697-84-0401 adresse 441 East Oak Parkvej 41 East Oak Parkvej
727-35-9948 adresse 280 Nobel Avenue 80 Nobel Avenue
875-54-8676 adresse 763 hvid Fabien måde 63 hvid Fabien måde
884-64-5876 adresse 45 hvid Nobel Boulevard 5 Hvid Nobel Boulevard
886-75-9197 adresse 35 øst anden Boulevard 5 øst anden Boulevard
975-80-3567 adresse 17 ny Boulevard 7 Ny Boulevard
|
denne teknik roterer rækkerne i tabellerne, der har forskelle i en Entity-attribut-value (EAV) tabel, så forskelle inden for en række kan sammenlignes og vises. Det gør denne rotation af UNIONing navnet og strengværdien af hver kolonne. Denne teknik fungerer bedst, hvor der ikke er et stort antal forskelle.
konklusioner
der er ingen enkelt ideel metode til sammenligning af dataene i tabeller eller resultater. En af en række teknikker vil være den mest relevante for en bestemt opgave. Det er helt ned til netop de svar, du har brug for, og typen af opgave. Har du brug for en hurtig kontrol af, at en tabel ikke er ændret, eller har du brug for at vide nøjagtigt, hvad ændringerne er? Vi er naturligvis hurtige til at udføre denne opgave, og sammenligninger af tabeller og resultater er en velkendt opgave for mange databaseudviklere.
hvis der er en generel regel, vil jeg sige, at udforskende eller ad hoc-arbejde har brug for et værktøj som f.eks.