[mysql] query (left join) probleem

[HenkS]

hallo ik heb het volgende probleem:

ik heb de volgende 3 tabellen:

auto:
a_id (autoid dus)
merk
type
enz..

auto_opties: (hierin staan de opties die een auto kan hebben, zoals airco, bovag, leer...)
id
naam

auto_opties_koppel (koppel tabel)
id
a_id (auto ids)
o_id (optie ids)


nu wil ik als je bij het zoeken opties selecteerd, je de auto's terug krijgt die die opties hebben, dus als je optie 1 en 2 hebt, dat je de auto terug krijgt die optie 1 en 2 heeft, maar selecteerd je optie 1,2 en 3 dat je een auto die alleen 1 en 2 heeft, niet terug krijgt, nu heb ik de volgende query daarvoor:

select * from auto
left join auto_opties_koppel on auto_opties_koppel.a_id = auto.a_id
where auto_opties_koppel.o_id=1

dit werkt goed!!! maar dit is maar voor 1 optie
dus wil ik het natuurlijk uitbreiden

dus doe ik daarna:
and auto_opties_koppel.o_id=2

nu krijg ik niks terug, terwijl in die koppel tabel de velden:

a_id, o_id

2, 1
2, 2

voorkomen, dus zou ik auto 2 moeten terug krijgen

maar dus niet, wat doe ik fout?

[Verwijderd]

Probeer dit anders eens, ben er alleen niet zeker van of het werkt, heb namelijk effe niets bij de hand om het te testen...

code:

select * from auto
left join auto_opties_koppel on auto_opties_koppel.a_id = auto.a_id
group by auto_opties_koppel.a_id
  having auto_opties_koppel.o_id=1 and auto_opties_koppel.o_id=2

[Janoz]

Met OR werkt het niet, want dan krijg je niet de auto's terug die aan alle opties voldoen, maar aan minimaal 1 van de opties.. Dit probleem lijkt trouwens heel erg op [topic=386232].

[Goodielover]

And optie=2 zal nooit werken. Er kan nooit een record in de koppeltabel staan met zowel optie_id =1 als ook optie_id=2. (Je hebt maar 1 veld!)

De oplossing is met een group by te werken.

code:

select a.*
from   auto a
    ,koppeltabel k
where  k.auto_id = a.auto_id
and    k.optie_id in (1,2,3)
group by a.auto_id
having count(k.optie_id) = 3

De tabelnamen kloppen niet (waarschijnlijk) maar ik neem aan dat je er nu wel uitkomt.

edit:

Het IN gedeelte bouw je dus dynamisch op (in een parameter) evenals het getal na de count(k.optie_id)
De oplossing van Frinkel zal niet werken.

[HenkS]

Op maandag 21 januari 2002 11:29 schreef FRiNKEL het volgende:
Probeer dit anders eens, ben er alleen niet zeker van of het werkt, heb namelijk effe niets bij de hand om het te testen...

code:

select * from auto
left join auto_opties_koppel on auto_opties_koppel.a_id = auto.a_id
group by auto_opties_koppel.aid
  having auto_opties_koppel.o_id=1 AND auto_opties_koppel.o_id=2

nee werkt niet, krijg zelfs niks terug als ik de AND constructie weghaal, dan ook niks, haal ik het hele having gedeelte weg, doet ie het wel, maar ja dan krijg ik teveel terug natuurlijk...

[Verwijderd]

Laatmaar, stond weer s onzin...

[dusty]

Op maandag 21 januari 2002 11:26 schreef HenkS het volgende:
auto_opties_koppel (koppel tabel)
id
a_id (auto ids)
o_id (optie ids)

En het nut van dat ID?

[Verwijderd]

Op maandag 21 januari 2002 11:40 schreef dusty het volgende:

[..]

En het nut van dat ID?

Klopt wat Dusty schrijft, je kunt net zo goed de primary key op a_id en o_id samen leggen... dan heb je die ID niet meer nodig...

[HenkS]

Op maandag 21 januari 2002 11:40 schreef dusty het volgende:

[..]

En het nut van dat ID?

ehmm het nut van dat ID = dat ik nu leer dat het onzinnig is, omdat de combinatie van die andere 2 al uniek moet zijn

[HenkS]

