Ir al contenido principal

Cómo cambiar los valores por defecto de una base de datos

Cuando creamos una nueva base de datos en SQL Server, ésta se configura con una serie de valores por defecto. Las preguntas que nos hacemos son:

  • ¿De dónde salen esos valores?
  • ¿Se pueden modificar?




La respuesta a la primera pregunta es muy sencilla: de la base de datos de sistema "model". Cuando instalamos una nueva instancia de SQL Server, ésta siempre contiene una serie de bases de datos de sistema por defecto, entre las que se encuentra model, que es usada por el servidor como plantilla para todas las bases de datos creadas en el servidor. Las nuevas bases de datos heredarán tanto los contenidos (funciones, procedimientos almacenados...) como las configuraciones de model.

Figura 1. Bases de datos de sistema de una instalación típica de SQL Server. Entre ella, model.

La segunda respuesta es "sí, se pueden modificar". Si alteramos la configuración de model, sus valores serán heredados como valores por defecto (siempre podemos cambiar los valores de la nueva base de datos en el momento de la creación, ya sea mediante el Management Studio o mediante script) por cualquier base de datos que creemos a partir de ese momento. Así pues, volviendo a nuestro post anterior, podríamos cambiar los valores iniciales de autocrecimiento que se le asignan a los ficheros de la nueva base de datos, evitando así el generalmente insuficiente valor de 1MB para el fichero de datos.

Figura 2. La nueva base de datos se crea con un valor de 10MB para el autocrecimiento del fichero de datos. Este valor lo habremos cambiado previamente en las propiedades de model.

Comentarios

Entradas populares de este blog

Aprendiendo a usar LEFT OUTER JOIN

En esta entrada pretendemos explicar los diferentes resultados obtenidos por distintas construcciones de consultas que, aparentemente, deberían producir el mismo conjunto de resultados. Así, veremos las diferencias entre filtrar los resultados de una query en la unión (Join) mediante condiciones ON y mediante cláusulas WHERE.

Variantes del SELECT COUNT con DISTINCT

Seguramente, muchos de vosotros habréis usado en innumerables ocasiones la función de T-SQL COUNT , que no hace sino devolver un número de registros: de una tabla, de un conjunto de resultados, etc... En una de sus aplicaciones, combinado con el DISTINCT -uno de los dos argumentos que admite- COUNT nos devuelve el número de valores únicos no nulos de la tabla o conjunto de resultados que estemos consultando. Pero ¡ojo! Cuidado con la sintaxis , o podemos obtener el valor equivocado sin darnos cuenta. No es lo mismo: SELECT COUNT (DISTINCT NombreCampo) FROM NombreTabla que: SELECT COUNT(*), DISTINCT NombreCampo FROM NombreTabla

Script para obtener el tamaño de todas las tablas de la base de datos

En algunas ocasiones podemos vernos con la necesidad de conocer qué tablas de nuestra base de datos están ocupando más espacio en disco. Por ejemplo, si disponemos de SQL Server Express , cuyas bases de datos están limitadas a 4GB o 10GB, según la versión que estemos usando -4, hasta 2005; 10, a partir de 2008-, aparte de usar las opciones de comprimir la base de datos, poner el log en el modo simple de recuperación o ajustar las políticas de crecimiento automático de nuestros ficheros, podemos necesitar averiguar qué tablas crecen más para tomar las decisiones oportunas.