What would be the best approach?
I've to a process that will potentially result in a table with over 91,000,000 rows.
The user will input a range of latitude and longitude values to download a csv file from that table, but here's my concern:
With that much data, I feel like it's going to be better to break up that one table and instead have 10 different tables, each one housing data specific to a particular state. Now when those queries are run, I'm asking my system to sort through less data and hence the app works quicker.
Is my concern justified or should I feel comfortable in setting things up in one mammoth table?
The user will input a range of latitude and longitude values to download a csv file from that table, but here's my concern:
With that much data, I feel like it's going to be better to break up that one table and instead have 10 different tables, each one housing data specific to a particular state. Now when those queries are run, I'm asking my system to sort through less data and hence the app works quicker.
Is my concern justified or should I feel comfortable in setting things up in one mammoth table?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Please post the CREATE TABLE statement and some of your test data. It only needs to be about 4 rows, but we need to see the complete row, with all of the columns filled. Armed with that (it's called the SSCCE) we should be able to give you some pretty solid ideas.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Did you work out a data model or are you discovering the best approach while coding?