Op maandag 21 januari 2002 11:37 schreef Goodielover het volgende:
And optie=2 zal nooit werken. Er kan nooit een record in de koppeltabel staan met zowel optie_id =1 als ook optie_id=2. (Je hebt maar 1 veld!)

De oplossing is met een group by te werken.

code:

select a.*
from   auto a
    ,koppeltabel k
where  k.auto_id = a.auto_id
and    k.optie_id in (1,2,3)
group by a.auto_id
having count(k.optie_id) = 3

De tabelnamen kloppen niet (waarschijnlijk) maar ik neem aan dat je er nu wel uitkomt.

edit:

Het IN gedeelte bouw je dus dynamisch op (in een parameter) evenals het getal na de count(k.optie_id)
De oplossing van Frinkel zal niet werken.

ik heb er dus ff mijn eigen query van gemaakt (velden aangepast:

select a.*
from auto a
,auto_opties_koppel k
where k.a_id = a.a_id
and k.o_id in (1,2)
group by a.a_id
having count(k.o_id) = 2

en dit werkt dus perfect, alleen snap ik het laatste gedeelte niet, waarom is dit nodig?

[dusty]

Op maandag 21 januari 2002 11:33 schreef Janoz het volgende:
Met OR werkt het niet, want dan krijg je niet de auto's terug die aan alle opties voldoen, maar aan minimaal 1 van de opties.. Dit probleem lijkt trouwens heel erg op [topic=386232].

En stiekum is de oplossing MET een or statement, maar dan moet je dus gaan tellen HOEVEEL ervan aan de voorwaarde voldoen dus ook nog een count erbij.

[Janoz]

Op maandag 21 januari 2002 11:47 schreef dusty het volgende:

[..]

En stiekum is de oplossing MET een or statement, maar dan moet je dus gaan tellen HOEVEEL ervan aan de voorwaarde voldoen dus ook nog een count erbij.

Ik doelde op de post boven mij , en als je de link gevolgd had, dan had je gezien dat ik in dat andere topic (Wat over eenzelfde soort probleem gaat) ook al de tel oplossing gegeven had. Het verschil met dit topic is echter dat hier in de koppeltabel gegarandeerd unieke waarden waren, en dat dit bij dat andere probleem niet zo was..

[Goodielover]

Op maandag 21 januari 2002 11:45 schreef HenkS het volgende:

[..]

group by a.a_id
having count(k.o_id) = 2

en dit werkt dus perfect, alleen snap ik het laatste gedeelte niet, waarom is dit nodig?

Ik neem aan dat je dit laatste gedeelte bedoelt.
Hier zeg je (group by a.a_id) dat je per auto het wilt weten.
Hier zeg je (having count(..) =3) dat het er precies drie moeten zijn.
Als je dit niet opneemt, krijg je elke auto 3 keer.

[dusty]

Op maandag 21 januari 2002 11:50 schreef Janoz het volgende:
[..]
Ik doelde op de post boven mij ,

Dat zegt men allemaal!

en als je de link gevolgd had, dan had je gezien dat ik in dat andere topic (Wat over eenzelfde soort probleem gaat) ook al de tel oplossing gegeven had.

Ik volg geen links voordat je het weet is het SPAM!

Het verschil met dit topic is echter dat hier in de koppeltabel gegarandeerd unieke waarden waren, en dat dit bij dat andere probleem niet zo was..

Hij heeft hier een ID geintroduceerd in het koppeltabel, waardoor ik dus wel degelijk twee keer een airco aan een auto kan toevoegen, wat dus veroorzaakt dat het dus NIET gegarandeerd unieke waarden zijn ( foutje in database model van um, dat krijg je als men ID's toevoegd die geen toegevoegde waarden hebben )

[Goodielover]

Op maandag 21 januari 2002 11:55 schreef dusty het volgende:

[..]

Dat zegt men allemaal!
[..]

Ik volg geen links voordat je het weet is het SPAM!
[..]

Hij heeft hier een ID geintroduceerd in het koppeltabel, waardoor ik dus wel degelijk twee keer een airco aan een auto kan toevoegen, wat dus veroorzaakt dat het dus NIET gegarandeerd unieke waarden zijn ( foutje in database model van um, dat krijg je als men ID's toevoegd die geen toegevoegde waarden hebben )

Kolder Dusty, dit ben ik niet van je gewend.
Het toevoegen van een ID zegt niets over wel of niet unieke waarde. Ik neem aan dat secondairy keys je ook wel wat zeggen. Het zou zelfs kunnen zijn dat als er bijvoorbeeld de prijs van de optie en de datum beschikbaar tot er wordt bijgehouden, dat het heel legitiem is daar een aparte ID voor bij te houden. Het maakt het updaten avn het record wel veel eenvoudiger en uniformer over de tabellen heen.

[HenkS]

ehmm ik heb een vraagje...

nu was er select auto.*

maar ik heb niet alle velden nodig

dus ik dacht doe:

select auto.a_id, auto.merk enz.... rest hetzelfde, maar nu gaat ie zeuren bij de 'having' dat ie a.brandstof niet kent, maar die zie ik nergens in de query staan... hoe kan dit, moet je in dit geval perse auto.* pakken?

edit:

zie post hieronder, dit was foutje

[HenkS]

ehmm foutje, dit was nu mijn query:

SELECT a.a_id, a.merk FROM auto a, auto_opties_koppel k WHERE k.a_id = a.a_id AND k.o_id in (1,2,5,6,7) GROUP BY a.a_id HAVING COUNT(k.o_id) = 5 AND a.merk = 'MG' AND a.brandstof = 'Benzine'

daarom ging het mis, maar als ik a.* doe, gaat het wel

ik dacht dat als je een veld in de 'where' meepakt, je dit toch niet in de select opvraag erbij hoeft te hebben?

[Goodielover]

Op maandag 21 januari 2002 12:05 schreef HenkS het volgende:
ehmm foutje, dit was nu mijn query:

SELECT a.a_id, a.merk FROM auto a, auto_opties_koppel k WHERE k.a_id = a.a_id AND k.o_id in (1,2,5,6,7) GROUP BY a.a_id HAVING COUNT(k.o_id) = 5 AND a.merk = 'MG' AND a.brandstof = 'Benzine'

daarom ging het mis, maar als ik a.* doe, gaat het wel

ik dacht dat als je een veld in de 'where' meepakt, je dit toch niet in de select opvraag erbij hoeft te hebben?

Je moet het niet opnemen in de having maar in de where clause. Je kan die auto's namelijk op vaarhand al uitsluiten. Dus:

code:

SELECT a.a_id
    ,a.merk
FROM   auto a
    ,auto_opties_koppel k
WHERE  k.a_id = a.a_id 
AND    k.o_id in (1,2,5,6,7)
AND    a.merk = 'MG'
AND    a.brandstof = 'Benzine' 
GROUP BY a.a_id
HAVING COUNT(k.o_id) = 5

Je moet alleen in de having opnemen, wat je alleen kan doen nadat de group by is geweest.

[HenkS]

thanks, ook wel logisch ja, perfector werkt mooi nu

[dusty]

Op maandag 21 januari 2002 11:59 schreef Goodielover het volgende:
Kolder Dusty, dit ben ik niet van je gewend.
Het toevoegen van een ID zegt niets over wel of niet unieke waarde. Ik neem aan dat secondairy keys je ook wel wat zeggen. Het zou zelfs kunnen zijn dat als er bijvoorbeeld de prijs van de optie en de datum beschikbaar tot er wordt bijgehouden, dat het heel legitiem is daar een aparte ID voor bij te houden. Het maakt het updaten avn het record wel veel eenvoudiger en uniformer over de tabellen heen.

Niets kolder, Als het een andere airbag is ga je niet de verschillende prijzen bij de koppeltabel opslaan, dan maak je verschillende airbags aan van de verschillende typen en prijzen, aangezien je dan ook de airbags krijgt die in een bepaalde auto wel passen en in anderen weer niet.

Zodra er gegevens erbij kunnen en je gaat de waarde in een andere tabel weer koppelen DAN kan je er een ID bij stoppen, echter in 99.9% van de gevallen heb je bij een koppeltabel GEEN ID nodig. (anders zou het ook geen koppeltabel meer zijn). Updaten van een record in een koppeltabel ? dat zou vreemd zijn, Dan verwijder je er meestal een en voeg je een andere toe. Dan ga je um niet updaten (althans niet bij de (auto - optie) mogelijkheid). Eenvoudiger ? Want je moet eerst de ID zoeken die bij de auto/optie hoort en dan met die ID gaan updaten? jah je hebt gelijk lijkt mij een stuk eenvoudiger dan meteen updaten aan de hand van de auto en optie.

Als je alles uniform wilt hebben kan je alles in EEN tabel gooien, is alles compleet uniform. (uber-normaliseren, zie ander topic in search)

De database gebruik je om alles zo optimaal mogelijk te laten verlopen, niet voor de uniformiteit.

[Janoz]

En zoals altijd is Dusty weer flink aan het vissen om iig op db-gebied altijd het laatste woord te hebben

[dusty]

Op maandag 21 januari 2002 12:41 schreef Janoz het volgende:
En zoals altijd is Dusty weer flink aan het vissen om iig op db-gebied altijd het laatste woord te hebben

Ik wil helemaal niet het laatste woord hebben

[HenkS]

lukt je ook niet

[dusty]

Op maandag 21 januari 2002 13:22 schreef HenkS het volgende:
lukt je ook niet

Dat wist ik al

[Goodielover]

In zo'n geval spreek je ook niet meer van een koppeltabel, maar een zelfstandige entiteit.
In het gavle van een update hoef je de ID niet op te zoeken, want die selecteer je gewoon direct mee.

edit:

(Lekker puh, dusty!
O ja, wie had ook alweer de oplossing gegeven, jij of ik?

[HenkS]

nou ik heb nu toch het id eruit gehaald, vond het niet nodig.....

thanks

[dusty]

Op maandag 21 januari 2002 13:25 schreef Goodielover het volgende:
[..]
O ja, wie had ook alweer de oplossing gegeven, jij of ik?

Ik geef zelden de oplossing, ik geef meestal alleen hints naar de oplossing. Laat ze maar zelf zoeken, leert men het meest van

[Janoz]

* Janoz snapt nu ook waarom Dusty lite-mod wil worden...

Dan kan ie zeker weten het laatste woord hebben

[dusty]

Op maandag 21 januari 2002 13:41 schreef HenkS het volgende:
nou ik heb nu toch het id eruit gehaald, vond het niet nodig.....

thanks

Goed zo! Je leert het nog wel

[HenkS]

mmmm had toch niet op Dusty moeten stemmen....

of ik maak een script waar ik de GOT pagina te zien krijg, behalve de laatste post, zet ik dan gewoon DUSTY neer

[dusty]

Op maandag 21 januari 2002 13:49 schreef Janoz het volgende:
* Janoz snapt nu ook waarom Dusty lite-mod wil worden...

Dan kan ie zeker weten het laatste woord hebben

Zou maar in 60% van alle thread zijn ofzo

[dusty]

Op maandag 21 januari 2002 13:50 schreef HenkS het volgende:
mmmm had toch niet op Dusty moeten stemmen....
[..]

Er komt nog altijd een tweede ronde kan je altijd alsnog niet op mij stemmen

[HenkS]

kan dit dus niet anders dmv left joins ofzo, want group by is nu niet echt bepaald snelheid bevorderend, zeker niet als de db straks groot is....

[dusty]

Op dinsdag 22 januari 2002 09:44 schreef HenkS het volgende:
kan dit dus niet anders dmv left joins ofzo, want group by is nu niet echt bepaald snelheid bevorderend, zeker niet als de db straks groot is....

Je gebruikt al left joins,

Als je goeie indexen zet ben je als het goed is af van het grootste gedeelte van je snelheids probleem. (althans voor grote queries)

[TheDane]

waarom doe je het niet zo:

vul voor je auto_optie_id's waardes van machten van 2 in

dus je krijgt dan een tabel met
optie_id | optie:
1 | stuur
2 | banden
4 | ruitewisser
8 | radio

als je auto (met ID 1 voor 't gemak even) dan meerdere opties heeft, (bijvoorbeeld stuur, ruitewisser, radio)

dan vul je in die auto_opties_koppel table 't volgende in:

auto_id | opties
1 | 13

heeft je auto alleen een stuur en banden, vul dan
1 | 3


sim-pel

[Janoz]

Op dinsdag 22 januari 2002 09:52 schreef TheDane het volgende:
waarom doe je het niet zo:

vul voor je auto_optie_id's waardes van machten van 2 in

dus je krijgt dan een tabel met
optie_id | optie:
1 | stuur
2 | banden
4 | ruitewisser
8 | radio

als je auto (met ID 1 voor 't gemak even) dan meerdere opties heeft, (bijvoorbeeld stuur, ruitewisser, radio)

dan vul je in die auto_opties_koppel table 't volgende in:

auto_id | opties
1 | 13

heeft je auto alleen een stuur en banden, vul dan
1 | 3


sim-pel

Dat voldoet niet aan de 1e normaal vorm.

[HenkS]

tjaaa wat moet ik hier nu van vinden....

en wat voor select statement doe ik dan? bv ik zoek alles met ruitenwissen en banden ???

[TheDane]

Op dinsdag 22 januari 2002 09:55 schreef Janoz het volgende:

[..]

Dat voldoet niet aan de 1e normaal vorm.

oh, ja, ik was vergeten dat dat ook een eis van HenkS was
(duh)

_{lees: wat dat dat er nou toe? 't is twintigduizend keer makkelijker te indexeren, query is korter, en efficienter}

normaliseren doesn't have to be the answer hoor

[TheDane]

Op dinsdag 22 januari 2002 09:55 schreef HenkS het volgende:
tjaaa wat moet ik hier nu van vinden....

en wat voor select statement doe ik dan? bv ik zoek alles met ruitenwissen en banden ???

uhh, weet even de preciese tables niet meer, maar auto_id should do it wel ff, ok?

select auto_id from auto_opties_koppeltabel where opties = (select sum(optie_id) from opties where optie in ('banden', 'ruitenwissen'));

zoiets ?

[dusty]

Op dinsdag 22 januari 2002 09:55 schreef TheDane het volgende:
[..]
oh, ja, ik was vergeten dat dat ook een eis van HenkS was
(duh)

Ook duidelijk niet begrepen waarvoor een database dient zie ik wel.

[TheDane]

Op dinsdag 22 januari 2002 09:59 schreef dusty het volgende:

[..]

Ook duidelijk niet begrepen waarvoor een database dient zie ik wel.

you may enlighten me

[HenkS]

Op dinsdag 22 januari 2002 09:57 schreef TheDane het volgende:

[..]

uhh, weet even de preciese tables niet meer, maar auto_id should do it wel ff, ok?

select auto_id from auto_opties_koppeltabel where opties = (select sum(optie_id) from opties where optie in ('banden', 'ruitenwissen'));

zoiets ?

ten eerste ga ik niet meer met jou naar feestjes, weet niet wat alcohol met je doet, maar als het zoiets oplevert...

en ten 2e, als je zo met in (opties) werkt, heb je meer een soort OR statement, dus als je dan zoekt naar bv banden, ruitenwissers en airco, dan krijg je volgens mij ook auto's met alleen banden en ruitenwissers .. terwijl je ook die met airco wilt hebben (als ik het ff goed zie)

maar hoe verzin je zoiets, maak je daarboven wel eens kortsluiting ofzo.????

(niet dat ik jouw oplossing ooit ga gebruiken, maar toch leuk om te lezen)

zit met die group by query trouwens nu op een snelheid van 0.00056..... gemiddeld.... maar ja de db is nog klein

[TheDane]

Op dinsdag 22 januari 2002 10:03 schreef HenkS het volgende:

[..]

ten eerste ga ik niet meer met jou naar feestjes, weet niet wat alcohol met je doet, maar als het zoiets oplevert...

en ten 2e, als je zo met in (opties) werkt, heb je meer een soort OR statement, dus als je dan zoekt naar bv banden, ruitenwissers en airco, dan krijg je volgens mij ook auto's met alleen banden en ruitenwissers .. terwijl je ook die met airco wilt hebben (als ik het ff goed zie)

maar hoe verzin je zoiets, maak je daarboven wel eens kortsluiting ofzo.????

(niet dat ik jouw oplossing ooit ga gebruiken, maar toch leuk om te lezen)

zit met die group by query trouwens nu op een snelheid van 0.00056..... gemiddeld.... maar ja de db is nog klein

1) feestje was gezellig
2) zou kunnen, heb er verder niet al te lang naar gekeken, hoofd doet nog pijn
3) dit idee heb ik van maarten .. wordt regelmatig gebruikt overigens, is een hele bekende techniek

tsja, en die snelheid: als je 1 record uit een tabel van 2 records moet selecteren

[HenkS]

Op dinsdag 22 januari 2002 10:06 schreef TheDane het volgende:

[..]

1) feestje was gezellig
2) zou kunnen, heb er verder niet al te lang naar gekeken, hoofd doet nog pijn
3) dit idee heb ik van maarten .. wordt regelmatig gebruikt overigens, is een hele bekende techniek

tsja, en die snelheid: als je 1 record uit een tabel van 2 records moet selecteren

snelheid is goed, alleen de vraag of het zo blijft bij grote db, want die koppeldb groeit natuurlijk enorm (iemand overigens advies qua indexen, dan weet ik of ik het goed heb gedaan)

ff over je punten:
2)zeg dan niks, of zeg het goed
1)ja was erg leuk, gezellig en ook nog eens lekkere wijven, was verdomme weer veel te geil...

