Feil med sql spørring

[stian90_2]

Hei. Jeg får stadig error "Invalig use of group function"

Jeg har denne sql spørringa:

 

SELECT mottaid,COUNT(*) FROM cm WHERE kjonn='Jente' GROUP BY mottaid ORDER BY COUNT(*) DESC LIMIT 1

 

Hva er galt, har prøvd det meste nå i noen timer. Uten og skjønne det helt =/

[roac]

Hei. Jeg får stadig error "Invalig use of group function"

Jeg har denne sql spørringa:

 

SELECT mottaid,COUNT(*) FROM cm WHERE kjonn='Jente' GROUP BY mottaid ORDER BY COUNT(*) DESC LIMIT 1

 

Hva er galt, har prøvd det meste nå i noen timer. Uten og skjønne det helt =/

7037039[/snapback]

I Microsoft SQL Server vil tilsvarende gå, hva som gjør at (MySQL?) ikke takler denne er jeg ikke sikker på, men du kan prøve følgende:

 

SELECT mottaid,COUNT(*) AS antall FROM cm WHERE kjonn='Jente' GROUP BY mottaid ORDER BY antall DESC LIMIT 1

 

Uten at jeg på noen måte vil garantere at det kommer til å virke, og jeg har ingen MySQL database jeg kan teste dette på. Forøvrig så bør kjonn reduseres til et enkelt tegn siden det bare er to valgalternativer, eller kanskje til og med datatypen bit (som dessverre er tatt ut av SQL-standarden i SQL:2003).

[stian90_2]

Joda, den funker veldig fint den. Så fikk jeg lært noe nytt i dag også. Takk for hjelpen

[Manfred]

men... har kjønn som en varchar? bra vi ikke lager spesielt mye overkill her da

[roac]

men... har kjønn som en varchar? bra vi ikke lager spesielt mye overkill her da

7096315[/snapback]

Jo, men det er nok av de som har dette som 'Mann' og 'Kvinne'

[Manfred]

hva med et bit-felt? kan det egentlig være så mye annet enn enten eller?

[roac]

hva med et bit-felt? kan det egentlig være så mye annet enn enten eller?

7096334[/snapback]

Nei, men det er nå også sånn at det ikke nødvendigvis er en god idé å basere seg på bit. Når det gjelder kjønn så kan dette være fordi kjønn ikke nødvendigvis alltid er kjent (Ja, jeg vet at man kan bruke NULL her, men skal man ha større og mer komplekse spørringer så vil det være en fordel å eliminere en hel del sjekk på NULL). Videre bør man kanksje vurdere hvor smart det er å bruke datatypen bit, siden det er en datatype som er tatt ut av sql-standarden i SQL:2003. Det kan derfor være at bit blir fjernet fra databaseimplementasjoner, selv om jeg strengt tatt håper at det ikke vil skje.

 

Personlig vil jeg nok foretrekke å bruke en enkelt char til kjønn, av hensyn til lesbarhet, kodeeffektivitet og kode som følger siste sql-standard.

[roac]

Edit: Dobbeltpost

Endret 18. oktober 2006 av roac

[Manfred]

En ting er da å bruke en char som kjønn, evt. kjøre dette som en fremmednøkkel-int. Du kan kanskje si det er litt overkill, men kan være greit å få ut "Mann", "Kvinne", "Ukjent", "MTF", "FTM" osv fra en spørring, så slipper man så mye kode rundt. I tillegg slipper man dobbeltlagring av masse bokstaver

[roac]

En ting er da å bruke en char som kjønn, evt. kjøre dette som en fremmednøkkel-int. Du kan kanskje si det er litt overkill, men kan være greit å få ut "Mann", "Kvinne", "Ukjent", "MTF", "FTM" osv fra en spørring, så slipper man så mye kode rundt. I tillegg slipper man dobbeltlagring av masse bokstaver

7110810[/snapback]

Jeg vil faktisk si at det er en dårlig idé, rett og slett fordi du vil få ekstra overhead i forbindelse med join, og det er minimalt med besparelse på radstørrelse. Normalisering er i utgangspunktet en god idé, men ikke alltid

[Manfred]

Det spørs litt hva det skal brukes til, og hvor mange valg du skal ha. Som du ser la jeg på to alternativer du ikke hadde med. Skal du bruke en bokstav krever dette at man vet hva de står for når man programmerer, dessuten krever det da mer programmeringsteknisk med conditionals eller if'er når man skal vise dette på en site.

[roac]

Det spørs litt hva det skal brukes til, og hvor mange valg du skal ha. Som du ser la jeg på to alternativer du ikke hadde med. Skal du bruke en bokstav krever dette at man vet hva de står for når man programmerer, dessuten krever det da mer programmeringsteknisk med conditionals eller if'er når man skal vise dette på en site.

7111941[/snapback]

Jeg tror ikke du forstår hva jeg mener. Jeg sa ikke at du SKULLE bruke en bokstav, men jeg sa at det var en dårlig idé å trekke de alternativene ut i en egen tabell, siden det er ekstra overhead forbundet med join mellom de to tabellene. Det vil også være overhead i forbindelse med ivaretagelse av referential integrity, så da ville jeg heller ivaretatt tekst i tabellen.

[Manfred]

Jeg bare mener at det er en uting å ha "Gutt", "Jente" osv som tekst i en tabell. Men det er min mening.

[roac]

Jeg bare mener at det er en uting å ha "Gutt", "Jente" osv som tekst i en tabell. Men det er min mening.

7113156[/snapback]

Har du noen god begrunnelse for dette? Slike betraktninger bør skje på et faglig grunnlag, ikke hva man synes. Generelt sett er normalisering bra, men ikke nødvendigvis til enhver pris, og databaser kan fint bli tregere ved å normalisere mer enn strengt tatt nødvendig, og dette vil være et klart tilfelle hvor man sannsynligvis bare vil få ekstra overhead ved å normalisere.

[Manfred]

både ut ifra normalisering, men også ut ifra den tanken at man skal jobbe med dette senere også. Det å legge inn fulltekst "gutt", "jente" skriker imot ethvert prinsipp for min del når det kommer til databaser.

[roac]

både ut ifra normalisering, men også ut ifra den tanken at man skal jobbe med dette senere også. Det å legge inn fulltekst "gutt", "jente" skriker imot ethvert prinsipp for min del når det kommer til databaser.

7117652[/snapback]

Hvilket prinsipp?

[Manfred]

Er du bare født vrang, egentlig?

[roac]

Er du bare født vrang, egentlig?

7117805[/snapback]

Nei det er jeg ikke, men det virker som om du har bestemt deg for at det er best å trekke de dataene ut i en egen tabell uten egentlig å ha en veldig god grunn til det, og det stiller jeg meg kritisk til. Hvis du kan komme opp med en plausibel begrunnelse for den relativt ekstreme normaliseringen så er det vel og bra, men jeg kan ikke se at du har kommet med det, men sier at det er prinsippielet. Jeg har i det minste beskrevet hvorfor jeg finner denne graden av normalisering lite hensiktsmessig, du har sagt at det er fordi du ikke liker det, noe som profesjonelt sett er en meget dårlig begrunnelse.