Как хранить меньше, равно и больше, чем в базе данных

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

Пример:

PatientId: 123 Частота мутаций: ‹3%

PatientId: 999 Частота мутаций: 3%

PatientId: 456 Частота мутаций: 10%

Мне нужно иметь возможность сортировать и фильтровать данные. Частота мутаций ‹3% лучше, чем 3%

Как я могу решить это?

спасибо за помощь


person cafenervosa    schedule 30.11.2009    source источник
comment
Является ли уровень мутаций 4,691% лучше, чем ‹4,7%?   -  person Mark Byers    schedule 01.12.2009
comment
Я бы сохранил то, что вы используете для расчета скорости мутации, чтобы учесть изменения в рейтинге.   -  person OMG Ponies    schedule 01.12.2009
comment
используется ‹4,7 %, поскольку точность измерения невысока, на границах она не 0, а слишком низкая, чтобы прикрепить к ней число в приведенном вами образце, вы измерите 4,691, но сэкономите ‹4,7 %, если это наименьшее измеряемое значение, но 0 также является значением.   -  person cafenervosa    schedule 01.12.2009
comment
Да, но как бы вы это сортировали? Вопрос Марка касался вашего метода сортировки: лучше ли 4,691, чем ‹4,7? Вы хотите сказать, что конвертируете 4,691 в ‹4,7? Это означает, что 4,691 будет таким же, как ‹4,7?   -  person CPerkins    schedule 01.12.2009


Ответы (4)


Как насчет добавления третьего столбца для уточнения int?

0 = меньше
1 = меньше или равно
2 = равно
3 = больше или равно
4 = больше

person tinkertime    schedule 30.11.2009
comment
Если бы вы сделали это, но изменили порядок на 0 = меньше, 1 = меньше или равно, 2 = равно, 3 = больше или равно и 4 = больше, вы могли бы сделать заказ на этом с другим столбцом, чтобы получить желаемые результаты. - person StrixVaria; 01.12.2009
comment
В мире математической оптимизации принято замечать, что A › B ‹=› -B ‹ -A, так что вы можете даже оставить только 3 значения в столбцах и покрыть все случаи: ‹, ‹=, =. - person Mathias; 01.12.2009
comment
или вы можете просто использовать фактические ‹ › ‹=, =, ›= и сохранить их как текст (varcahr), если вы правильно экранируете эти значения. Создавать гораздо меньше путаницы, чем пытаться вспомнить, чему равно 3 и чему равно 4. ИЗБЕГАЙТЕ создания новых соглашений, если достаточно старых. - person konung; 01.12.2009

Самый простой способ — использовать предопределенные значения для этих случаев, например, здесь значение 3,0 означает 3 %, а 2,99 означает "менее 3 %".

Поскольку эти значения "Меньше чем" и "Больше чем" обычно применяются только к концам диапазона, такое соглашение позволяет обрабатывать всю фильтрацию и упорядочение с одним значением поля стандартным способом. Основным недостатком этого подхода является то, что он предполагает жесткое кодирование этих предельных значений на уровне приложения для целей отображения и т.п.

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

person mjv    schedule 30.11.2009
comment
А разве такие ограничения не должны быть в приложении? База данных предназначена для хранения данных. Бизнес-логика применяет правила к данным, а пользовательский интерфейс показывает данные пользователю в понятном формате. - person Corin; 01.12.2009
comment
@Corin, да, такие ограничения и обычно неявная информация о масштабе и т. д. должны обрабатываться на уровне приложения. - person mjv; 01.12.2009

Если вы не хотите разбивать данные на 3 поля, такие как less_equal_more(varchar) (‹.=, > или текстовые эквиваленты), измерение (deciaml) (3,5 или любой другой уровень точности) и unit_of_measurment(varchar) (например, процент или абсолютный в милях или метрах - что угодно) - вы должны хранить в varchar. Но я бы разбил ваши данные - это облегчит ваши поисковые запросы. Работа с полнотекстовым поиском (который вам придется делать, если вы храните все в одном поле) довольно сложна по сравнению с запросами, которые вам пришлось бы выполнять, если вы разбиваете свои данные.

person konung    schedule 30.11.2009

Я бы предложил хранить ваши данные в виде интервалов, т.е. ‹3% станет [0,3], 3% станет [3,3] и так далее. Это может занять 4 столбца в вашей базе данных, по одному для каждой из конечных точек и один для обозначения того, открыт или закрыт интервал в каждой конечной точке. Сохраняйте числовые данные числовыми, чтобы вы могли выполнять над ними арифметические операции, кодировать значения «открыто» и «закрыто» так, как это лучше всего соответствует вашим требованиям к доступу и манипулированию.

person High Performance Mark    schedule 01.12.2009