“Escucho y olvido. Veo y recuerdo. Hago y entiendo.” – Confucio.

Como desarrolladores de SQL Server, a menudo nos encontramos en situaciones en las que necesitamos más funciones y herramientas para desarrollar y depurar de manera eficiente procedimientos almacenados, funciones, lotes e informes ad-hoc. Saltar entre ventanas, sesiones y herramientas puede ser lento e ineficiente.

Consideremos un escenario en el que queremos ver todas las columnas de una tabla en el Explorador de Objetos. Desafortunadamente, no podemos ver si una columna tiene la propiedad de identidad establecida y los valores de inicio e incremento. Aunque podemos generar la declaración de creación de tabla para ver esta información, implica pasos adicionales y tiempo.

Ahora, comparemos dos declaraciones de creación de tabla:

Primer formato, generado por el Analizador de Consultas de SQL:

CREATE TABLE [Orders] (
[OrderID] [int] IDENTITY (1, 1) NOT NULL ,
[CustomerID] [nchar] (5) COLLATE Cyrillic_General_CI_AS NULL ,
[EmployeeID] [int] NULL ,
[OrderDate] [datetime] NULL ,
[RequiredDate] [datetime] NULL ,
[ShippedDate] [datetime] NULL ,
[ShipVia] [int] NULL ,
[Freight] [money] NULL CONSTRAINT [DF_Orders_Freight] DEFAULT (0),
[ShipName] [nvarchar] (40) COLLATE Cyrillic_General_CI_AS NULL ,
[ShipAddress] [nvarchar] (60) COLLATE Cyrillic_General_CI_AS NULL ,
[ShipCity] [nvarchar] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[ShipRegion] [nvarchar] (15) COLLATE Cyrillic_General_CI_AS NULL ,
[ShipPostalCode] [nvarchar] (10) COLLATE Cyrillic_General_CI_AS NULL ,
[ShipCountry] [nvarchar] (15) COLLATE Cyrillic_General_CI_AS NULL
)
GO

Segundo formato, generado por procedimiento almacenado de usuario:

create table Orders (
OrderID            int
,CustomerID         nchar(5)
,EmployeeID         int
,OrderDate          datetime
,RequiredDate       datetime
,ShippedDate        datetime
,ShipVia            int
,Freight            money
,ShipName           nvarchar(40)
,ShipAddress        nvarchar(60)
,ShipCity           nvarchar(15)
,ShipRegion         nvarchar(15)
,ShipPostalCode     nvarchar(10)
,ShipCountry        nvarchar(15)
)

Personalmente, prefiero el segundo formato. Sin embargo, es importante tener en cuenta que sin importar el formato que utilice para crear una tabla, el Analizador de Consultas o el Administrador Empresarial siempre devolverán su código en el primer formato. Por eso uso, desarrollo y modifico mis scripts y los guardo en Visual Source Safe. Esto me permite abrir mi script en el formato en el que lo desarrollé, lo cual es crucial para mantener la consistencia.

Aunque existen herramientas de terceros disponibles para generar código a partir de una base de datos (ingeniería inversa), es posible que no proporcionen todas las características necesarias. Además, vale la pena mencionar que SQL Server 2005 puede no tener estas características.

Cuando se escribe o depura un procedimiento almacenado o un script de Transact-SQL, a menudo es necesario tener información sobre una tabla, como nombres de columnas y tipos de datos, fácilmente disponibles en diferentes formatos. Para agilizar el proceso de escritura, se puede utilizar un procedimiento almacenado de usuario llamado up_CT_Q (up significa procedimiento de usuario, CT significa Cortar Escritura, Q significa Consulta, lo que indica que no se utilizan declaraciones de inserción, actualización o eliminación en este procedimiento).

El procedimiento almacenado up_CT_Q devuelve información de tabla o vista en varios formatos. Veamos algunos ejemplos utilizando la tabla Customers en la base de datos Northwind:

Formato 1:

CustomerID       nchar(5)
,CompanyName      nvarchar(40)
,ContactName      nvarchar(30)
,ContactTitle     nvarchar(30)
,Address          nvarchar(60)
,City             nvarchar(15)
,Region           nvarchar(15)
,PostalCode       nvarchar(10)
,Country          nvarchar(15)
,Phone            nvarchar(24)
,Fax              nvarchar(24)

Este formato es útil para verificar rápidamente el tipo de datos y la longitud de la columna. Se puede utilizar como lista de parámetros de entrada para un procedimiento almacenado o en una declaración de creación de tabla para ingeniería inversa cuando sea necesario eliminar y crear una tabla con una definición modificada.

Formato 2:

Declare @CustomerID       nchar(5)
Declare @CompanyName      nvarchar(40)
Declare @ContactName      nvarchar(30)
Declare @ContactTitle     nvarchar(30)
Declare @Address          nvarchar(60)
Declare @City             nvarchar(15)
Declare @Region           nvarchar(15)
Declare @PostalCode       nvarchar(10)
Declare @Country          nvarchar(15)
Declare @Phone            nvarchar(24)
Declare @Fax              nvarchar(24)

