[SQL] Query filter vraagje

[JurjenK]

Sinds kort ben ik de wondere wereld betreden van SQL, helaas loop ik nu (al) vast met iets. Ik gebruik SQL in Microsoft Access 2010.

Het probleem is het volgende; ik heb een lijst met allemaal vliegvelden, zoals hier (een klein deel):

Name Lagos de Moreno airport ( LOM) - Mexico Linkoping airport ( LPI) - Sweden Lappeenranta airport ( LPP) - Finland Ludhiana airport ( LUH) - India Lusikisiki airport ( LUJ) - South Africa Luqa airport ( 995) - Malta Langgur airport ( LUV) - Indonesia Luwuk airport ( LUW) - Indonesia Maryborough airport ( MBH) - Australia (MBH) Luxembourg airport ( LUX) - Luxembourg Laval airport ( LVA) - France

Vervolgens wil ik alle vliegvelden uit Sweden, Finland en Mexico eruit halen, en alleen de vliegvelden uit de overige landen laten terugkomen. Voor één land lukt het me nog wel, maar voor meerdere landen krijg ik het maar niet voor elkaar. Het dichtstbijzijnde (of in ieder geval, wat mij het meest logisch leek) is het volgende:

SELECT Location.Name
FROM Location
WHERE Name NOT LIKE IN("*Sweden*", "*Finland*", "*Mexico*")

Helaas pakt ie de NOT LIKE IN() combinatie niet. Enig idee hoe dit op te lossen?

[NMe]

Zonder like en zonder wildcards. En waarom zoek je op namen in plaats van id's?

[voodooless]

Waarom voeg je bij Location geen country ID toe, dan kun je daar makkelijk op filteren in een IN. Anders moet je gewoon dynamisch je query bouwen door middel van een simpel loopje over je landen.

[RobIII]

Je kunt niet zomaar keywords door elkaar mikkeren (Like en IN) en er van uit gaan dat SQL wel snapt wat je bedoelt

Je zult iets moeten doen als:

SQL:

Where name like '*foo*'
 or name like '*bar*'
 or name like '*foobar*'