[TheDane]

Op dinsdag 22 januari 2002 10:08 schreef HenkS het volgende:

[..]

snelheid is goed, alleen de vraag of het zo blijft bij grote db, want die koppeldb groeit natuurlijk enorm (iemand overigens advies qua indexen, dan weet ik of ik het goed heb gedaan)

ff over je punten:
2)zeg dan niks, of zeg het goed
1)ja was erg leuk, gezellig en ook nog eens lekkere wijven, was verdomme weer veel te geil...

2) *gaaap* , ik heb mn koffie nog niet eens op
1) jij bent altijd geil .. ik vraag me wel af waar ivo al die wijven van kent, sjit,. . doet ie goed!

[dusty]

Op dinsdag 22 januari 2002 10:01 schreef TheDane het volgende:
[..]
you may enlighten me

database != bitneuken.

[dusty]

Op dinsdag 22 januari 2002 10:03 schreef HenkS het volgende:
[..]
en ten 2e, als je zo met in (opties) werkt, heb je meer een soort OR statement, dus als je dan zoekt naar bv banden, ruitenwissers en airco, dan krijg je volgens mij ook auto's met alleen banden en ruitenwissers .. terwijl je ook die met airco wilt hebben (als ik het ff goed zie)

Nee, je zou alleen de auto's krijgen met de opties die je wilt. Echter is dit een methode die men nog in het begin van de jaren 80 gebruikte om opties e.d. op te slaan.

