Programming Windows 6th Edition for 10 USD

Charles Petzold publicó en su blog, una oferta casi irresistible. La próxima edición de su libro Programming Windows estará disponible en preventa entre el 17 y 31 de mayo en 10 dólares. Cuando el libro se publique en su edición final, costará alrededor de 50 dólares, así que habrá que aprovechar la oferta.
Por ese precio, se tendrá por anticipado acceso al contenido parcial.

Para mayor detalle, consultar el blog de Charles Petzold…

[Actualización]:

Se publicó la versión final el 15 de Enero de 2013.

Asegurando consistencia ante cambio de tipos en Tablas SQL Server con las vistas INFORMATION_SCHEMA

El día de hoy me encontré con un problema derivado de la necesidad de cambiar un tipo de datos en una columna específica.

El problema era este…

Existen dos aplicaciones que se requiere actualizar y requieren el manejo de inventarios. Los catálogos de producto de ambas son semejantes salvo en el tipo de datos de la columna que es la llave primaria del mismo.

Supongamos la siguiente definición de tablas

CREATE TABLE [dbo].[Products1](
    [ProductID] [int] NOT NULL,
    [Productname] [nvarchar](50) COLLATE Modern_Spanish_CI_AS NOT NULL,
    [Existence] [int] NOT NULL,
CONSTRAINT [PK_Products1] PRIMARY KEY CLUSTERED
(
    [ProductID] ASC
)

y

CREATE TABLE [dbo].[Products2](
    [ProductID] [char](10) NOT NULL,
    [Productname] [nvarchar](50) COLLATE Modern_Spanish_CI_AS NOT NULL,
    [Existence] [int] NOT NULL,
CONSTRAINT [PK_Products1] PRIMARY KEY CLUSTERED
(
    [ProductID] ASC
)

Como podremos observar, la única variante entre ambas tablas es el tipo de dato de la llave primaria.

Ahora bien, para ambas tablas existen procedimientos almacenados que se encargan de las operaciones CRUD.

Con el fin de crear código único que permita acceder a ambas tablas, la necesidad puntual era la de consolidar los tipos definidos en ambas así como sus dependencias y es ahí donde existía un problema ya que no se tenía la certeza de que se encontraran todas las dependencias de la misma (nada garantizaba que se hubieran definido todas las llaves foráneas en las tablas relacionadas).

Si bien SQL Server nos puede proporcionar una vista de dependencias de un elemento de la base de datos, si no están definidas correctamente las restricciones, puede haber objetos que escapen a este análisis automático.

Es ahí donde entran las vistas de esquema de SQL. En particular, sabía que existían procedimientos almacenados y tablas que estaban relacionadas con los campos ProductID en ambas tablas, así que con el fin de garantizar que ninguna dependencia escapara, utilicé las siguientes instrucciones.

select * from information_schema.columns where column_name like ‘%Product%’

La sentencia SQL anterior, me permite identificar todas las columnas que tienen un nombre que contenga la palabra ‘Product’. De esta manera se identifican las tablas dependientes, tengan o no tengan restricciones de llave foránea.

La siguiente sentencia permite identificar los procedimientos almacenados que reciben como parámetro un argumento con nombre semejante a Product.

select * from information_schema.parameters where parameter_name like ‘%Product%’

Con lo anterior, tengo una lista que me permitirá tener una idea de si algún objeto dependiente se escapó del análisis.

Si bien lo anterior no me permite analizar todo el tipo de dependencias no detectadas automáticamente por SQL Server, me permite reducir el margen.

Una ventaja adicional es que se puede determinar si faltó la definición de alguna restricción de llave foránea y poder así emitirla.

Para más información de lo que podemos analizar con estas vistas, podemos ir al sitio de msdn http://msdn.microsoft.com/en-us/library/ms186778.aspx.

Etiquetas de Technorati: ,,,