SQL Whizes, come on in

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

crystal

Platinum Member
Nov 5, 1999
2,424
0
76
Since lat & long combine, will be distinct, use that to filter your results. Got it?
 

torpid

Lifer
Sep 14, 2003
11,631
11
76
Originally posted by: dmurray14
Originally posted by: torpid
Originally posted by: dmurray14
Originally posted by: torpid
No one is doubting the need for lat and long, we are doubting the need for such a non-normalized table structure.

OK, and what are you going to do about it? I have my reasons for doing what I have done, because it works for us.

I'm going to post here and say that you might want to re-consider that table design. What are YOU going to do about it?

Nothing, because you don't send me a paycheck every week.

But your bosses do, and they probably expect you to do things in a way that make sense. If you had put the lat & long in a separate table and normalized the DB, this query would be trivial and would increase the future capabilities to do queries based on lat & long.
 

torpid

Lifer
Sep 14, 2003
11,631
11
76
Originally posted by: isasir
Well obviously there's some column that has multiple different entries for the city. Lat and long work fine since it's the same for each city. You add a variable like, uh, gender, for example, and you'll start getting 2 results for each city. AFAIK, no way around that unless you get rid of that variable in the query.

I don't think this is true based on the OP, but maybe it is. If it is, then we need more information on how to determine which of the dupe rows is being returned, or if it is just a random one.