[TheDane]

Op dinsdag 22 januari 2002 10:10 schreef dusty het volgende:

[..]

database != bitneuken.

1 == 1

maar als je een dergelijke query moet brouwen om een imho brak datamodel te compenseren dan ben je ook niet goed bezig. _IK_ had 't iig anders gedaan, en wel such as above i think _{voor zover ik op dit moment kan denken}

[dusty]

Op dinsdag 22 januari 2002 10:14 schreef TheDane het volgende:
[..]
Maar als je een dergelijke query moet brouwen om een imho brak datamodel te compenseren dan ben je ook niet goed bezig. _IK_ had 't iig anders gedaan, en wel such as above i think _{voor zover ik op dit moment kan denken}

Brak datamodel?

Het enige wat brak was was zijn extra 'ID' in zijn koppeltabel. Als jij dit een brak datamodel vindt zou ik wel eens een correcte datamodel van jou willen zien.

De query compenseert niets, Is een goede, correct en snelle query. Datamodel is erg flexibel en makkelijk uit te bereiden.

[TheDane]

Op dinsdag 22 januari 2002 10:20 schreef dusty het volgende:

[..]

Brak datamodel?

Het enige wat brak was was zijn extra 'ID' in zijn koppeltabel. Als jij dit een brak datamodel vindt zou ik wel eens een correcte datamodel van jou willen zien.

