Y en el mundo de software pasa lo mismo. Acaso un “militante” del software libre diría que tecnológicamente, .NET es superior a Java? Muy difícil.
Muchos podrán sincerar su pensamiento político y decir que prefieren Java porque es open source y punto. Pero otros se enroscaran en una larga
“flame war” para demostrar que tienen razón.
Ahora que pasa cuando la elección de una tecnología ni siquiera obedece a una posición política visible? A nadie se le ocurriría decir que el uso store procedures sobre queries representa una postura ideológica… Y la realidad es que así como muchos prefieren a las rubias sobre las morochas o viceversa, muchos prefieren store procedures sobre querys.
Por supuesto como dije antes, para una determinada especificación funcional o restricción tecnológica, puede haber una clara y objetiva racionalidad en elegir un producto sobre el otro. Sin embargo, hay un universo de situaciones, donde la ventaja de la elección de una tecnología sobre otra es más difusa y ahí entra el conflicto. Ahí es donde se abre una ventana para la del tabú del programador inteligente, para lo que dificilmente pueda reconocer, para la subjetividad mas irracional posible: “el porque si”.

Y como se soluciona esto?
Mal que le pese a un peronista, la mejor opción para estos casos es el diálogo y consenso.

Importante: Esta consulta funciona para todos los packages instalados dentro de la base msdb, pero no para los que fueron deployados como archivos!

Importante 2: Esta consulta solo funciona en SQL Server 2008 en adelante. La vista msdb.dbo.sysssispackages no existe en SQL Server 2005.

Para acceder, pueden hacerlo por live meeting mediante alguno de los siguientes enlaces:

http://snipr.com/virtualaltnet

https://www323.livemeeting.com/cc/usergroups/join?id=van&role=attend

Para el que nunca escuchó hablar de estas tecnologías, esta es la web oficial de Pex.

Desde este link se pueden bajar el PPT de la Presentación que voy a hacer.

http://www.encuestasit.com/Estadisticas.aspx

/*Seteamos el uso maximo de SQL Server al valor que deseamos, (en este ejemplo, 1024MB). Como la liberacion de memoria, el SQL Server no la hace inmediatamente, hacemos un delay de 1 minuto.*/
WAITFOR DELAY ’00:01:00′
GO
EXEC sys.sp_configure N’max server memory (MB)’, N’1024′
GO
RECONFIGURE WITH OVERRIDE
GO

Qué cosas migra este utilitario?
• Schemas
• Tablas
• Constraints (Primary Keys, Unique Keys, Foreign Keys)
• Indices
• Tipos de datos (Domains en PostgreSQL)
• Vistas (Si el código SQL utilizado es compatible con PostgreSQL, no vamos a tener problemas, de lo contrario, tendremos que modificarlo manualmente para hacerlo compatible).
• Comentarios (Extended Properties en SQL Server)

Qué cosas no migra?
• Datos (para eso podemos utilizar algún ETL o SSIS)
• Store procedures/funciones/triggers (La aplicación sin embargo, nos permite generar el script de estos objetos, para que luego los modifiquemos manualmente).

Adicionalmente, este utilitario agrega un par de funciones que existen en SQL Server y no en PostgreSQL como por ejemplo “newid()”, cuando usamos columnas tipo ROWGUID en SQL Server.
También se genera un trigger automáticamente, cuando existe una columna Computed, ya que esta feature no existe en PostgreSQL. Tiene una mínima inteligencia en algunos aspectos, que nos pueden ahorrar mas tiempo todavía. Por ejemplo, cuando encuentra que se llama a la función GetDate(), se reemplaza por su homologa en PostgreSQL que es now(). Lo mismo hago para DatePart y un par de funciones mas.

Esta aplicación es muy básica, pero potente. No garantizo que funcione en todos los escenarios ni que sea infalible. Pero me ha servido para convertir bases de datos muy complejas de manera muy rapida y creo que puede servir a muchos.

