texto - ¿Debo usar el tipo de datos SQL_Variant?

tipo long en sql server

Question

utilizando SQL Server 2005 con SP4 y estoy diseñando una tabla de base de datos.

Aquí está la mesa 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

La columna profileroptionvalue puede contener una cadena de hasta 30 caracteres, valores enteros o decimales, por ejemplo, los valores son "ProfilerValueType", o 12.52 o 20, etc. (no más de dos decimales y los valores enteros son menos de 100)

¿Debo usar sql_variant o varchar (30) ...? Nunca usé sql_variant antes y no estoy seguro de ninguna implicación de no usarlo en términos de diseño de base de datos.

Cualquier inconveniente de usar sql_variant ... con código .net

Answer 1

Sé que mi respuesta es un poco tarde, pero la tabla que se hace aquí parece un poco como una tabla de configuración de la aplicación. Como alternativa a las sugerencias dadas, pensemos en no limitarnos a 30 o incluso 8000 caracteres. También hagámoslo un poco más autónomo y definible por el usuario.

Con esos pensamientos en mente, ¿por qué no guardar la información del "perfil" como un tipo de datos XML que incluso permitiría múltiples niveles de configuración? Es probable que ya no necesite más columnas como ProfilerOptionID y podría obtener esto en una simple tabla de control.

Answer 2

Vale la pena señalar que no es posible copiar implícitamente la columna sql_variant.

por ejemplo, crear un esquema de copia de seguridad de CPSync4D.ProjectProfilerOption llamado CPSync4D.ProjectProfilerOption_bkp

y entonces

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

Todos los valores para ProfilerOptionValue en la tabla de respaldo serán varchar

También tenga en cuenta: me han dicho que SQL_Variant no se puede usar en la replicación, pero esto no es cierto . Ciertamente, se puede hacer con SQL 2008 R2 (que estoy usando) porque lo acabo de hacer, pero esto puede haber sido cierto para versiones anteriores (no tengo ninguna versión anterior con la que pueda verificar, por lo que no puedo confirmar ni negar esto).

Sin embargo, lo que sí es cierto es que si replica una tabla con una variante de SQL y tiene una gran cantidad de datos y luego algo sale mal y necesita corregir los datos manualmente, entonces es posible que tenga una pieza desagradable de SQL para escribir. . Esto se debe a que al copiar los datos no se puede copiar con varios tipos de bases en la misma declaración de copia. Supongo que la replicación no tiene este problema porque no copia varias filas (con la excepción obvia de la instantánea pero que utiliza bcp).

PD. Me doy cuenta de que este es un post antiguo, pero lo pongo aquí para otros futuros visitantes con la misma pregunta.

Answer 3

10 razones para convertir explícitamente los tipos de datos de SQL Server

Como regla general, debe evitar el uso del tipo de datos sql_variant de SQL Server. Además de ser un cerdo de memoria, sql_variant es limitado:

• Las variantes no pueden ser parte de una clave primaria o externa. (esto no se cumple a partir de SQL Server 2005. Ver actualización a continuación)
• Las variantes no pueden ser parte de una columna calculada.
• Las variantes no funcionarán con LIKE en una cláusula WHERE.
• Los proveedores OLE DB y ODBC convierten automáticamente las variantes a nvarchar (4000) - ¡ouch!

Para evitar problemas, siempre convierta explícitamente los tipos de datos sql_variant a medida que los usa. Utilice cualquier método que desee, pero no intente trabajar con un tipo de datos sql_variant no convertido.

No he usado sql_variant antes, pero teniendo en cuenta estas restricciones e implicaciones de rendimiento, primero buscaría alternativas.

A continuación sería mi solución más preferida a menos

• Simplemente crea tres columnas diferentes. 3 Los diferentes tipos de datos (deberían) significan 3 formas diferentes de interpretarlos tanto en el lado del cliente como en el del servidor.
• Si esa no es una opción, use una columna VARCHAR para que al menos pueda usar las declaraciones LIKE .
• Utilice el tipo de datos sql_variant .

Editar Cudo''s a ta.speot.is

Las variantes pueden ser parte de un primario de clave externa.

Una clave única, primaria o externa puede incluir columnas de tipo sql_variant, pero la longitud total de los valores de datos que conforman la clave de una fila específica no debe ser mayor que la longitud máxima de un índice. Esto es 900 bytes