Archief - MYSQL: Query probleem

Lo,

Tja, kgeraak er echt niet uit.

Ik heb 2 tabellen nodig hier

de tabel link en de tabel nummer.

De tabel link bevat telkens 2 id's van nummers

tabel LINK

Veld Type
id int(11)
id_src int(11) <-- een id van een nummer
id_doel int(11) <-- een id van een nummer
----------------------------------------
daarnaast is er nog die tabel met nummer, met de naam, id ...

tabel LINK

Veld Type
id int(11) Ja
naam_nummer varchar(255)
...
----------------------------------------

Nu kijk ik telkens of een bepaalde waarde in id_src of id_doel zit en haal dan de andere waarde eruit (id_doel of id_src).

Nu wil ik een query opbouwen waarin: als id_src het $id is, haal ik id_doel op, dan ga ik kijken of id_doel niet nog ergens anders in de tabel aanwezig is in id_src of id_doel en wil dan weer de andere waarde eruit halen.

Zo bekom ik links tot in de 2 familie

a link b
b link c
en dan wil ik die a link c bekomen.

Hoe begin ik daar best aan, aan het laatste wel te verstaan.

Mvg, Wolf

Waar combinaties de eerste tabel is die je hierboven beschrijft & links de tweede.
Ik denk dat dit het gewenste resultaat zou moeten geven & anders heb k uw uitleg niet goed verstaan

K thx, ik zal het straks eens uittesten

En waar moet dat precies voor dienen? Want aan je uitleg schort - denk ik - iets.

Stel :
a link b
b link c
d link b

En je wil alles van a opzoeken.

Aangezien je zegt dat je gaat kijken of die id_doel nog ergens anders in de tabel aanwezig is als doel of src, zit je - puur op gevoel - met een potentieel probleem, want dan krijg je de 2 andere records terug (c en d).

mja, dat is net waar ik mee zit.

Die tabel nummer = liedjes

Ik heb gewoon al mijn nummers in db staan en wil dan links trekken om gelijkaardige nummers te kunnen sorteren.

Bv, ik sta te draaien en heb op een moeilijk mixbaar nummer (a) (erg traag ofzo) een goed nummer gevonden. Als ik op dat goed nummer (b) al een ander nummer gelinkt had (c), heb ik meteen bij het moeilijk mixbaar nummer (a) ook met c gelinkt.

Het is als een soort probeersel om goede combo's te vinden die niet voor de hand liggen.

EDIT: Als jullie een andere manier hebben door bv men db layout aan te passen, zeg het dan maar.

En die id_src en id_doel had ik evengoed 1 en 2 kunnen noemen, de functie van beide is namelijk hetzelfde -> als ik doel heb, wil ik src, en als ik src heb wil ik doel en dan weer zo verder.

een tussentabel gaan gebruiken ... dit lijk mij in dit opzicht het makkelijkste.

eerste kolom is id 1 tweede kolom is id 2

id 1 kan meerdere keren voorkomen, dus bv song a is mixbaar met song b & c dan krijg je als volgt:

A B
A C
B A
B C

Waar je dan een foreign key van maakt van de 2de kolom, en er zo voor zorgt dat de combinatie van beide waarden uniek is...

Naar wat ik er hiervan interpreteer is een tussentabel de beste oplossing...
whispy/djeez/radiance... correct me If I'm wrong

Bof, dit is dus een perfect voorbeeld van het depth-first-search algoritme (iet uit grafenleer dus). Probleem is dat dat dingske looping vereist en mysql da nie goe genoeg ondersteund .

Ge hebt enkele oplossingen:
-Een tergend traag mysql-algoritme (vooral als ge het wilt veralgemenen, als je enkel maar a->b->c en niet nog verder wilt komt ge er denk ik ongeveer met radiance zen algoritme, wat nog goed meevalt qua snelheid).
-Alles ophalen en een relatief snel php-algoritme gebruiken
-Zoals orez zegt een tussentabel gebruiken waar er dus dubbel gelinkt wordt tussen waarden id1 en id2 (id1 is zowel eens 'start' id als 'eind' id, net zoals id2)
-uw gelinkte nummers in 1 record opslaan en bv. id_src = INT en dan ids_target = "9,8,2,3" en string functies op toepassen. Dan met string functies een algoritme bouwen. Just bedacht, dus kweet zelfs niet of het zou lukken en zelfs al lukt het zal het weerom vreselijk traag zijn, zelfs pak erger als in oplossing 1.
-... (kan nie onmiddelijk op nog andere komen)

