[SQL] Select Distinct geeft duplicaten.

[paragon]

Ik probeer vanuit een tabel informatie te halen om deze aan een andere tabel toe te voegen. Omdat ik geen dubbele email adressen wil toevoegen aan de nieuwe tabel dacht ik dit op te lossen door een Select Distinct te gebruiken. Echter in het resultaat komen toch dubbele email adressen voor.

SQL:

Select Distinct Email, NameF, NameL, DOB From ClubGuestsLists

De functie van Distinct is toch in dit geval dat ik niet dubbele Email adressen krijg?

Bovenstaande SQL is en kortere versie van de werkelijke SQL die ik gebruik, maar het 'resultaat' is hetzelfde.

Ik maak gebruik van ASP en MS SQL Server

[ Voor 10% gewijzigd door paragon op 12-04-2007 18:03 ]

[Kleintje81]

Al DISTINCT ROWS geprobeerd?

[paragon]

Distinct Rows geeft toch juist het zelfde email adres weer wanneer bijvoorbeeld het DOB veld verschilt?

[e-mail] 19/1/2003
[e-mail] 18/1/2003

Die worden dan toch beiden geselecteerd?

[Kleintje81]

paragon schreef op donderdag 12 april 2007 @ 18:09:
Die worden dan toch beiden geselecteerd?

Heb je de overige waarden wel nodig?
Anders zou ik het beperken tot een:

code:

Select Distinct Email From ClubGuestsLists

[paragon]

Ja ik heb die overige waarden zeker nodig.

[Kleintje81]

paragon schreef op donderdag 12 april 2007 @ 18:16:
Ja ik heb die overige waarden zeker nodig.

Ik zie het nut zo gauw niet om bv een datum mee te selecteren.
Mijn vermoeden is dat daar je probleem zit.

Wat meer achtergrond informatie over je nieuwe tabel zou ook handig zijn...

[MeatLoaf]

Een distinct geeft elke unieke regel maar één keer weer. Als het lijkt dat je dubbele regels krijgt zit er toch een verschil in een van de vier velden. Oftewel de Distinct geld voor alle geselecteerde velden.

Wil je alleen de unieke email-adressen hebben dan zul je toch een Select Distinct moeten doen met alleen het email adres.

[ Voor 9% gewijzigd door MeatLoaf op 12-04-2007 18:24 ]

[Sh0ckTr00per]

distinct is ervoor om dubbele rijen weg te filteren. Dus als 1 van de velden uit je resultaatset verschilt van een andere rij, maar de rest overeen komt, krijg je beide rijen terug. In de praktijk heb je maar heel zelden distinct nodig als je database fatsoenlijk genormaliseerd is.

[paragon]

@Kleintje81

Die overige info heb ik nodig, laten we zeggen dat het een brakke db is en er staat veel redundante info in. Ik wil nu van 1 tabel af maar een gedeelte van de inhoud moet overgezet worden naar de andere tabel. Waaronder dus de DOB

@Meatloaf

Daar was ik dus al bang voor. Maar het is toch wel mogelijk via SQL om geen dubbele email adresseb terug te krijgen zonder alleen het email veld te selecteren?

@ShockTrooper

Brakke db dus

[ Voor 4% gewijzigd door paragon op 12-04-2007 18:30 ]

[Cyphax]

paragon schreef op donderdag 12 april 2007 @ 18:29:
Daar was ik dus al bang voor. Maar het is toch wel mogelijk via SQL om geen dubbele email adresseb terug te krijgen zonder alleen het email veld te selecteren?

Tuurlijk kan dat, de vraag is: wat moet er gebeuren met de rijen die niet uniek zijn?
Bijvoorbeeld:

E-mailadres Anderewaarde
[e-mail] X
[e-mail] Y

Je hebt Anderewaarde ook nodig maar je wilt toch het e-mailadres uniek hebben. Wil je X terug of maakt het niet uit?

[Kleintje81]

