Hi,
What's the most efficient way to store the following information:
* Table contains 1 million listings
* Each listing can be geo-targeted to any of the 200+ countries
* Searches return listings based on location
Option #1 (normalized)
* Listings (PK listingID int) [1 million rows]
* ListingLocations (listingID, locationID) [could be up to 200 million rows]
Option #2 (denormalized)
* Listings (PK listingID int, binary(32) with bit-mask consisting of 200 bits one for each location)
Usage: Usually the query will simply lookup listings based on some keywords. It will get back 50-200 listings. Then the application (C#) will filter the listings based on location.
Did anyone have experience with similar structures? Which option is more efficient?
I know that using the intersection-table in Option #1 is the "proper" relational-DB way of doing things. However, I do not like the idea of storing the listingID so many times (ones for each locationID).
Thanks,
Av
I think too the option #1 is the good solution and yourself explain this ("I do not like the idea of storing the listingID so many times (ones for each locationID)).
But i have an ideea vis-a-vis the way the users use your db: if your users should query the data using geographical criteria, let'say : country of West or Sud or East Europe, Africa etc you can use partitioned table with boundary values that geographic zones. So you'll grow the performance.