La aplicación se puede bajar de esta URL.

Toda sugerencia, queja, critica sera bievenida.

Para crear un ABM de clientes, pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación. También debemos crear varios archivos XML de configuración para los distintos frameworks. Por supuesto no hay que olvidarse que debemos también crear clases e interfaces adicionales para los distintos patrones de diseño existentes que hacen nuestro código más elegante, óptimo, lindo, portable, legible, etc. O sea, más PRO.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.

No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.

/*Creamos una tabla Paises de ejemplo con el campo row_id con la propiedad IDENTITY habilitada*/
CREATE TABLE dbo.Paises (row_id INTEGER IDENTITY PRIMARY KEY NOT NULL, data SQL_VARIANT NULL);
GO

/*Insertamos información de ejemplo*/
INSERT dbo.Paises (data)
VALUES (‘Argentina’), (‘Brasil’), (‘Chile’), (‘Uruguay’)
GO

/*Paso 1: Borro todos los objetos dependedientes de la tabla a modificar*/
ALTER TABLE ClienteAsociadoAPais DROP CONSTRAINT Paises_Original_FK

/*Paso 2: Creamos una tabla idéntica a la tabla Paises, pero sin la propiedad identity sobre la columna row_id.*/
CREATE TABLE dbo.Destination (row_id INTEGER PRIMARY KEY NOT NULL, data SQL_VARIANT NULL);

/*Paso 3: Movemos el contenido de una tabla a otra.*/
ALTER TABLE dbo.Paises SWITCH TO dbo.Destination;

/*Paso 4: Eliminamos la tabla original (que ahora no tiene datos).*/
DROP TABLE dbo.Paises;

/*Paso 5: Renombramos la tabla para que tenga el nombre original*/
EXECUTE sp_rename N’dbo.Destination’, N’Paises’, ‘OBJECT’;

/*Paso 6: Creo todos los objetos dependedientes de la tabla a modificada que habia borrado en el paso 1*/
ALTER TABLE ClienteAsociadoAPais ADD CONSTRAINT Paises_Original_FK

La clave de esto esta en la sentencia SWITCH, que en realidad no mueve datos, sino que simplemente cambia el puntero de datos de un lugar a otro, con lo cual nos ahorramos un montón de problemas relacionados con lockeos. Este método tiene enorme ventajas por el método que anteriormente habíamos visto en el post anterior. En tabla muy grandes, la diferencia de performance es enorme.
Veamos los siguientes números capturados del profiler, para la tabla ejemplo con varios millones de registros:

Metodo clasico de reconstruccion de tabla:

Metodo alternativo usando SWITCH:

Como se puede ver, no hay comparacion posible entre ambos metodos, en tablas de mucho volumen.

Sin embargo, hay un par limitaciones:

• Esto solo funciona en las versiones Developer y Enterprise de SQL Server, ya que son las únicas que permiten manejo de particiones de tablas.
• La tabla Destino debe tener exactamente la misma estructura que la tabla origen (con excepción obviamente de la propiedad identity sobre la columna).

Algo que hay que tener en cuenta, es que al igual que el método de reconstrucción de tabla, hay que borrar y crear nuevamente todas las foreign key asociadas a la tabla.

Links relacionados:
Partitioned Tables and Indexes

Veamos este ejemplo:

INSERT INTO TablaCliente (ID, Nombre, Apellido)
SELECT ID, Nombre, Apellido FROM ServidorLinkeado.dbo.MaestroClientes