Este formato es útil para declarar variables en un procedimiento almacenado.

Formato 3, tipo 1:

CustomerID
,CompanyName
,ContactName
,ContactTitle
,Address
,City
,Region
,PostalCode
,Country
,Phone
,Fax

En este formato, una declaración Select o Insert es más fácil de leer y gestionar. Si una tabla contiene una columna con la propiedad de identidad, se deben enumerar todas las columnas no nulas en una declaración Insert. Este formato también facilita comentar una columna si es necesario. Si bien el Analizador de Consultas de SQL puede generar una declaración Select, se vuelve difícil de leer y modificar cuando una tabla tiene múltiples columnas. Como buena práctica, cada línea de un script debe ajustarse al ancho de la pantalla.

Formato 3, tipo 2:

Cust.CustomerID
,Cust.CompanyName
,Cust.ContactName
,Cust.ContactTitle
,Cust.Address
,Cust.City
,Cust.Region
,Cust.PostalCode
,Cust.Country
,Cust.Phone
,Cust.Fax

Además del tipo 1, todos los nombres de columna tienen un prefijo de nombre de alias. Este formato es útil para varias uniones y subconsultas.

Formato 3, tipo 3:

Cust.CustomerID       as [CustomerID]
,Cust.CompanyName      as [CompanyName]
,Cust.ContactName      as [ContactName]
,Cust.ContactTitle     as [ContactTitle]
,Cust.Address          as [Address]
,Cust.City             as [City]
,Cust.Region           as [Region]
,Cust.PostalCode       as [PostalCode]
,Cust.Country          as [Country]
,Cust.Phone            as [Phone]
,Cust.Fax              as [Fax]

Este formato facilita cambiar el nombre de las columnas cuando la salida debe tener nombres diferentes a los de la tabla.

Formato 4:

CustomerID       = @CustomerID
,CompanyName      = @CompanyName
,ContactName      = @ContactName
,ContactTitle     = @ContactTitle
,Address          = @Address
,City             = @City
,Region           = @Region
,PostalCode       = @PostalCode
,Country          = @Country
,Phone            = @Phone
,Fax              = @Fax

Este formato se utiliza en la cláusula “where” de las declaraciones Select, Update o Delete en un procedimiento almacenado.

Formato 5, no se proporcionan parámetros de entrada:

Para obtener la descripción del procedimiento, simplemente ejecútelo sin ningún parámetro. Esto proporcionará la siguiente información:

DOCUMENTACIÓN y USO

El procedimiento almacenado definido por el usuario up_CT_Q se utiliza para la ingeniería inversa y para simplificar los procesos de escritura y depuración de scripts.

El primer parámetro de entrada es el nombre de la tabla.

El segundo parámetro de entrada es el Número de Formato que representa el formato de la salida.

FormatNumber = 1: se devuelve una lista de nombres de columna y sus tipos de datos. Esto es útil como lista de parámetros de entrada para un procedimiento almacenado.

FormatNumber = 2: se devuelve el nombre de columna con el prefijo @. Útil para declarar variables en un procedimiento almacenado.

FormatNumber = 3 Tipo 1: se devuelven todos los nombres de columna en un formato de tabla vertical de una columna. En este formato, una declaración Select o Insert es más fácil de leer y gestionar si es necesario comentar una columna.

FormatNumber = 3 Tipo 2: además del tipo 1, todos los nombres de columna tienen un prefijo de nombre de alias.

FormatNumber = 3 Tipo 3: facilita cambiar el nombre de las columnas.

FormatNumber = 4: se utiliza en la cláusula "where" de las declaraciones Select, Update o Delete.

Si no se proporciona el nombre de la tabla, el procedimiento devuelve la descripción y ejemplos de uso de este procedimiento.

Ejemplos, utilizando la tabla Customers en la base de datos Northwind:

Ejemplo 1, Formato 1: exec up_CT_Q Customers,1
Ejemplo 2, Formato 2: exec up_CT_Q Customers,2
Ejemplo 3, Formato 3, Tipo 1: exec up_CT_Q Customers,3,1
Ejemplo 3, Formato 3, Tipo 2: exec up_CT_Q Customers,3,2,Cust
Ejemplo 3, Formato 3, Tipo 3: exec up_CT_Q Customers,3,3,Cust
Ejemplo 4, Formato 4: exec up_CT_Q Customers,4
Ejemplo 5, para obtener la descripción del procedimiento: exec up_CT_Q

Utilizando el procedimiento almacenado up_CT_Q, podemos mejorar la funcionalidad del Analizador de Consultas de SQL Server y simplificar los procesos de escritura y depuración de scripts. Este procedimiento proporciona varios formatos de salida que se adaptan a diferentes necesidades, lo que facilita trabajar con tablas y columnas.

Recuerda, como desarrolladores, es importante encontrar formas de optimizar nuestro flujo de trabajo y ahorrar tiempo. El procedimiento almacenado up_CT_Q es solo un ejemplo de cómo podemos lograr esto en SQL Server.

¡Gracias por leer!