Hey erg bedankt allemaal voor de goede reply's!!
Ik denk dat ik met deze oplossingen aan de slag kan en zal weten te zeggen of het lukt!

Net even met orez besproken ook, zijn oplossing werkt maar zorg wel voor een exponentieel groeiende database, op kleine schaal geen probleem, maar als ge zo 10 gerelateerde platen hebt ... da's 2^10 records ...da's veel
killgore's string oplossing is in theorie goed, maar praktisch zeer moeilijk te realiseren denk ik & idd traag.

Andere mogelijk oplossing is werken met een groepering van nummers, ipv ze direct aan mekaar te koppelen.
dus je hebt :
tabel nummers
numID
numNaam

tabel groepen
groepID
groepNaam

koppeltabel groep nummer
groepID
numID

Lijkt mij niet echt gigantische nadelen te hebben, maar misschien kijk ik er over.

Het gaat hier over ongeveer 5.000 nummers
Dus euhm

|M°B|Morbuus zei:

Het gaat hier over ongeveer 5.000 nummers
Dus euhm

Klik om te vergroten...

(kga hier effe php gebruiken, moeste in c++ of zo werken, ist zelfde he ):

Dan zou ik het linken anders doen en meer via php:
ge maakt in php een array met alle linkid's, serializet die en plaatst die terug in de tabel. (maak nog altijd aparte tabel voor links, anders gaat werken met links nog trager gaan).

nadelen hier aan:
bij elke update moet je eerst de huidige array ophalen, unserializen, aanpassen, en dan weer invoegen in db (dus minstens 2 queries ipv 1 update of insert).
Je kan niet meer direct via mysql links gaan ophalen, je moet eerst een nummer selecten dan via PHP weer de juiste query opstellen -> weer 2 queries ipv 1.

voordelen:
-Je kan een php-algoritme gebruiken voor jouw oorspronkelijk probleem. Dit zal sneller zijn omdat je met looping & arrays kan werken en je niet op een zoek-patroon moet baseren.
-Je hebt veel kleinere db-groei

Die nadelen zijn relatief: je gaat maar een klein beetje zoek-snelheid verliezen doordat direct linking wegvalt, het grootste nadeel zit hem in het feit dat je gewoon 2x met db moet verbinden, wat zowat dé bottleneck is in db-driven programmas/scripts.
Ook zal je bij een immense link-tabel merken dat dit sneller gaat dan pure mysql-oplossing, simpelweg omdat het zoeken in de mysql-tabellen dan wegens de grootte gewoon extreem traag gaat.


edit: radiance zen groep systeem zal idd beter werken. Tenminste als je ervan uit gaat dat als a gelinkt is met b en b met c dat a ook auto gelinkt is met c (transitiviteit om wiskundige term te gebruike ). Ma da lijkt wel zo uit originele post.

orez zei:

Naar wat ik er hiervan interpreteer is een tussentabel de beste oplossing...

Klik om te vergroten...

Zijn link tabel is nu net een tussentabel die 2 records uit zijn nummer tabel aan elkaar linkt. De id_src en id_doel uit de link tabel verwijzen dus elk naar een id in zijn nummer tabel. Dat is althans toch mijn interpretatie adhv zijn verduidelijking.

dJeez zei:

Zijn link tabel is nu net een tussentabel die 2 records uit zijn nummer tabel aan elkaar linkt. De id_src en id_doel uit de link tabel verwijzen dus elk naar een id in zijn nummer tabel. Dat is althans toch mijn interpretatie adhv zijn verduidelijking.

Klik om te vergroten...

Daar heb je het volledig juist.

Ik begin wel lichtjes de weg kwijt te raken in al deze verklaringen omdat ik nog niet zo skilled ben dus ik ga even wat googelen op jullie reply's en wat op het irc channel vragen. Daarna post ik wel opnieuw.

maakt het het allemaal niet handiger als ik die 2 id's die naar de tabel nummer zijn gelinkt in 1 veld steek met dan een , ertussen.

Ik laad elk veld in een array en ga dan met php kijken wat er in elke array zit en doe dan steeds een query, of is dat pas traag?

dat is redelijk dom om doen ja ... je verliest enorm veel dynamiek op deze manier

orez zei:

dat is redelijk dom om doen ja ... je verliest enorm veel dynamiek op deze manier

Klik om te vergroten...

dynamiek niet, gewoon switchen tussen talen is geen verlies van dynamiek ..., ma ge verliest vooral snelheid door meerdere queries.

Zoals gezegd -> radiance zen systeem (van extra "groepen" tabel) is beter .