multiple - SQL Server 2008, ¿unirse o no unirse?

sql server like multiple

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 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

¿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, por ejemplo, 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 2

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 todas las configuraciones (o la mayoría de ellas) se usan y usan regularmente, recomendaría colocarlas en la misma tabla.

Además, la cantidad de columnas a las que se refiere no es extrema, por lo que recomiendo una sola tabla, evitando las combinaciones si se usan campos.

Answer 3

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

• Si se accede a ciertas columnas o se cambian 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 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), entonces debe agregarlos a la tabla principal.

Answer 5

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 quieres 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.

Answer 6

Tu solución no está mal, pero considera seguir cosas:

1. La tabla que contiene más columnas y muchas de ellas almacena nulas es un signo para crear otra tabla
2. Si desea almacenar configuraciones, cree un diseño que pueda almacenar cualquier cantidad de configuraciones sin almacenar valores nulos, 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 usa int o tiny int obtendrá un rendimiento mucho mejor.

Espero que esto ayude

Answer 7

El tamaño de los campos, la frecuencia y el tipo de uso (selecciones, actualizaciones, etc.) y el tamaño de las tablas (filas) son importantes, además de las formas en que lo indexa.

En general, este no es un mal diseño si el subconjunto de datos en una tabla se ve comúnmente (digamos 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.