Как мне смоделировать поле, которое может содержать как числовые, так и строковые значения в SQL Server 2005?

Question

У меня есть новая таблица базы данных, которую мне нужно создать ...
Логически он содержит ID, name и "value".
Это поле значения может быть числовым или символьной строкой по своей природе.

Я не думаю, что хочу просто сделать поле varchar, потому что я также хочу иметь возможность запрашивать с фильтрами типа WHERE value > 0.5 и такими.

Как лучше всего смоделировать эту концепцию в SQL Server 2005?

EDIT: Я не против создания здесь нескольких полей (одно для чисел, одно для не-чисел), но, поскольку они все на самом деле одинаковы, я не был уверен, что это отличная идея.
Я думаю, я мог бы создать отдельные поля, а затем иметь представление, которое объединяет их в один логический столбец.

Есть мнения по этому поводу?

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

Answer 1

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

Answer 2

Ваша проблема со смешанными данными может заключаться в том, как Sql 2005 сортирует текстовые данные. Это не «естественный» сорт.

Если у вас есть поле varchar, и вы делаете:

where value > '20.5'

Значения типа «5» будут в вашем результате (как в случае сортировки на основе символов «5» следует после «20,5»)

Вам будет лучше с отдельными колонками для хранения.

Используйте Coalesce, чтобы объединить их в один столбец, если они вам нужны в ваших результатах:

select [ID], [Name], Coalesce( [value_str], [value_num] )
from [tablename]

Answer 3

Вы можете рассмотреть возможность использования двух столбцов, одного «строка» и одного «числовой» (какие бы варианты ни были уместны) со столбцом «строка» NOT NULL и столбцом «число», допускающим значения NULL. При вставке значения всегда заполняйте столбец «строка» независимо от типа, однако, если значение является числовым, ТАКЖЕ сохраняйте его в столбце «числовой». Теперь у вас есть встроенный индикатор типа (если столбец «числовой» заполнен, то он числовой, если не строка), вы всегда можете просто извлечь значение для отображения из столбца «строковый» и использовать «числовое» значение в расчетах или для правильной числовой сортировки / сравнения по мере необходимости. Вы всегда можете добавить третий столбец, указывающий тип значения, но такой подход устраняет необходимость в этом. Обратите внимание, что вы можете рассмотреть возможность сохранения числовых и строковых значений, используя набор триггеров INSERT и UPDATE.

Answer 4

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

Зависит от источника данных. Если вы получаете данные от пользователей (или какой-либо другой системы) в произвольной форме и вам не важно, какой это тип данных, тогда лучший способ их хранения - это наиболее общий способ (varchar и т. Д.) , Если входящие данные более структурированы, и вы заботитесь об этой структуре, то имеет смысл сохранить эту структуру в базе данных, используя отдельные поля.

С точки зрения SELECT это не имеет большого значения; Вы можете сохранить его в любом случае и прочитать как ту же схему. Как только вы попадаете в фильтры (как вы упоминаете), все становится немного более волосатым, но все же легко выполнимым. Тем не менее, вы не указываете, нужно ли вам иметь возможность обновлять эти данные, и если да, то нужно ли проводить принудительную проверку данных.

Судя по его звукам, вам нужно выполнять различные типы поиска в зависимости от "типа" сохраняемого значения. Поэтому может иметь смысл добавить поле Тип, чтобы любые фильтры можно было быстро ограничить типом значений, которые вас интересуют. Заметьте, под Type я имею в виду более логичную область применения Type; не фактический тип данных, который хранится.

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

Answer 5

Я не думаю, что вы сможете обойтись, используя VARCHAR или NVARCHAR в качестве типа данных. Со смешанными данными, которые вы описываете, вам придется проверить значение, когда вы извлекаете поле из базы данных, и выполнить соответствующие CAST или CONVERT в зависимости от типа данных.

Answer 6

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

Альтернативой может быть наличие 2 или 3 столбцов вместо одного столбца значений. Может иметь три столбца: value_type (перечисление между «number» и «string»), number_value, string_value. Тогда вы можете восстановить этот запрос, чтобы он был

WHERE value_type = 'number' AND number_value > 0.5

Answer 7

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

Answer 8

две колонки.

Table: (ValueLable as char(x), Value as numerica(p,s))

Answer 9

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