I have been working on a MS 2010 Access Database to calculate rates on a CSV input of shipments.
A rate is generally distinguished by the Origin City, Origin Country, Destination City, Destination Country, a possible mid-way Destination City, Weight, Volume, and Quantity. A unique combination of these variables will specify another list of variables which are used to calculate the final rate by multiplying these variables against the weight, volume, or quantity, and adding them together.
One issue is that there is an inconsistency in City and Country names/spellings. My other concern is that I am feeling I could benefit from splitting the data into multiple tables, but unsure how to best accomplish this.
Edit:
Thank you for your criticisms. My question is, what is the best way to structure this database? Here is a simplified example of my table:
rates (startCity, startCountry, midCity, midCountry, endCity, endCountry, type, weight, volume, baseRate, feeA, feeB, feeC, delivery, fuel)
Everything is in one table, and it doesn’t really have a unique identifier/key. Instead each line is unique in that at least one of the locations or the type is different.
csv input: shipmentID, startCity, startCountry, midCity, midCountry, endCity, endCountry, type, weight, volume, qty
query output: shipmentID, {qty*[baseRate+weight*(feeA+feeB)+volume*(feeC)+delivery+fuel]}
I am not sure I understand your question. If you are looking for a database structure I would come up with the following 3 tables:
location (id, cityname, zipcode, country_ID)
country (id, countryname)
route (id, startlocation_ID, midlocation_ID, endlocation_ID, ratefactor)
The final rate is probably based on a formula. The route-dependent part of the formula needs to be put into the “route” table as “ratefactor”. Whether you need to put the other parts of the formula in a table, too, will depend on the formula itself (you didn’t tell us enough about it). Entering of city/country names should be done with a dropdown list where the user can choose only between the ones already entered. Most of the time your users will probably use the routes tables with the already entered regular routes, I guess. If your company does serve any location in the world you can’t avoid letting them enter new city names all the time themselves, of course.
UPDATE: After your EDIT I suggest you look deeper into the topic of database normalization. At example your “rates” table looks like you will have many, many identical routes differing only on the weight. So it would make sense to keep the route information separately as I suggested already. The additional information should go in a separate table (quote: id, route_ID, type, weight,…).
“(feeA + feeB)” and “feeC” seem to be the ratefactors I mentioned in my suggestion. But I don’t see the reason of having both feeA and feeB, because they are always added together before being used. If they refer to the price of connecting to cities and your would need to keep this information separate it would probably be best to keep the price information in a different table (connectionprice: id, locationA_ID, locationB_ID, pricing) and look it up instead of entering it every time anew.
Although one can argue you don’t need a separate PK if you have different fields whose combination makes for an unique identifier, I would make a habit of creating one (“id”) for each table nonetheless. Nearly always it makes programming access and information retrieval so much easier.