De query compenseert niets, Is een goede, correct en snelle query. Datamodel is erg flexibel en makkelijk uit te bereiden.

't is een heel flexibel datamodel. absoluut! maar voor de toepassing die hij hanteert lijkt 't mij niet 't meest _handige_ datamodel.

ik wil de efficiency van voorgaande queries wel eens vergelijken bij een database van tien- tot honderdduizend auto's met ieder honderd++ opties ...

hmm, ik was even terug aan 't lezen en kwam dit tegen:

Op maandag 21 januari 2002 12:41 schreef Janoz het volgende:
En zoals altijd is Dusty weer flink aan het vissen om iig op db-gebied altijd het laatste woord te hebben

[dusty]

Op dinsdag 22 januari 2002 10:25 schreef TheDane het volgende:
[..]
ik wil de efficiency van voorgaande queries wel eens vergelijken bij een database van tien- tot honderdduizend auto's met ieder honderd++ opties ...
[..]

En met jouw systeem welke ID heeft de laatste optie?

Efficiency zal beter zijn dan dat jij denkt.

[TheDane]

Op dinsdag 22 januari 2002 10:37 schreef dusty het volgende:

[..]

En met jouw systeem welke ID heeft de laatste optie?

Efficiency zal beter zijn dan dat jij denkt.

