SQL Server 2008, unirse o no unirse?

Question

Solo una pequeña pregunta con respecto a las uniones. Tengo una tabla con alrededor de 30 campos y estaba pensando en hacer una segunda tabla para almacenar 10 de esos campos. Luego me gustaría unirme a ellos con los datos principales. Los 10 campos que estaba planeando almacenar en una segunda tabla no se consultan directamente, solo son algunas configuraciones para los datos en la primera tabla.

Algo así como:

Table 1 
Id 
Data1 
Data2 
Data3 
etc ... 

Table 2 
Id (same id as table one) 
Settings1 
Settings2 
Settings3 

¿Es esta una mala solución? ¿Debería usar una sola tabla? ¿Cuánto impacto en el rendimiento tiene? Todas las entradas en la tabla 1 también tendrían una entrada en la tabla 2.

Pequeña actualización está en orden. La mayoría de los campos de Datos son del tipo varchar y 2 de ellos son del tipo texto. ¿Cómo se trata la indexación? Mi plan es indexar 2 campos de datos, correo electrónico (varchar 50) y autor (varchar 20). Y sí, todos los registros en la Tabla 1 tendrán un registro en la Tabla 2. La mayoría de los campos de configuración son del tipo de bit, alrededor del 80%. El resto es una mezcla entre int y varchar. Los varchars pueden ser nulos.

Answer 1

Esto se conoce como vertical partitioning, y es una estrategia legítima. Puede hacer esto por los siguientes motivos:

• Si se accede o cambia a ciertas columnas con mucha más frecuencia que otras.
• Si desea almacenar algunas de las columnas en un conjunto de medios de almacenamiento y los demás en otro.
• Si tiene desencadenadores extensos que no necesitan ejecutarse en respuesta a actualizaciones en algunas de las columnas.

Es probable que se produzca un pequeño golpe de rendimiento al acceder a través de JOIN, pero el rendimiento puede aumentar en los casos en que solo necesite acceder a una u otra de las tablas de componentes.

Answer 2

¿Las tablas 1 y 2 tienen el mismo número de filas? Es decir, ¿cada fila en la tabla 1 tiene una fila correspondiente en la tabla 2 y viceversa? Si es así, una combinación innecesaria, puede filtrar las columnas que desee con una selección.

Una unión solo sería útil si tiene filas en la tabla 2 que corresponden con más de 1 fila en la tabla 2, p. una fila de clasificaciones que se aplican a múltiples filas de datos.

Editar: Mis preguntas ya están respondidas por la edición en la publicación original. Yo diría que una unión no es necesaria aquí y solo tendría un impacto adverso en el rendimiento.

Answer 3

Esto dependerá de si cada fila en la tabla 1 necesita una fila en la tabla 2 (¿Todas las filas tienen configuraciones) y cuántas de estas configuraciones son NULAS regularmente?

Si todos los ajustes (o la mayoría de ellos) se usan y utilizan con regularidad, recomiendo colocarlos en la misma tabla.

Además, el número de columnas a las que se refiere no es extremo, por lo que una sola tabla, evitando las combinaciones si se usan campos, es lo que recomendaría.

Answer 4

Si los datos pertenecen juntos, mantenlos juntos.

Si su configuración no tiene sentido sin los datos de la tabla principal y corresponde uno a uno a ellos (es decir, una fila en la tabla 1 tiene exactamente una fila es la tabla 2), debe agregarlos a la tabla principal.

Answer 5

solución No es malo, pero hay que considerar siguientes cosas:

1. tabla que contiene un mayor número de columnas y muchos de ellos almacena nula es una señal para crear otra tabla
2. Si desea guardar los ajustes, cree un diseño que pueda almacenar cualquier cantidad de configuraciones sin almacenar nulo, por ejemplo, cree una tabla que tenga campos, primarykeyid, foreignkeyid, settingname, settingvalue. Tenga en cuenta que en 2, está almacenando el encabezado del nombre de la configuración, pero si utiliza int o tiny int obtendrá un rendimiento mucho mejor.

Esperanza esto ayuda

Answer 6

El tamaño de los campos, la frecuencia y el tipo de uso (selecciona, actualizaciones, etc.) y el tamaño de las tablas (filas) todos los asuntos, además de los te formas índice eso.

En general, este no es un mal diseño si el subconjunto de datos en una tabla se ve comúnmente (por ejemplo, en una lista) y el segundo subconjunto se ve/edita con mucha menos frecuencia y/o contiene campos muy grandes (como varchar (max)).

Sin embargo, si los datos siempre se ven juntos, probablemente este no sea el camino a seguir. Entonces, si tiene que leer esas configuraciones en la segunda tabla cada vez que lee la primera tabla, no tome este camino.

Actualización: Teniendo en cuenta su índice y el hecho de que casi todas las configuraciones tienen un tamaño fijo (bit), simplemente lo convertiría en una sola tabla. Si necesita una consulta de subconjunto sin toda la tabla, es posible que desee considerar un índice de cobertura en lugar de dividir la tabla.

Answer 7

Si va a consultar regularmente la tabla de configuraciones al mismo tiempo que la tabla de datos, las querrá como una sola tabla. Si consulta cada conjunto de datos por separado, puede ser útil mantenerlos separados.

Hay un golpe de rendimiento en cada unión, pero también querrás ver cómo estás usando las tablas. Si los necesita al mismo tiempo, es mejor mantenerlos juntos, de lo contrario, puede romperlos siempre y cuando no planee usarlos al mismo tiempo con frecuencia en el futuro.