Je zou van die 'flexibele' waarden een keuze moeten maken welke je wilt bewaren.
Bv de eerste of laatste datum.

Misschien dat je iets icm SELECT TOP 1 in elkaar kan zetten.

[_js_]

DISTINCT geeft unieke rijen in het resultaat terug.
DISTINCT ROW haalt unieke rijen uit tabellen

Wat jij nodig hebt is GROUP BY en funties als MAX en MIN om aan te geven welke waarden je voor bv. DOB wilt hebben.

[sanzut]

SQL:

SELECT DISTINCT(Email), NameF, NameL, DOB From ClubGuestsLists

Bij de oude SQL code moest email,nameF,nameL en DOB uniek zijn

[ Voor 26% gewijzigd door sanzut op 12-04-2007 18:58 ]

[paragon]

Het maakt niet uit welke DOB er overblijft het is zijn guestlist requests maar daarbij hebben de personene dus meerdere malen een request gedaan alleen de DOB net even iets anders ingevuld.

[Exterazzo]

SQL:

SELECT Email, NameF, NameL, MAX(DOB) FROM ClubGuestLists GROUP BY Email

Zoiets, maar dan moeten de NameF en NameL ook wel altijd hetzelfde zijn, anders kun je daar ook nog een MAX omheen zetten.

Als het toch alleen maar om het email adres gaat, dan kun je ook wel een MAX om die andere velden zetten. Dan krijg je als het goed is alleen de verschillende email adressen en de namen en geboortedata erbij.

Dus zo:

SQL:

SELECT Email, MAX(NameF), MAX(NameL), MAX(DOB) FROM ClubGuestLists GROUP BY Email

[ Voor 43% gewijzigd door Exterazzo op 12-04-2007 19:20 ]

[paragon]

sanzut schreef op donderdag 12 april 2007 @ 18:57:

SQL:

SELECT DISTINCT(Email), NameF, NameL, DOB From ClubGuestsLists

Bij de oude SQL code moest email,nameF,nameL en DOB uniek zijn

Dit heeft bij mij hetzelfde effect

[Sh0ckTr00per]

Exterazzo schreef op donderdag 12 april 2007 @ 19:14:

SQL:

SELECT Email, NameF, NameL, MAX(DOB) FROM ClubGuestLists GROUP BY Email

Zoiets, maar dan moeten de NameF en NameL ook wel altijd hetzelfde zijn, anders kun je daar ook nog een MAX omheen zetten.

Jep, je moet ofwel NameF en NameL dan ook in de group by opnemen of er ook een aggregate van maken (max, min, etc)

[whoami]

paragon schreef op donderdag 12 april 2007 @ 19:12:
Het maakt niet uit welke DOB er overblijft het is zijn guestlist requests maar daarbij hebben de personene dus meerdere malen een request gedaan alleen de DOB net even iets anders ingevuld.

Als het niet uitmaakt welke DOB er getoond wordt, waarom moet je hem dan tonen ?
En als je 'm dan toch wil tonen, dan zal je met MIN of MAX aan de gang moeten, en met GROUP BY moeten werken.
Trouwens, hoe bedoel je de DOB is net iets anders ingevuld ? Wordt die datum dan niet in een datum-veld opgeslagen ?

[paragon]

Ik zal het maar even wat duidelijker proberen uit te leggen. Er is een db met daarin een tabel waarin alle 'leden' van een club staan vermeld hier staat al hun gegevens in. Nu heeft er iemand een pagina gemaakt waarbij willekeurige mensen een gastenlijst aanvraag kunnen doen, dit kunnen ze dus meer dan 1 keer hebben gedaan. Bij het aanvragen vullen ze onder andere hun naam, achternaam, email en geboorte datum in. Nu komen verschillende mensen dus vaker voor in de gastenlijst-aanvraag-tabel. Alleen hebben mensen dus net even hun overige personalia some net even anders ingevoerd. Verschillen zijn klein.