die eerste zin niet ik snap

en wellicht heb je wel gelijk wat betreft die efficiency, heb ik wat dat betreft niet zo'n ervaring, vandaar mijn vorige opmerking:

you may enlighten me

[dusty]

Op dinsdag 22 januari 2002 10:39 schreef TheDane het volgende:
[..]
die eerste zin niet ik snap

Jij geeft elke optie een nieuw ID van een macht van 2.. Welke NUMMER heeft de LAATSTE optie. dus stel je hebt 400 opties wat is daar het exacte ID van?

[TheDane]

Op dinsdag 22 januari 2002 10:43 schreef dusty het volgende:

[..]

Jij geeft elke optie een nieuw ID van een macht van 2.. Welke NUMMER heeft de LAATSTE optie. dus stel je hebt 400 opties wat is daar het exacte ID van?

ik denk niet dat 't de bedoeling is dat bezoekers zelf nieuwe opties gaan verzinnen, of tussendoor gaan verwijderen.

dus 't is zowiezo max(opties)*2
en bovendien kun je die lijst heel fijn in excel oid maken, en exporteren als create/insert script


dus ik vind eigenlijk dat je 't verhaal ontwijkt, en op zoek bent naar manieren om mijn methode af te kraken, terwijl ik liever zou hebben dat je jouw methode bewijst. onafhankelijk van enige alternatieven.

