我想在数据库中存储公制单位 - 我应该使用什么数据类型？
我想将最终以英制/美国显示的高度（例如 6 ft 4）存储在当前为 MySQL 的数据库中（我计划将其迁移到 PostgreSQL）。
我想知道什么单位适合这种类型的存储，以及我应该使用什么列类型？我正在考虑厘米/公制系统和一些数字列类型，但如果有人可以提供见解，那就太好了。
I'd like to store height which would eventually be displayed in Imperial/US ( 6 ft 4 for example ) in a database which is currently MySQL ( which I plan to migrate to PostgreSQL ).
I'm wondering what unit is good for this type of storage, and what column type I should use? I'm thinking centimeters/metric system and some numeric column type, but would be great if someone can provide insight.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为这主要取决于对数据进行什么操作。如果只是要存储和检索以供显示，则将其存储为文本。如果您需要进行平均值和范围等计算，请在简化为基本测量单位（例如英寸或百分之一英寸）后将其存储为数字类型。整数或浮点类型的选择再次取决于您需要执行的计算。
在数据库中转换为公制，然后返回英制单位进行输出的唯一原因是，如果您出于某种其他原因需要公制，并且比以英制生成输出更重要/更频繁。否则，您所做的就是在两个方向上引入舍入误差。
I think it mostly depends on what operations are to take place on the data. If it is just going to be stored and retrieved for display, then store it as text. If you need to do calculations like average and range, store it in a numerical type after reducing to a base unit of measure (e.g., inches, or hundredths of an inch). The choice of integer or floating-point type again depends on what calculations you need to perform.
The only reason to convert to metric in the db and then back to Imperial units for output would be if you need metric for some other reason, and one that is more important/frequent than generating output in Imperial. Otherwise all you are doing is introducing rounding errors in both directions.
使用 int 数据类型将其存储为厘米。注 1 厘米 = 0.39370078740157477 英寸
store it as centimetres using an int datatype. Note 1cm = 0.39370078740157477in
如果它们是连续数量，则将它们以米为单位存储为浮点数，并在报告中转换为米、米+厘米、英尺、弗隆。
如果它们是您不希望出现舍入误差的固定单位（例如产品尺寸），则将它们作为 int 存储在最小公制细分 ml、mm、mg 等中，并再次在输出时进行转换
If they are continous quantities then store them in metres as a float and convert into metres, metres+cm, feet, furlongs in the report.
If they are fixed units that you don't want a rounding error on, like product sizes, then store them as an int in the smallest metric subdivison ml,mm,mg etc. and again convert on output
我完全不明白为什么任何数据库都比其他数据库更好地存储公制单位而不是英制单位。在处理存储测量值的问题时，我看到了两种主要的思想流派。以最小的合理单位存储并将其用作所有内容的基础（即所有内容均以克和厘米为单位）。另一种方法是如果您使用混合单位，则用比例存储单位，但这可能会使设置变得不必要的复杂化。
如果无法使用比基本单位更高分辨率的测量值，则可以使用 int 或 long 来存储值。
Off of the top of my head I can't see why any database would be better than any other for storing metric units verses imperial ones. When approaching the problem of storing measurements, I see two major schools of thought. Store in the smallest reasonable units and use it as a base for everything (i.e. everything is in grams and cm). Another way would be to store the units with a scale if you're using mixed units, but this would probably complicate the setup more than necessary.
You can use an int or long to store the value if there is no possibility for measurements with a higher resolution than your base unit.
如果您只想以英制显示，那么很可能没有充分的理由以公制存储。只需使用
int来存储英寸数即可省去麻烦。如果您需要比这更高的分辨率，可以：int来存储（例如）十分之一英寸当您仅存储“数百/数千人的身高”时，存储问题不太可能成为问题。
If you are only ever going to display in Imperial, then there may well be no good reason to store in metric. You will save yourself hassle by simply use an
intto store the number of inches. If you need more resolution than that, either:intto store (for example) tenths of an inchAs you are storing only "hundreds/thousands of peoples' heights", storage issues are very unlikely to be a worry.
这可能听起来很尴尬，但如果帝国措施是默认的，它可能对你有用。
比我将长度存储在 CHAR(2) 中作为十六进制值。 6 英尺 11 英寸变为 6B，该列可排序，并且不会出现在存储公制长度时可能发生的舍入问题。
That might sounds awkward, but it may work for you in case Imperial measures are default.
Than I'd store length in CHAR(2) as HEX value. 6 ft 11 in becomes 6B, the column is sortable and you have no rounding problems which may happen in case you're storing metric lengths.