2010-10-07 22 views
6

¿Alguien tiene una idea de cuál es la mejor práctica para almacenar un tipo de datos desconocido en una tabla? Básicamente, necesitaría almacenar tipos como bit, smallint, int, real y nvarchar en la misma columna de "valor", para su posterior interpretación por una aplicación .NET.Almacenamiento de tipo de datos desconocido en la base de datos del servidor MS SQL

Estaba tratando de lograr la mejor solución posible para no comprometer el rendimiento o el crecimiento de la base de datos.

¿Alguna sugerencia?

¡Gracias de antemano!

+2

Si va por la ruta EAV, le sugiero que lea un poco acerca de por qué esta es una mala estructura de datos en una base de datos relacional. ver: http: //www.simple-talk.com/opinion/opinion-pieces/bad-carma/ Si realmente necesita hacer esto, podría considerar una solución nosql en su lugar. – HLGEM

Respuesta

11

Varchar (max) es probablemente la forma más fácil de hacerlo.

sql_variant se diseñó para este propósito para que pueda usarlo, pero lea la entrada de Books Online para asegurarse de que hará lo que desee.

http://msdn.microsoft.com/en-us/library/ms181071.aspx

+0

No me gusta mucho la solución varchar, pero definitivamente voy a probar la sql_variant y probar el rendimiento de conversión. ¡Si es aceptable, entonces va a ser así! Gracias por su sugerencia. –

+0

+1 - es bueno aprender cosas – Brad

+3

+1 para sql_variant. ¡Primero he oído hablar de eso! –

0

Almacenarlo como varchar (o nvarchar). Esto manejará todos los tipos. Deberá determinar la duración para hacerlo según lo que sabe sobre sus datos.

+0

Gracias por la sugerencia. pero estaba evitando la solución varchar (nvarchar) debido al crecimiento de la base de datos y al rendimiento de las conversiones. –

+2

No puedes tener tu pastel y comértelo también; si desea almacenar diferentes tipos en la misma columna, ¿qué otro *** tipo de *** usaría? String/varchar es el tipo ** solo ** que puede representar todos los otros tipos (excepto binario o curso). – Brad

+0

** Nota: Acabo de leer acerca del tipo 'sql_varient' y eso parece una solución viable, pero me pregunto cómo reaccionará .NET para convertir los objetos en esa columna al tipo que desee. – Brad

1

Tal como lo veo, sólo tiene dos opciones:

Usted es el objeto tendrá que ser guardado como una especie de cadena. Esa cadena podría ser una cadena sin formato o XML. Si lo "serializa" como XML y lo almacena en la base de datos, nuevamente, puede elegir nvarchar o XML. Me gustaría señalar que "serializarlo" inflará los datos. Si puede determinar razonablemente el tipo de datos basado en otra columna que puede estar extrayendo al mismo tiempo, entonces le sugiero que lo ponga como una cadena.

+1

La solución parece correcta, pero ¿no sería la cadena serializada o Xml mucho más grande (en bytes) que los datos base en sí? –

+0

@Guilherme, sí, por eso dije ''señalaría que' serializarlo 'inflaría los datos'. Pero si no tienes otra forma de determinar el tipo de datos real, esto puede ser un retroceso. – Brad

0

probar esto:

YourTableName 
...more columns... 
ColType char(1)  --B=bit, S=smallint, I=int, R=real, n=nvarchar, you can FK to a table to store these or just check constraint them 
Col  nvarchar(x) --where x is large enought to hold your longest string or other value 
...more columns... 

en la aplicación .Net, leído en ColType y convertir la columna de la Col a ese tipo. Al guardar, SQL Server convertirá los tipos de datos nativos a nvarchar() por usted.

+0

Gracias por la sugerencia. pero estaba evitando la solución varchar (nvarchar) debido al crecimiento de la base de datos y al rendimiento de las conversiones. –

+0

ha, su respuesta seleccionada: "sql_variant" ¿cómo crees que funcionará mejor? –

1

no estoy seguro de lo que entendemos por 'tipo desconocido'. Si quiere decir que un valor es exactamente uno de un número limitado de tipos posibles, entonces usaría una tabla de una sola columna, fuertemente tipada, para cada tipo posible y una tabla de "superclase" para indicarle qué tabla buscar.

+0

De hecho, esa es precisamente mi solución actual. Pero estaba tratando de mejorar los cruces de tablas y seleccionar consultas, al tener una sola tabla de "valores". Si no hay otra opción, esa es la forma en que se mantendrá. –

Cuestiones relacionadas