maar voor 2^400 heb je een flink id nodig, i admit,.

[Janoz]

Op dinsdag 22 januari 2002 10:49 schreef TheDane het volgende:

[..]

ik denk niet dat 't de bedoeling is dat bezoekers zelf nieuwe opties gaan verzinnen, of tussendoor gaan verwijderen.

dus 't is zowiezo max(opties)*2
en bovendien kun je die lijst heel fijn in excel oid maken, en exporteren als create/insert script


dus ik vind eigenlijk dat je 't verhaal ontwijkt, en op zoek bent naar manieren om mijn methode af te kraken, terwijl ik liever zou hebben dat je jouw methode bewijst. onafhankelijk van enige alternatieven.

maar voor 2^400 heb je een flink id nodig, i admit,.

Wie zegt dat de bezoekers nieuwe opties verzinnen? Elk jaar weer worden er nieuwe opties bedacht... Kan me heel goed voorstellen dat binnenkort iedereen ook wel wil zoeken op brake assist, of steering assist.

Daarnaast is het model uit te breiden met een 'tussen tabel' om verschillende opties te combineren tot groepen waardoor het zoeken wat generaler wordt.

Met bits is het trouwens lastig zoeken op een combinatie van AND's en OR's. Helemaal als ze worden genest...

[TheDane]

Op dinsdag 22 januari 2002 10:59 schreef Janoz het volgende:

[..]

Wie zegt dat de bezoekers nieuwe opties verzinnen? Elk jaar weer worden er nieuwe opties bedacht... Kan me heel goed voorstellen dat binnenkort iedereen ook wel wil zoeken op brake assist, of steering assist.

Daarnaast is het model uit te breiden met een 'tussen tabel' om verschillende opties te combineren tot groepen waardoor het zoeken wat generaler wordt.

Met bits is het trouwens lastig zoeken op een combinatie van AND's en OR's. Helemaal als ze worden genest...

1e B : juist, lijkt me ook niet, dus vandaar mijn statement:)

2e B: excellent point !

*enlightenment*