как сохранить приблизительное число? (число слишком мало, чтобы его можно было измерить)

#sql #variables #types

#sql #переменные #типы

Вопрос:

У меня есть таблица, представляющая стандарты сплавов. Стандарт частично основан на химическом составе сплавов. Состав представлен в процентах. Процентное содержание определяется с помощью теста химического состава. Примерные данные.

Но иногда лаборатория не может измерить значение ниже определенного процента. Таким образом, они указывают, что элемент присутствует, но процент меньше, чем они могут измерить. Я был озадачен тем, как точно сохранить такое число в базе данных SQL. Я думал сохранить число со знаком минус. Конечно, ни один элемент не может иметь отрицательного состава, но я могу интерпретировать это как меньшее, чем указанное значение. Или вариант — добавить еще один столбец для каждого элемента!! Последний вариант мне действительно не нравится. Есть еще идеи? Это небольшая проблема, если подумать, но я думаю, что толпа всегда мудрее. У кого-нибудь может быть более аккуратное решение.


Обновлен вопрос:

Спасибо за все ответы.

  • Результаты тестов поступают из разных лабораторий, поэтому общей нижней границы нет.
  • Например, когда процентное содержание титана меньше <0,0004, число по-прежнему важно, только формула в этом случае будет немного отличаться.

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

Другая возможность, о которой я подумал, — сохранить его в виде строки. Есть еще идеи?

Ответ №1:

То, о чем вы говорите, — это контрольное значение. Это распространенный метод. В конце концов, строки на большинстве языков используют 0 в качестве контрольного значения в конце строки. Вы можете это сделать. Вам просто нужно найти число, которое имеет смысл и не используется ни для чего другого. Многие строковые функции вернут -1, чтобы указать, что того, что вы ищете, там нет.

0 может сработать, потому что, если элемента там нет, не должно быть даже записи. Вы также сталкиваетесь с проблемой, заключающейся в том, что его можно ошибочно принять за фактически означающее 0. -1 — другой вариант. Очевидно, что у него нет такой же проблемы.

Другой столбец, указывающий, измеримо ли количество или нет, также является приемлемым вариантом. Аргументы в пользу этого становятся более убедительными, если вам нужно хранить разные категории микроэлементов (например <1%, <0.1%, <0.01%, и т.д.). Сохранение отрицательного значения этих чисел кажется мне немного халтурным.

Комментарии:

1. «0» в качестве контрольного значения кажется разумным, потому что для многих вычислений это приемлемое значение.

Ответ №2:

Вы могли бы просто сохранить его как NULL , что означает, что значение существует, но не определено.

Любая арифметическая операция с a NULL приводит к NULL .

Деление на NULL безопасно.

NULL функции агрегирования игнорируются, поэтому запросы, подобные этим:

 SELECT  SUM(metal_percent), COUNT(metal_percent)
FROM    alloys
GROUP BY
        metal
  

выдаст вам сумму и количество фактических, определенных значений, не принимая во внимание незаполненные значения.

Комментарии:

1. Вы бы перепутали «NULL= не измерено» с «NULL= измерено, но ниже возможностей оборудования»

2. @MSalters : хороший момент. Но, как отмечалось выше, записи в этом случае даже не должны попадать в таблицу. Если структура таблицы этого не позволяет, то да, требуется другой столбец («причина отсутствия значения»)

3. @MSalters : в случае нуля мы могли бы перепутать «следов металла нет» и «следов металла, которые мы не смогли измерить».

Ответ №3:

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

Ответ №4:

Поскольку ограничения значений четко определены (не могут иметь отрицательного состава), я бы выбрал подход «отрицательное значение для обозначения меньшего, чем». До тех пор, пока использование таких контрольных значений достаточно документировано, оно должно быть достаточно простым в реализации и обслуживании.

Альтернативным, но похожим методом было бы добавить 100 к значениям, предполагая, что вы не можете получить больше 100%. Таким образом, <0.001 становится 100.001.

Ответ №5:

У меня была бы таблица, моделирующая сертификат в соотношении «один ко многим» с другой таблицей, хранящая значения для элементов. Тогда у меня все равно была бы таблица elements, содержащая значение в одном столбце и флаг (меньше) в виде отдельного столбца.

Черновик:

 create table CERTIFICATES
(
  PK_ID integer,
  NAME varchar(128)
)

create table ELEMENTS
(
  ELEMENT_ID varchar(2),
  CERTIFICATE_ID integer,
  CONCENTRATION number,
  MEASURABLE integer
)
  

В зависимости от используемого вами компонента database engine типы столбцов могут различаться.

Ответ №6:

Почему бы не добавить еще один столбец для хранения того, является ли это следовой суммой

Это позволит вам сохранить количество, которое в трассировке меньше слишком

Ответ №7:

Поскольку общего минимального порогового значения не существует, а значение NULL неприемлемо, самым простым решением сейчас является наличие столбца marker, который указывает, присутствует ли количество, поддающееся количественной оценке, или количество трассировки. Значение «Трассировка» указало бы любому, кто читает необработанные данные, что присутствовало только количество следов. Значение «Количество» будет указывать на то, что вам следует проверить столбец суммы, чтобы найти фактическое количество.

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

Ответ №8:

Похоже, что подойдет другое поле; назовите его ‘MinMeasurablePercent’.