Cual es el uso en la práctica de los FILES y los FILEGROUPS

[usuariobaneado]

HOla a todos...

Estaba leyendo un poco sobre los archivos físicos de las bases de datos. Como ya todos sabemos, el archivo de datos por default es un *.mdf y el de log *.ldf Luego si yo quiero agregar más archivos de datos serán *.ndf

Corrijanme si estoy equivocado, entiendo que teniendo más archivos yo puedo poner el mdf en el disco C, y un ndf en el disco D, pienso que ese es el fin

Ahora, el filegrop por defecto es PRIMARY, pero puedo crear otro filegroup SECONDARY, y por ejemplo meter el archivo mdf en el PRIMARY y crear un ndf y meterlo en el filegroup SECONDARY, en definitiva, crear n archivos y filegroups y meter cada archivo en un filegropu respectivo.

Mis preguntas son, para que sirve hacer esto? Cual es la mejor estrategia?

[iislas]

Todo lo que has dicho, es correcto, para eso sirven los MDF, LDF y NDF, incluyendo los FILEGROUPS

[usuariobaneado]

Iniciado por iislas

Todo lo que has dicho, es correcto, para eso sirven los MDF, LDF y NDF, incluyendo los FILEGROUPS

Que tal islas... gracias por responder. Pero me quedan algunas dudas sueltas, y es para que sirve, como les puedo sacar provecho

[iislas]

Para obtener una MAYOR VELOCIDAD de acceso, o bien, podrias crear un FILEGROUP que se llamara RH, donde guardaras todas las tablas de RECURSOS (IN)HUMANOS...............

[usuariobaneado]

Bien, ante ese planteamiento tengo una duda:

supongamos que en un filegroup guardo las tablas de recursos humanos, pero por ejemplo, en la tabla RolPago, donde se guardarán los registros de los pagos a empleados, debería de tener un campo foraneo con el código del empleado. Entonces al sacar un reporte de pagos debería de irme a la tabla de Personas para sacar el nombre del empleado. Y la tabla de Personas están proveedores, clientes, empleados, etc. Esta tabla pertenecería a otra "area" por decirlo así. Entonces al hacer el select, hay un join, y los datos estarían en dos filegroup diferentes. Supongo que en ese caso se perdería performance, invalidando el objetivo principal del filegroup.

Eso es algo que se me ocurrió, que puedes opinar al respecto

[Mithrandir]

Una ventaja es que puedes restaurar/respaldar a nivel de filegroup, cosa que puede ser útil en caso de DB grandes.

Otra cosa más es en caso de que escasee el espacio, o que quieras hiperoptimizar el acceso a tu DB. En un filegroup usas un disco rápido para los datos de acceso frecuente y en un disco lento los datos de poco movimiento (históricos). O bien, en un RAID optimizado para escrituras los datos de movimiento y en un RAID especializado en lectura los datos de poco movimiento.

Esta tabla pertenecería a otra "area" por decirlo así. Entonces al hacer el select, hay un join, y los datos estarían en dos filegroup diferentes. Supongo que en ese caso se perdería performance, invalidando el objetivo principal del filegroup.

Eso no afecta a los filegroups. Eso se da en el caso de diferentes DB, pues se hacen comprobaciones de collation y no tienes monerías como integridad referencial entre ellas.

[usuariobaneado]

Gracias Mith...

Con respecto a los respaldos y restauraciones. No valdría tener la tabla de rol de pago y la tabla de empleados en filegroups diferentes, ya que al restaurar, podría perder integridad entre las dos tablas

[Mithrandir]

Sí, es un riesgo, pero es algo que asumen con tal de tener posibilidades de reslapdar en DB muy grandes.

Su uso hasta donde yo conozco suele ser para separar volúmenes de datos sin movimiento (históricos), por lo que el riesgo que comentas es muy bajo.