Gennestreg udtræk fra tabel der også er i en anden tabel

<ole>

De poster/værdier, som findes begge steder, kan du skrive mellem DEL tags:


Så bliver de gennemstreget

/mvh
</bole>

Det vidste jeg godt :0). mit spørgsmål kan vidst også misforstås men jeg ville gerne vide hvordan kan jeg sammenligne de 2 tabeller og i listen fra den ene give dubletterne <del>-tagget.

Jeg har søgt lidt på google. men jeg har kun fundet metoder der udskriver dubletterne eller udskriver dem der ikke er dubletter. ikke noget om hvordan man udskriver hele lister og gør noget specielt ved dubletterne.

Klaphattens, fortæl mig lige hvilke ansigtstræk min søster og jeg har tilfælles.

Hvad mangler du for at kunne besvare det spørgsmål?  *o)

Hvis det er SQL du leder efter, så prøv: select *, exists(select * from tabel2 where tabel2.kolonne2 = tabel1.kolonne1) AS dublet FROM tabel1

Så får du et ekstra felt "dublet" i tabel1, som er true hvis rækken findes i tabel2

Et billede af jer to ;o)

Men hvis du leder efter et et billede af mine tabeller. så har jeg lavet 2 tabeller. test1 og test2. de er bare til øvelser.

Alle rækker i 'test1' skal udskrives. men rækker hvor 'test1' kolonne 'id' der er ens med 'test2' kolonne 'id1', skal markeres med del-tagget.

var det, det svar du søgte :o)

#5: Tak  *o)

Så kunne du f.eks. bruge:

Ole: Den uskriver ikke alle rækker fra tabel1, kun fællesmængden af tabel1 og tabel2. Min forespørgsel tager alle fra tabel1, og markerer for hver række, om rækken findes i tabel2.

#7: Jeg havde ikke set, at alle rækker fra tabel1 skulle vises  =)

I virkeligheden burde man nok join'e innodb tabeller på en foreign key, men erfaringsmæssigt kan det meget hurtigt blive en kamp bare at forklare (og få forstået), hvordan nøglen oprettes  *o)

Kun hvis kolonnen i tabel2 er unik, kan det samme resultat opnås med en left join, ellers risikerer du at få nogle rækker fra tabel1 flere gange. Er der noget galt i bare at selecte en ekstra exists-kommando, som jeg foreslog? Hvis forespørgslen er langsom kan du bare lave et indeks på kolonnen i tabel2 (ikke nødvendigvis et unikt). Det er da til at forstå.

Fedt fedt fedt, det skal der leges lidt mere med. smid et svar qobra.

Ole du må gerne forsøge eller henvise et sted der evt forklare det bedst muligt, så vil jeg se om jeg kan forstå det. :o)

God fornøjelse :)

#9: Klart, at det skal være unikt. Der er ikke noget galt med din løsning - og der er heller ikke noget galt i at sætte et 'lokalt' indeks på den anden tabel. Det er de færreste udviklere, som laver ikke-indekserede kald  =)

På den anden side set er der vel heller ikke noget galt ved at gå skridtet videre og øge performance yderligere. Joins og foreign keys er en yderst fremgangsmåde i professionelle sammenhæng - netop p.gr.a. den voldsomme perfomance forbedring, det somregel medfører.

#10: Havde jeg sådan et link, ville det ikke være så svært at forklare. Et af problemerne er også, at de(t) mest udbredte databaseadministrationsprogrammer (langt ord!) for PHP/MySQL ikke er særlig velegnet til at håndtere foreign keys.

Bedste bud: Søg på Google  =)

Tvivler nu på at en fremmednøgle vil gøre nogen forskel på performance. Så vidt jeg ved kan du kun lave en fremmednøgle, hvis du refererer til en primærnøgle. I så fald er det primærnøglen, der giver performance. Performance på et almindeligt indeks er ikke forskellig fra performance på et primært indeks, så resultatet vil være det samme. Om en join vil være hurtigere ved jeg ikke, det kommer an på hvordan databasen tolker forespørgslen.

Og da tabel1 tydeligvis indeholder data, som ikke har relationer til tabel2, vil det ikke være muligt at oprette en fremmednøgle.

- og da ingen af os ved, hvad der skal testes på, og hvad opgaven helt specifikt går ud på, kan der gættes i det uendelige  =)