在 MySQL 表中存储运费，将来会添加许多列
我正在创建一个系统，用户可以在其中指定其商品的运费。我需要涵盖的变量是重量范围（从克到克）、价格和涵盖的国家/地区。根据这些数据，我可以通过参考客户所在国家/地区和篮子的总重量来计算运输成本。
我的第一个想法是这样的：
id from_weight to_weight price us ca gb fr es de it
------------------------------------------------------------------
1 0g 499g 1.99 Y Y N N N N N
2 500g 999g 2.99 Y Y N N N N N
3 1000g 1999g 4.99 Y Y N N N N N
4 2000g 2999g 7.99 Y Y N N N N N
5 0g 499g 4.99 N N Y Y Y Y Y
6 500g 999g 6.99 N N Y Y Y Y Y
7 1000g 1999g 9.99 N N Y Y Y Y Y
8 2000g 2999g 14.99 N N Y Y Y Y Y
但是计划将添加越来越多的国家/地区选项。这意味着每次添加更多列。这是构建此类数据的最佳方法吗？任何其他建议
I'm looking to create a system where users specify shipping prices for their items. The variables I need to cover are the weight band (from in grams to in grams), the price and the countries covered. From this data I can calculate shipping cost by referencing the customers country and the total weight of the basket.
My first thought is something like this:
id from_weight to_weight price us ca gb fr es de it
------------------------------------------------------------------
1 0g 499g 1.99 Y Y N N N N N
2 500g 999g 2.99 Y Y N N N N N
3 1000g 1999g 4.99 Y Y N N N N N
4 2000g 2999g 7.99 Y Y N N N N N
5 0g 499g 4.99 N N Y Y Y Y Y
6 500g 999g 6.99 N N Y Y Y Y Y
7 1000g 1999g 9.99 N N Y Y Y Y Y
8 2000g 2999g 14.99 N N Y Y Y Y Y
However the plan would be to add more and more country options. This would mean adding more columns each time. Is this the best way to structure this kind of data. Any other suggestions
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通常，首选做法是保持表结构相同，只添加行以满足您所说明的情况。 （由于优化等原因，您可能会偏离这一点）
我建议您查找“第三范式”，如果您的数据库符合第三范式的规则，那么您通常会减少很多维护以及更容易的扩展性。
这就是您查询数据的方式
normally it is preferred practice to leave the table structure the same, and just add rows to cater for the case that you illustrated. (there are reasons such as optimisation where you can deviate from this)
I would suggest at looking up "3rd Normal Form", if your database complies with the rules to be in 3rd normal form then, you generally end up with a lot less maintenance and easier extendibility down the track.
this is how you would query the data
如果您想避免添加列，您可以添加第二个表，其中包含 PriceID 和 Country 作为列，然后删除所有国家/地区列。然后，您只需使 PriceID 具有引用第一个表中的 ID 的外键，您就可以根据需要添加新的国家/地区。
If you want to avoid adding columns, you can add a 2nd table that has priceID and Country as columns and just remove all the country columns. Then you just make priceID have a foreign key referencing the ID from your first table and you can add new countries as needed.
是的，我会这么说。您的目标是查找给定重量和国家/地区组合的价格，因此执行此查询应该很容易：
并且您的架构可以轻松实现这一点。我建议您选择 to_weight，使值 499.9 适合其中一个类别，除非权重被限制为整数。我不担心添加新列，这很简单，您可以针对任何新国家/地区将其默认为 false。
Yes, I'd say so. Your goal is going to be to find the price for a given weight and country combination, so it should be easy to perform this query:
And your schema allows that easily. I'd recommend that you select your to_weight such that a value of 499.9 fits in one of the categories, unless weight is restricted to be an integer. I wouldn't worry about adding new columns, that's easy and you can default it to false for any new country.
表格的行似乎形成了相关定价计划的组。如果是这种情况，我建议您有一个
PricingPlan表和一个PlanDetail表。应使用第三个
PlanCountry表，这样您就不必为要与定价计划关联的新国家/地区添加任何列（例如，将在该表中添加一个新行）您希望将墨西哥纳入 planA)：It seems the rows of your table form groups of related pricing plans. If that's the case, I would suggest you have a
PricingPlantable and aPlanDetailtable.A third,
PlanCountrytable should used so you don't have to add any columns for new countries that you want to relate to a pricing plan (a new row would be added in that table, if for example you want Mexico to be included in planA):