[MSSQL] data negeren in query

[Verwijderd]

Momenteel ben ik bezig met ontwikkelen van applicatie dat werkt met projecten. Onder een project kunnen meerdere locaties voor komen. Een locatie kan ook onder meerdere projecten bekend zijn. Op het moment van invoer wordt er gecontroleerd (aan de hand van de locatie naam) of deze locatie al is ingevoerd in een project. Is de locatie bekend in een ander project dan het huidige project, dan kan hij bekend worden gemaakt in het huidige project (d.m.v. het toevoegen van een record in de tabel link_project_location). Dit mag niet een tweede keer gebeuren...

Ik heb onderstaande tabellen met data:

project

id	name
1	project 1
2	project 2

link_project_location

pr_id	lc_id
1	1
1	2
1	3
1	4
1	5
1	6
2	1
2	2
2	3
2	7

location

id	name
1	Houten
2	Houten
3	Houten
4	Houten
5	Houten
6	Houten
7	Houten

Nu loop ik tegen het volgende probleem aan; de onderstaande query wordt uitgevoerd:

SQL:

SELECT location.id, location.name, link_project_location.project_id
FROM location LEFT JOIN link_project_location on location.id = link_project_location.lc_id
WHERE (location.name LIKE '%Hout%'

resultaat

id	pr_id	name
1	1	Houten
2	1	Houten
3	1	Houten
4	1	Houten
5	1	Houten
6	1	Houten
7	2	Houten
1	2	Houten
2	2	Houten
3	2	Houten

Van het bovenstaande result worden ook de locaties met id 1, 2 en 3 meegenomen met pr_id 2. Maar deze record moeten eruit gefilterd worden, omdat deze al voor komen in project 1. Daarintegen locatie met id 7 komt nog niet in project 1 voor en mag wel meegenomen worden. Is hier een eenvoudige en universele manier voor? Want de applicatie kan meerder projecten bevatten dan alleen 1 en 2.

Ik hoop dat het verhaal en probleem duidelijk is.
Mocht dit niet het geval zijn dan hoor ik het graag...

[ Voor 3% gewijzigd door Verwijderd op 27-05-2008 14:04 ]

[RobIII]

Je zult met wat Aggregate functies en een GROUP BY moeten gaan werken (mits je de criteria weet te formuleren voor je aggregates, want die mis ik in je topic, je zegt alleen "Maar deze record moeten eruit gefilterd worden" maar niet waarom). Waarom zouden 1, 2 en 3 moeten afvallen en 7 niet? (Dan lees ik al snel: MAX() ).
En mocht ik je topic verkeerd begrijpen (en die kans is aanwezig, want ik heb moeite om er een zinnig touw aan vast te knopen) dan kan het antwoord ook nog wel eens zijn: zet een extra WHERE-clause
En schrijf je joins eens volledig uit in plaats van "FROM location, link_project_location". Dat is wel zo netjes.

Dido schreef op dinsdag 27 mei 2008 @ 14:06:
Als een locatie bij project 1 en 2 hoort, wil je dan het record van project 1 terughebben? Of van project 2? Of maakt het niet uit? Of moet het random zijn?

^^ Dat zeg ik "mits je de criteria weet te formuleren..."

[ Voor 39% gewijzigd door RobIII op 27-05-2008 14:07 ]

[Dido]

Als een locatie bij project 1 en 2 hoort, wil je dan het record van project 1 terughebben? Of van project 2? Of maakt het niet uit? Of moet het random zijn?

[Verwijderd]

Als er gewerkt wordt in project 1 en de locatie is bekend in project 1 EN 2, dan mag alleen de locatie van het huidige project terug komen, dus 1. Thanx!

[RobIII]

Dan zul je dus (handigst) een extra clause op je JOIN zetten met het "huidige project".

[Dido]

Het "huidige project", dus 1. Je zult op de een of andere manier het begrip "huidige project" moeten gebruiken, dus, want dat zie ik nergens. Er is geen standaard manier om te selecteren op iets waarvan jij toevallig weet wat het is

Maar dit is sowieso niet echt heel simpel.

Wat wil je precies met je query bereiken?

Ik kan me zo gauw niet indenken wat je wilt met een "lijst locaties die aan minimaal 1 project gekoppeld zijn, met daarbij een projectnummer dat zo mogelijk het huidige projectnummer is (en anders een willekeurig nummer?)

[Verwijderd]

het "Huidige project nr" is het project nummer waar je op dat moment in bezig bent, in dit geval heb ik project nr. 1 aangehouden.

[pedorus]

Als ik het goed snap wordt dus gevraagd om een lijstje met locatieId, het eerste het beste project op die locatie en de naam van die locatie? Met de voorwaarde dat als het huidige project het eerste het beste project kan zijn, dan moet het huidige project gezien worden als eerste het beste.

Na ja, een simpele GROUP BY op locationId met en MIN(pr_id) in de select moet dat wel oplossen lijkt mij.

Als het "huidige project nr" niet het laagste is, dan wordt het iets lastiger en kan er bijvoorbeeld gesorteerd worden (op afstand tot projectId) en gebruik worden gemaakt van FIRST.
(Het sorteren kan dan als volgt: select ... from (select tabelnaam order by ...) AS tabelnaam ... )

Die namen van de id's zijn akelig gekozen, waardoor dingen als NATURAL JOINs of USING niet meer goed werken en het lastig te begrijpen is.