SQL: Ikke joine, men bare legge sammen (UNION)

[834HF42F242]

Veldig vanskelig å forklare dette, og jeg har søkt meg lei på nettet etter svar. Hehe

 

Skal legge sammen tabeller, men ikke joine på kritereir. Skal rett og slett legge sammen to forskjellige tabeller til en stor virtuell, som deretter skal sorteres etter gitt kriterie.

 

Forsøker å forklare "grafisk":

 

 

 

tabellArtist:

--------------------------------------

| Artist_ID | Article_Text | Photo |

--------------------------------------

| 1 | Bla bla | bilde01.png |

--------------------------------------

| 2 | Bla bla | bilde02.png |

--------------------------------------

 

tabellNews:

--------------------------------------------------------------

| News_ID | Article_Text | Photo | Inner_Photo |

--------------------------------------------------------------

| 1 | Bla bla | bilde03.png | bildeF03.png |

--------------------------------------------------------------

| 2 | Bla bla | bilde04.png | bildeF04.png |

--------------------------------------------------------------

 

Slå sammen til:

 

tabellNy:

--------------------------------------------------------------

| Ny_ID | Old_ID | Article_Text | Photo | Inner_Photo |

--------------------------------------------------------------

| 1 | 1 | Bla bla | bilde01.png | NULL |

--------------------------------------------------------------

| 2 | 2 | Bla bla | bilde02.png | NULL |

--------------------------------------------------------------

| 3 | 1 | Bla bla | bilde03.png | bildeF03.png |

--------------------------------------------------------------

| 4 | 2 | Bla bla | bilde04.png | bildeF04.png |

--------------------------------------------------------------

Endret 18. september 2007 av neitakk

[Ekko]

Du kan ikke ha en tabell (ikke virituell) som du select into fra de to andre tabellene (i 2 operasjoner), deretter en select fra tabellen før en delete på hele tabellen.

 

Vet at dette er 4 operasjoner istedenfor en, men om du ikke har voldsomm ytelseskrav så kan vel det løse problemet.

[834HF42F242]

Hvis jeg bruker UNION, har du noen idé om hvordan jeg kan beholde ID-ene? ID-ene er vesentlige for å få laget URL til artikkelen.

[roac]

Hvis jeg bruker UNION, har du noen idé om hvordan jeg kan beholde ID-ene? ID-ene er vesentlige for å få laget URL til artikkelen.

9518994[/snapback]

Hvorfor skal du lage en ny ID som (for meg i hvert fall) ikke gir noen mening?

 

SELECT
 News_ID, null AS Artist_Id, Article_Text, Photo, Inner_Photo
 FROM tabell_News
UNION ALL
SELECT
 0 AS News_Id, Artist_Id, Article_Text, Photo, null AS Inner_Photo
 FROM tabell_Artist

 

Forøvrig vil jeg anbefale deg å se litt på navngivning. Best practice er å navngi tabeller med flertall (evt et ord som tydelig er en samling av noe), samt at det ikke er noen videre grunn til å prefikse tabellen med tabell. Om en spørring går mot en tabell eller et view bør i utgangspunktet ikke være vesentlig. (Annet enn at det kan påvirke ytelsen både positivt og negativt).

Endret 18. september 2007 av roac

[834HF42F242]

Navnene er bare eksempler for denne tråden

 

Trodde oppføringene fikk ny virtuell ID etter rekkefølge? Eller kan to oppføringer ha samme ID?

 

tabellNy:

--------------------------------------------------------------

| ID | Article_Text | Photo | Inner_Photo |

--------------------------------------------------------------

| 1 | Bla bla | bilde01.png | NULL |

--------------------------------------------------------------

| 2 | Bla bla | bilde02.png | NULL |

--------------------------------------------------------------

| 1 | Bla bla | bilde03.png | bildeF03.png |

--------------------------------------------------------------

| 2 | Bla bla | bilde04.png | bildeF04.png |

--------------------------------------------------------------

 

Spørringen skal gå slik at jeg får sortert oppføringene på dato i en loop uavhengig hvilken tabell oppføringen kommer fra...

 

Slik:

 

1: Spørring mot flere tabeller

2: Åpner recordset med serverscript

3: Starter loop fra første helt til siste dato er oppnådd

4: Setter verdier til variabler

5: Jeg skriver HTML med serverscript

6: Avslutter loopen

Endret 18. september 2007 av neitakk

[roac]

Slik:

 

1: Spørring mot flere tabeller

2: Åpner recordset med serverscript

