Los datos de referencia son una parte esencial de cualquier base de datos de SQL Server. Sin embargo, cuando varios desarrolladores y probadores participan en la adición de datos de referencia, puede haber inconsistencias y conflictos. En este artículo, exploraremos las mejores prácticas para gestionar datos de referencia en SQL Server y garantizar una base de datos consistente y confiable.

Replicar el escenario del problema

Antes de adentrarnos en las mejores prácticas, vamos a configurar una base de datos de muestra con datos de referencia para replicar el problema. Crearemos una base de datos llamada CarsSample y la poblaremos con tablas de referencia como CarMake y CarType.

Agregar tablas de referencia

Para agregar tablas de referencia, podemos utilizar el Explorador de objetos de SQL Server y ejecutar los scripts SQL necesarios. Las tablas CarMake y CarType servirán como nuestras tablas de referencia, y la tabla Car se actualizará para incluir claves externas que hagan referencia a estas tablas.

CREATE TABLE [dbo].[CarMake]
(
   [CarMakeId] INT NOT NULL IDENTITY(1,1),
   [Name] VARCHAR(40),
   [Detail] VARCHAR(200),
   CONSTRAINT [PK_CarMake] PRIMARY KEY CLUSTERED ([CarMakeId])
)

CREATE TABLE [dbo].[CarType]
(
   [CarTypeId] INT NOT NULL IDENTITY(1,1),
   [Name] VARCHAR(40),
   [Detail] VARCHAR(200),
   CONSTRAINT [PK_CarType] PRIMARY KEY CLUSTERED ([CarTypeId])
)

CREATE TABLE [dbo].[Car] (
    [CarId]   INT          IDENTITY (1, 1) NOT NULL,
    [CarMakeId]    INT NULL,
    [RegYear] INT          NULL,
    [CarTypeId]    INT NULL,
    CONSTRAINT [PK_Car] PRIMARY KEY CLUSTERED ([CarId] ASC), 
    CONSTRAINT [FK_Car_CarMake] FOREIGN KEY ([CarMakeId]) REFERENCES [CarMake]([CarMakeId]), 
    CONSTRAINT [FK_Car_CarType] FOREIGN KEY ([CarTypeId]) REFERENCES [CarType]([CarTypeId])
)

Estilo de desarrollo de base de datos declarativo

SQL Server Data Tools (SSDT) ofrece un estilo de desarrollo de base de datos declarativo, que proporciona varios beneficios, incluida la implementación consistente de la base de datos. Cuando se trata de agregar datos de referencia, podemos utilizar scripts de datos que se ejecutan como scripts posteriores a la implementación durante el proceso de publicación o depuración.

De forma predeterminada, los scripts de datos utilizados para poblar las tablas de referencia no son repetibles. Sin embargo, para evitar conflictos e inconsistencias, debemos hacer que estos scripts sean repetibles.

Solución potencial

Una posible solución al problema de la sobreescritura de datos de referencia es modificar los scripts de datos para que solo inserten datos si aún no existen. De esta manera, los cambios realizados por un desarrollador no serán sobrescritos por otro desarrollador.

Por ejemplo, en lugar de utilizar la opción de implementación “Siempre volver a crear la base de datos”, podemos modificar el script de datos para la tabla CarType de la siguiente manera:

SET IDENTITY_INSERT [dbo].[CarType] ON

IF NOT EXISTS (SELECT * FROM CarType WHERE CarTypeId=1 and Name='Estate') 
INSERT INTO [dbo].[CarType] ([CarTypeId], [Name], [Detail]) VALUES (1, N'Estate', NULL)

IF NOT EXISTS (SELECT * FROM CarType WHERE CarTypeId=2 and Name='SUV') 
INSERT INTO [dbo].[CarType] ([CarTypeId], [Name], [Detail]) VALUES (2, N'SUV', NULL)

IF NOT EXISTS (SELECT * FROM CarType WHERE CarTypeId=3 and Name='Saloon') 
INSERT INTO [dbo].[CarType] ([CarTypeId], [Name], [Detail]) VALUES (3, N'Saloon', NULL)

IF NOT EXISTS (SELECT * FROM CarType WHERE CarTypeId=4 and Name='Hatchback') 
INSERT INTO [dbo].[CarType] ([CarTypeId], [Name], [Detail]) VALUES (4, N'Hatchback', NULL)

IF NOT EXISTS (SELECT * FROM CarType WHERE CarTypeId=5 and Name='MPV') 
INSERT INTO [dbo].[CarType] ([CarTypeId], [Name], [Detail]) VALUES (5, N'MPV', NULL)

SET IDENTITY_INSERT [dbo].[CarType] OFF

Al utilizar este enfoque, el script de datos solo insertará datos si aún no existen, asegurando que los cambios realizados por un desarrollador se conserven.

Conclusión

La gestión de datos de referencia en SQL Server requiere una cuidadosa consideración para evitar conflictos e inconsistencias. Siguiendo las mejores prácticas, como utilizar scripts de datos repetibles y evitar la opción de implementación “Siempre volver a crear la base de datos”, podemos garantizar una base de datos consistente y confiable.