Как обрабатывать сантиметр от / до дюймов - PullRequest
1 голос
/ 18 мая 2011

У меня есть международное приложение, которое обрабатывает длины и веса людей и сохраняет их в базе данных. Мне было интересно, как с этим справиться, если пользователи могут переключаться между использованием сантиметров / дюймов в приложении.

Я думал всегда использовать сантиметры в базе данных и конвертировать в дюймы, если пользователь решил использовать дюймы. Но, конечно, если пользователь вводит длину в дюймах, и она преобразуется в сантиметры и сохраняется в ней, значение может немного измениться из-за ошибок округления.

Как бы вы справились с этим сценарием?

Спасибо, L

Ответы [ 7 ]

2 голосов
/ 18 мая 2011

В вашем вопросе есть много вопросов, помимо имеющейся информации.Прежде чем принять решение о том, как хранить и преобразовывать информацию, вы должны знать, какая у вас допустимая ошибка.Например, если вы рассчитываете траекторию для перехвата поступающей ракеты с другой ракетой, для достижения успеха необходима чрезвычайно маленькая точность.Если это медицинское применение и используется для точного контроля рецептуры лекарственного средства, может быть важнее быть точным, чем если бы вы просто рассчитывали ИМТ.

Короче, выберите стандарт, метрический или другой, и придерживайтесь его для своего типа хранения.в зависимости от требуемой точности выберите наименьшую единицу измерительной системы, которая обеспечит вам необходимую точность.Все показы единиц измерения другой системы измерений будут преобразованы из этого базового измерения.

И постарайтесь не перегружать решение.Если, очевидно, не будет важно отмерить до 52 знаков после запятой, вы тратите впустую усилия и вводите ненужные осложнения, объясняющие этот сценарий.

1 голос
/ 18 мая 2011

Если один и тот же пользователь должен иметь возможность переключаться во внешнем интерфейсе, вам определенно следует сохранить одно поле, представляющее значение в одной единице, которую вы определили, потому что ошибки округления все равно произойдут.

Если у вас есть группаесли пользователи имеют дело только с дюймами, а другие - только с сантиметрами, и каждая из этих групп имеет свою одну базу данных или, по крайней мере, «свои значения», то выбирают два поля: значение / единица (например, одно и то же программное обеспечение, разная установка клиента в разных странах)

Я бы хранил значения не с плавающей запятой, представляющие, например, микрометры (с 32-разрядным без знака вы можете представлять все от 4,2 км до 0,001 мм).

1 голос
/ 18 мая 2011

Таким образом, вы будете иметь ошибки округления, если вы конвертируете из сантиметров в дюймы, и если вы конвертируете из сантиметров в дюймы.Проблема будет одинаковой, независимо от того, что вы храните в БД.

Вы можете хранить значения не в сантиметрах в базе данных, а в миллиметрах.Поэтому я думаю, насколько меньше единица, тем точнее она будет, даже в случае конвертации.

1 голос
/ 18 мая 2011

Лично я бы использовал один из двух методов.

  1. Всегда храните его в одной и той же единице измерения
  2. Сохраняйте единицы измерения в отдельном поле, чтобы вы знали, является ли единица измерения CM или дюймами.

Я предпочитаю первый метод, поскольку он облегчает обработку.

0 голосов
/ 13 августа 2016

Мы можем сделать задачу очень просто.У нас есть только коэффициент для преобразования дюймов в см, а все вычисления и результат мы не сохранили в БД.Мы можем только умножить или разделить число на соотношение и получим результат.Так что если у вас см, нужно умножить соотношение и получить результат.Вы можете увидеть, как это работает, на примере, который я нашел за 2 минуты: http://inchpro.com/metric-system/convert-inches-to-centimeters Я думаю, вы знаете, что хранение всех значений в базе данных занимает много места.

0 голосов
/ 18 мая 2011

В зависимости от того, что вы собираетесь делать с этими значениями (нужно ли много агрегировать на уровне БД и т. Д.), Лучший способ убедиться в отсутствии кумулятивной ошибки округления - это сохранить в исходном блокеизмерения с этой единицей измерения (id) в отдельном столбце и иметь отдельную таблицу преобразования, которую вы используете для оперативных вычислений при сравнении, агрегировании и т. д.

Это не будет суперэффективный или удобный, однако: вам всегда нужно присоединиться к таблице преобразования, прежде чем выполнять какую-либо работу с сохраненными значениями.

0 голосов
/ 18 мая 2011

Не знаю, зачем вам нужна база данных, если вы не храните свои коэффициенты конверсии.

Невозможно восстановить метрические или имперские значения, потому что это просто числа

.в соответствии со степенью точности, которую вы хотите отобразить ....

...