Подтвердить что ты не робот

Должен ли я использовать тип данных SQL_Variant?

используя SQL Server 2005 с пакетом обновления 4 (SP4), и я создаю таблицу базы данных.

Вот таблица DDL

CREATE TABLE CPSync4D.ProjectProfilerOption
(
    ProjectProfilerOptionID     INT  IDENTITY(1,1) CONSTRAINT PK_ProjectProfilerOption_ProjectProfilerOptionID PRIMARY KEY 
   ,ProjectID                   INT  CONSTRAINT FK_ProjectProfilerOption_Project_ProjectID FOREIGN KEY(ProjectID) REFERENCES CPSync4D.Project(ProjectID) ON DELETE CASCADE
   ,ProfilerOptionID            TINYINT CONSTRAINT FK_ProjectProfilerOption_ProfilerOption_ProfilerOptionID  FOREIGN KEY(ProfilerOptionID) REFERENCES CPSync4D.ProfilerOption (ProfilerOptionID) 
   ,ProfilerOptionValue         sql_variant  NOT NULL   

)
Go

столбец profileroptionvalue может содержать строку длиной до 30 символов, целое или десятичное значения, например. значениями являются "ProfilerValueType" или 12.52 или 20 и т.д. (не более двух десятичных знаков и целочисленных значений меньше 100)

Должен ли я использовать sql_variant или varchar (30)...? Я никогда раньше не использовал sql_variant и не был уверен в том, что вы не используете его в плане дизайна базы данных.

Любые ошибки использования sql_variant... с .net-кодом

4b9b3361

ОТВЕТЫ

Ответ 1

10 причин для явного преобразования типов данных SQL Server

Как правило, вам следует избегать использования SQL-серверов sql_variant тип данных. Sql_variant, помимо того, что он является памятью, ограничен:

  • Варианты не могут быть частью первичного или внешнего ключа. (это не относится к SQL Server 2005. См. обновление ниже)
  • Варианты не могут быть частью вычисленного столбца.
  • Варианты не будут работать с LIKE в предложении WHERE.
  • Поставщики OLE DB и ODBC автоматически конвертируют варианты в nvarchar (4000) - ouch!

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

Я раньше не использовал sql_variant, но учитывая эти ограничения и последствия для производительности, я сначала рассмотрю альтернативы.

Следующее будет моим самым наименее предпочтительным решением

  • Просто создайте три разных столбца. 3 Различные типы данных (должны) означают 3 разных способа интерпретации как на стороне клиента, так и на стороне сервера.
  • Если это не вариант, используйте столбец VARCHAR, чтобы вы могли, по крайней мере, использовать операторы LIKE.
  • Используйте тип данных sql_variant.

Изменить Cudo на ta.speot.is

Варианты могут быть частью первичного внешнего ключа

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

Ответ 2

Я знаю, что мой ответ немного запоздалый, но создаваемая здесь таблица немного похожа на таблицу конфигурации приложения. В качестве альтернативы предложенным предложениям подумайте о том, чтобы не ограничивать себя 30 или даже 8000 символов. Позвольте также сделать его немного более самостоятельным и определяемым пользователем.

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

Ответ 3

Стоит отметить, что невозможно скопировать столбцы sql_variant неявно.

например. Создайте схему резервного копирования CPSync4D.ProjectProfilerOption под названием CPSync4D.ProjectProfilerOption_bkp

а затем

Insert into CPSync4D.ProjectProfilerOption_bkp
(
    ProjectProfilerOptionID
   ,ProjectID
   ,ProfilerOptionID
   ,ProfilerOptionValue 
)
SELECT 
    ProjectProfilerOptionID
   ,ProjectID
   ,ProfilerOptionID
   ,ProfilerOptionValue 
FROM CPSync4D.ProjectProfilerOption

Все значения для ProfilerOptionValue в таблице резервного копирования будут varchar

Обратите внимание: мне сказали, что SQL_Variant нельзя использовать в репликации, но это не правда. Конечно, это может быть сделано с SQL 2008 R2 (я использую), потому что я только что это сделал, но это может быть верно для более старых версий (у меня нет старых версий для проверки не может подтвердить или опровергнуть это).

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

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