Eventueel kun je de laatste wildcard weglaten (dus "*foo") als het land altijd achteraan staat (en de string verder geen whitespace of andere rommel aan 't eind bevat en ...) maar "Australia (MBH)" geeft dan weer problemen...

Maar waar ik me meer zorgen over maak is dat je (schijnbaar?) geen losse velden hebt voor deze landinfo.

NMe schreef op donderdag 25 augustus 2011 @ 10:00:
Zonder like en zonder wildcards.

Zonder like/wildcards wordt 't lastig in dit geval Het kan wel...

SQL:

where right(name, 3) = 'foo'
 or right(name, 3) = 'bar'
 or right(name, 6) = 'foobar'

Linksom of rechtsom: dit gaat natuurlijk nooit fatsoenlijk performen. Ik zou dan ook eerst even gaan normaliseren en een fatsoenlijk DB ontwerp bouwen.

[ Voor 69% gewijzigd door RobIII op 25-08-2011 10:09 ]

[JurjenK]

Helaas krijg ik de database zo aangeleverd dat elk vliegveld niet op landen-niveau is georganiseerd.

RobIII schreef op donderdag 25 augustus 2011 @ 10:02:
Je zult iets moeten doen als:

SQL:

Where name like '*foo*'
 or name like '*bar*'
 or name like '*foobar*'

Eventueel kun je de laatste wildcard weglaten (dus "*foo") als het land altijd achteraan staat (en de string verder geen whitespace of andere rommel aan 't eind bevat en ...) maar "Australia (MBH)" geeft dan weer problemen...

Ik heb dit inderdaad geprobeerd, op de volgende wijze:

SQL:

SELECT Location.Name
FROM Location
WHERE Name LIKE "*Sweden*"
OR Name LIKE "*Finland*"
OR Name LIKE "*Mexico*"

Dit werkt bij mij niet zodra ik meerdere landen ga toevoegen (in dit geval Finland en Mexico). Alleen Sweden brengt hij wel keurig alle Zweedse vliegvelden terug, maar zodra er meerdere landen worden toegevoegd, brengt Access alles terug ipv alleen deze drie landen.

Australië kan ik er eventueel handmatig nog wel uit halen, als de (MBH) op het eind een probleem vormt..

[NMe]

Stop eens met die like, die dient hier geen enkel doel. Lees mijn vorige post nog eens.

[JurjenK]

Zoals je suggereerde, zonder like en zonder wildcards, heb ik dat gedaan;

SQL:

SELECT Location.Name
FROM Location
WHERE Name IN("Sweden", "Finland", "Mexico")

Maar hier geeft hij dan niets terug. Ook als je "*Sweden*" zo tikt, returned ie niets..

[voodooless]

Je zegt dat je de database kant en klaar gekregen hebt? Waarom pas je de database niet aan? Maak een extra country tabel, en filter de landen uit het Name veld in Location. Zet de country id's netjes in Location erbij, en je kunt lekker makkelijk filteren.

[P.O. Box]

JurjenK schreef op donderdag 25 augustus 2011 @ 10:41:
Helaas krijg ik de database zo aangeleverd dat elk vliegveld niet op landen-niveau is georganiseerd.


[...]


Ik heb dit inderdaad geprobeerd, op de volgende wijze:

SQL:

SELECT Location.Name
FROM Location
WHERE Name LIKE "*Sweden*"
OR Name LIKE "*Finland*"
OR Name LIKE "*Mexico*"

Dit werkt bij mij niet zodra ik meerdere landen ga toevoegen (in dit geval Finland en Mexico). Alleen Sweden brengt hij wel keurig alle Zweedse vliegvelden terug, maar zodra er meerdere landen worden toegevoegd, brengt Access alles terug ipv alleen deze drie landen.

Australië kan ik er eventueel handmatig nog wel uit halen, als de (MBH) op het eind een probleem vormt..

los van het feit dat het natuurlijk niet echt een lekker database ontwerp is, moet je aan het volgende denken:
(volgens mij heb je trouwens je query hierboven verkeerd gequote en bedoelde je:

SQL:

SELECT Location.Name
FROM Location
WHERE Name NOT LIKE "*Sweden*"
OR Name NOT LIKE "*Finland*"
OR Name NOT LIKE "*Mexico*"

)

simpele logica leert dat "Griekenland" NOT LIKE "Sweden" is, en dus getoond zal worden. simpele logica leert ook dat "Finland" NOT LIKE "Sweden" is, en dus getoond zal worden... m.a.w. voor ieder land geldt dat minimaal 1 van de voorwaarden TRUE is...

you do the math

[Teunis]

P.O. Box schreef op donderdag 25 augustus 2011 @ 11:42:
[...]

SQL:

SELECT Location.Name
FROM Location
WHERE Name NOT LIKE "*Sweden*"
AND Name NOT LIKE "*Finland*"
AND Name NOT LIKE "*Mexico*"

)

even kleine edit op bovenstaande post
anders komt sweden er gewoon door omdat het niet gelijk is aan Finland

Andere optie is

SQL:

SELECT Location.Name
FROM Location
WHERE 
NOT
(
 (Location.Name  Like '*Sweden') or
 (Location.Name  Like '*Finland') or
 (Location.Name  Like '*Mexico')
)

Afhankelijk hoevaak je dit moet doen kun je overwegen om de tabel aan te passen en deze velden zelf toe te voegen, zodat geheel makkelijker wordt om te filteren.

[ Voor 15% gewijzigd door Teunis op 25-08-2011 11:50 ]

[P.O. Box]

Teunis schreef op donderdag 25 augustus 2011 @ 11:48:
[...]

even kleine edit op bovenstaande post
anders komt sweden er gewoon door omdat het niet gelijk is aan Finland

Afhankelijk hoevaak je dit moet doen kun je overwegen om de tabel aan te passen en deze velden zelf toe te voegen, zodat geheel makkelijker wordt om te filteren.

zucht... kauw het anders voor...

(edit: nu ik mijn verhaal zo teruglees, kwam het ook niet echt over als een tip, maar meer alsof ik de kant en klare oplossing aandroeg.... dit was niet de bedoeling.... excuus)

[ Voor 17% gewijzigd door P.O. Box op 25-08-2011 11:51 ]

[NMe]

JurjenK schreef op donderdag 25 augustus 2011 @ 11:09:
Zoals je suggereerde, zonder like en zonder wildcards, heb ik dat gedaan;

Ik zie net pas dat je een query wil doen op die string met tig verschillende types data erin. Hoezeer zit je hieraan vast? Want hoewel je antwoord in de posts hier boven me staat ga je hier nog meer problemen van ondervinden als je de database niet normaliseert.

[JurjenK]

Teunis schreef op donderdag 25 augustus 2011 @ 11:48:

Andere optie is

SQL:

SELECT Location.Name
FROM Location
WHERE 
NOT
(
 (Location.Name  Like '*Sweden') or
 (Location.Name  Like '*Finland') or
 (Location.Name  Like '*Mexico')
)

Thanks, dit heeft heel erg geholpen. Krijg het nu inderdaad voor elkaar om alle landen eruit te filteren die ik eruit wilde filteren (wat er overigens meer dan 3 zijn).

P.O. Box schreef op donderdag 25 augustus 2011 @ 11:42:

simpele logica leert dat "Griekenland" NOT LIKE "Sweden" is, en dus getoond zal worden. simpele logica leert ook dat "Finland" NOT LIKE "Sweden" is, en dus getoond zal worden... m.a.w. voor ieder land geldt dat minimaal 1 van de voorwaarden TRUE is...

you do the math

Dit deed wel even m'n ogen openen. Thanks.

NMe schreef op donderdag 25 augustus 2011 @ 11:51:
[...]

Ik zie net pas dat je een query wil doen op die string met tig verschillende types data erin. Hoezeer zit je hieraan vast? Want hoewel je antwoord in de posts hier boven me staat ga je hier nog meer problemen van ondervinden als je de database niet normaliseert.

De database die ik krijg aangeleverd is verre van ideaal en clean. In principe kan ik er verder info eruit halen die ik nu eenmalig nodig heb, maar mocht ik 'm in de toekomst vaker nodig hebben, dan is het wellicht een idee om de database een beetje beter in elkaar te draaien.

Overigens bedankt voor alle hulp, wordt erg gewaardeerd!