Yo quiero copiar el contenido de la tabla MaestroClientes de un servidor externo a mi base de datos. Supongamos que la tabla MaestroClientes contiene 20 millones de registros, lo que significa que aun en optimas condiciones, el proceso seguramente duraría al menos un par de minutos.
Ahora mientras se ejecuta el INSERT de mas arriba, hagamos un SELECT COUNT(*) FROM TablaCliente en otra sesión. Como verán, la consulta queda en espera, hasta que se termine la transacción que realiza el insertado de datos.
Sin embargo, si consultamos la vista de sistema sys.partitions, vamos a encontrar información muy interesante, especialmente en el campo Rows. Consultando esta vista para la tabla que deseamos monitorear a medida que se ejecuta la transacción, vamos a ver que el campo rows de esa vista varia.

Ejemplo:

SELECT object_id, rows FROM sys.partitions WHERE object_id = OBJECT_NAME(‘TablaCliente’)

A diferencia del SELECT COUNT(*) que hacíamos antes, esta consulta no queda bloqueada, pudiendo ser ejecutada varias veces mientras se realiza la transacción de insertado.
Entonces, como hacemos para ver el porcentaje de progreso?

1) Capturamos el total de registros que vamos a insertar:
SELECT COUNT(*) FROM ServidorLinkeado.dbo.MaestroClientes.

2) Capturamos el total de registros que ya existe en la tabla de destino:
SELECT rows FROM sys.partitions WHERE object_id = OBJECT_NAME(‘TablaCliente’)

3) Ejecutamos la transacción que realiza el insertado masivo de datos:
INSERT INTO TablaCliente (ID, Nombre, Apellido)
SELECT ID, Nombre, Apellido FROM ServidorLinkeado.dbo.MaestroClientes

4) Mientras se ejecuta la transacción, abrimos una nueva conexión y ejecutamos reiteradamente esta consulta:
SELECT rows FROM sys.partitions WHERE object_id = OBJECT_NAME(‘TablaCliente’)

Exactamente aplica la misma lógica, en el caso de que nos interese monitorear una operación de DELETE. La única diferencia es que en la columna rows de la tabla sys.partitions, veremos que su número desciende sucesivamente.

2) Agregar la sentencia CREATE OR REPLACE PROCEDURE/VIEW/FUNCTION como ya tienen Oracle o PostgreSQL. De esta manera, con una sola sentencia, nos evitamos verificar si existe o no una vista, store procedure o una función cuando deployamos.

3) CREATE TABLE NuevaTablaCliente AS TableClienteExistente. La posibilidad de crear una nueva tabla copiando la estructura de otra tabla ya existente es una feature muy piola de PostgreSQL.

4) ALTER COLUMN NombreColumn SET IDENTITY ON/OFF. Habilitar/deshabilitar un campo identity sin necesidad de reconstruir toda la tabla.

5) @NuevoParametro TablaCliente.ClienteId%TYPE. Poder declarar un parametro o variable como tipo de dato de una columna, en vez de declarar explicitamente el tipo de dato como hacemos actualmente.

6) Indíces Bitmap como los de Oracle.

7) Una funcion DECODE similar a la de Oracle (para el que no la conoce, es una especie de CASE…WHEN en una funcion).

8) Que no haya que configurar 50 parametros de Windows y DTC para poder correr una transacción distribuida correctamente.

9) Tener una función de conversión y formateo de datos potente, amigable y facil de usar, y no ese engendro de CONVERT.

10) Una función de SPLIT de string nativa para T-SQL que devuelva una variable de tabla.

11) ALTER TABLE para cambiar el orden de una columna en una tabla. Si bien es un poco “polémica” esta feature (se supone que el orden de las columnas no debería importarnos), la realidad es que a veces termina siendo útil. MySql tiene esta posibilidad.

12) Mejorar el error “String or binary data would be truncated.” cuando insertamos o modificamos datos. En que columna? Que valor fue el que tiro error? Si lo sabes, porque SQL Server no me lo queres decir?

13) Que soporte este tipo de sentencias: SELECT * FROM Clientes WHERE (col1, col2) NOT IN (SELECT col1, col2 FROM OtrosClientes). Actualmente el IN o NOT IN solo lo podemos hacer con una sola columna.

Alguna otra sugerencia?