Shared Table in Database, or Multiple Data? Storing Real-World Location in DB

I have what seems like what could be a simple question but might be more difficult than anticipated. Let's s开发者_开发知识库ay I'm trying to track the latitude and longitude of Users and Businesses. Right now, I have a table called locTable, that contains 3 columns: Index, Latitude, Longitude.

The table that stores information for the Users and Businesses contain a FK to the locTable. This allows me to use one table to store the location data, however I've noticed doing queries on this data might be difficult.

Now, I could store Latitude and Longitude information in each table for Users and Businesses, however if I need to make changes regarding the data, I would have to update the queries along with two (or more) different tables.

What would you all suggest? Shared table or store the information separately?

---

First off, establish whether lat/long is a "lookup" table. I would not consider Lat/Long to be a lookup. What that means is you would not store an exhaustive list of every possible Lat/Long combo. They are often specified to 4 decimal places. In theory there could be infinite Lat/Long combo's if you have infinite scale.

I would not consider it duplication to store lat/long in both tables. Think of BirthDates. To avoid BirthDate duplication you could have a "BirthDates" table with a row for every day in the last 300 years. This would avoid BirthDay duplication of people, dogs, and companies. But it is not duplication in the "lookup" sense.

I am not suggesting it is wrong to store Lat/Long in it's own table. I'm just suggesting it may not be considered duplication to store Lat/Long in both tables.

---

Are the locations changing? If so, reverse the foreign key. Have the location table have a foreign key the user's and businesses table. Add a date column to the location table, and you can also track them over time just by adding new locations.

With your model, you potentially have to update two tables in order to update the location. With switching the foreign key around, all you have to do is add new rows to the location table when the location changes.