De bedoeling is dus dat ik alle data uit de velden in de gastenlijst-aanvraag-tabel die overeenkomt met velden uit de leden-tabel invoeg in de leden tabel dus even een voorbeeld.

leden-tabel velden
PeopleID, PeopleStatusID, Email, NameF, NameL, DOB, OptEmail

gastenlijst-aanvraag-tabel velden
RequestID, Email, NameF, NameL, DOB, Guests, RequestDate

Ik moet dus iets hebben wat in dit geval uit de gastenlijst-aanvraag-tabel de Email, NameF, NameL en DOB selecteert en daarbij dus niet dubbele Email adressen.

Ik hoop dat dit wat duidelijker is allemaal

[Reinier]

Geef eens een voorbeeld van de records die naar jouw mening dubbel zijn? Je zegt namelijk dat er bijvoorbeeld verschillende DOBs ingevuld zijn bij hetzelfde emailadres. Je query geeft dan uiteraard meerdere keren dat emailadres terug (want de records verschillen).

[Voutloos]

Hoe je de query goed moet krijgen mag inmiddels toch wel duidelijk zijn, je moet gewoon zelf bepalen wat je met die andere velden doet.

Imo zit een belangrijk deel van het probleem in het aanvraagformulier. Waarom licht je mensen niet alvast in dat met ingevuld mailadres al eerder een aanvraag gedaan is (met al dan niet gevolgen voor het kunnen indienen van een volgende aanvraag)?

Overigens wel apart dat DOB vaak anders ingevuld wordt. Gaat het invullen van deze datum wel intuitief, gebruik je het juiste datatype, etc. etc. Uiteraard moet je alsnog een keuze maken welke DOB je weergeeft bij meerdere rijen met hetzelfde emailadres, maar ook op dit punt kan je misschien/wellicht wel de input en daarmee de kwaliteit van je data verbeteren.

[paragon]

Voutloos schreef op vrijdag 13 april 2007 @ 08:27:
Hoe je de query goed moet krijgen mag inmiddels toch wel duidelijk zijn, je moet gewoon zelf bepalen wat je met die andere velden doet.

Imo zit een belangrijk deel van het probleem in het aanvraagformulier. Waarom licht je mensen niet alvast in dat met ingevuld mailadres al eerder een aanvraag gedaan is (met al dan niet gevolgen voor het kunnen indienen van een volgende aanvraag)?

Overigens wel apart dat DOB vaak anders ingevuld wordt. Gaat het invullen van deze datum wel intuitief, gebruik je het juiste datatype, etc. etc. Uiteraard moet je alsnog een keuze maken welke DOB je weergeeft bij meerdere rijen met hetzelfde emailadres, maar ook op dit punt kan je misschien/wellicht wel de input en daarmee de kwaliteit van je data verbeteren.

Je hebt helemaal gelijk, het is dan ook geen aanvraag formulier van mezelf maar van iemand anders, database is ook een puinhoop (was al duidelijk). Ben aan het puinruimen. Ik heb het opgelost door wat ASP code te gebruiken. Volgende stap is dan ook het aanpassen van het aanvraag formulier.

[momania]

Er wordt al een paar keer gezegd dat je dan een min of max moet gebruiken icm een group by, maar moeten we het maar uitspellen voor je?:

SQL:

Select Email, max(NameF), max(NameL), max(DOB) From ClubGuestsLists group by Email

[paragon]

momania schreef op vrijdag 13 april 2007 @ 14:47:
Er wordt al een paar keer gezegd dat je dan een min of max moet gebruiken icm een group by, maar moeten we het maar uitspellen voor je?:

SQL:

Select Email, max(NameF), max(NameL), max(DOB) From ClubGuestsLists group by Email

Neehoor dat had niet gehoeven. Ik heb het via ASP opgelost omdat dit niet alle velden in de select zijn en het dan wel een erg lange lap sql zou worden.