3: Starter loop fra første helt til siste dato er oppnådd

4: Setter verdier til variabler

5: Jeg skriver HTML med serverscript

6: Avslutter loopen

9520006[/snapback]

For det første, det er ingen ting i veien for samme id. Og for det andre (jeg regner med at det ikke er en million rader du skal hente ut):

 

1: Spørring mot flere tabeller

2: Henter hele recordset med serverscript

3: Starter loop fra første helt til siste dato er oppnådd

4: Setter verdier til variabler

5: Jeg skriver HTML med serverscript

6: Avslutter loopen

 

Og så, hvis det er mellom bestemte datoer: En aldri så liten where-clause (eller rettere sagt to) er på sin plass, for å begrense hva du får ut fra databasen

[834HF42F242]

Får ikke helt forklart hva jeg mener, og er usikker på om jeg har gjort meg forstått... Hehehe.

Men endringen på punkt to der var interessant.

 

Du spør mot en, spør mot neste, og åpner så et recordset? Slik jeg gjør det nå så må jeg lukke recordsettet før jeg åpner neste for neste spørring. Jeg trodde at hvis man skal få alt inn i et recordset til en loop, så måtte man ta en UNION eller JOIN for å gjøre det fra flere tabeller.

 

edit: Begrenser lastingen ved å sette en FOR loop basert på antall records man får ut. Fordeler det på sidetall.

Endret 18. september 2007 av neitakk

[blackbrrd]

Noe slikt som dette burde fungere:

SELECT * FROM ( SELECT a,b,c,d FROM table_a WHERE date between x and y
UNION
SELECT a,b,c,d FROM table_b WHERE date between x and y
) as foo
ORDER BY foo.a

 

Ser ikke helt poenget med id-en som går 1-2-3-4

 

Hele problemstillingen høres forresten ut som om den har opphav i

a) dårlig design

b) legacy system + nytt system

c) to forskjellige systemer som er koblet sammen

Endret 18. september 2007 av blackbrrd

[834HF42F242]

Verken A, B eller C stemmer. Har bygget opp alt selv, men er veldig dårlig på å forklare meg.

 

Jeg har bygget tre systemer som jeg slår sammen på forsiden. Det er album, artister og artikler. De album og artister som inneholder biografi/anmeldelse viser jeg på forsiden sammen med artikler.

 

Slik ser det ut

 

Som du sikkert skjønner, vil jeg oppnå å ikke ha kategoriske ting i slotter, men flytende. Dvs. at øverste oppslag både skal kunne være album, artist og artikkel.

 

Tenkt litt videre på å ha en helt egen tabelle for alle artikler, og heller knytte artikler opp mot nyhetskategoriene, album og artister mot ID. Men veldig surt å bygge om både database og koder etter 5 måneders arbeid.

[blackbrrd]

Vel, du nevnte bare to tabeller, så jeg regnet med at det var to systemer. Nå høres det ut som du har tre systemer

 

Spørsmålet er om det lønner seg for deg å bygge om eller ikke, kommer an på hvor mye videreutvikling du har tenkt å foreta deg. En god datamodell lønner seg i det lange løp, ettersom den vil forminske mengden spesialbehandling du trenger å gjøre i kode. Samtidig kan det være mye arbeid å gjøre om fra et system til et annet.

 

Fikk du ut det du trengte med query forslaget mitt?

[roac]

Noe slikt som dette burde fungere:

SELECT * FROM ( SELECT a,b,c,d FROM table_a WHERE date between x and y
UNION
SELECT a,b,c,d FROM table_b WHERE date between x and y
) as foo
ORDER BY foo.a

9521078[/snapback]

Bytt ut UNION med UNION ALL er du snill Ellers er jeg enig.

[Manfred]

Du sier det ikke er dårlig design, men hvis det er så vanskelig å jobbe med i ettertid så er det nok det, uansett hva du måtte mene selv. Hvorfor kunne ikke de tre tingene ligge i en tabell, og bare ha f.eks et bit/boolsk felt som indikerte hva det var, eller en fk id linket til en annen tabell eller noe.

 

Når feltene er så like i flere tabeller, kan dette tyde på dårlig databasedesign.

[834HF42F242]

Feltene er ikke så like. Jeg har ikke postet tabellene slik de egentlig er. Album, artister og artikler er så forskjellige oppføringer at det kreves 3 tabeller. Derimot vurderer jeg å legge selve anmeldelsen fra album og biografien fra artister inn i artikler-tabellen, siden struktur på alle artikler er så og si lik.