Introducción al Power BI

Clásicamente la suite de inteligencia de negocios de Microsoft, está enfocada en el SQL Server, en donde se tienen SQL Server Integration Services para la parte de ETLs e integración, SQL Server Analisys Services para el manejo de datos analíticos y cubos y SQL Server Reporting Services para el despliegue de información y reportería.

Hoy en día Microsoft nos ofrece una alternativa en la que se saca provecho de las bondades de herramientas ya conocidas por el público en general, sin necesidad de ser técnicos como el Microsoft Excel 2013, de esta forma un usuario final trabaja dentro de su computador personal, sin necesidad de acudir a los departamentos de TI. Esto se logra a través de la instalación de plug-ins gratuitos para Excel, entre los que se tienen:

1. Power Query: Con esta herramienta se maneja la conexión al origen de datos, misma que puede ser una base de datos como Oracle, SQL Server, Acceso My SQL, así como archivos planos (como Excel o archivos de texto o XML), o páginas de Internet que utilicen el formato oData y se pueden buscar fácilmente a través de la herramienta (como por ejemplo, al poner en la búsqueda “Olympics”, el motor devuelve páginas de Wikipedia con tablas de los ganadores de las olimpiadas). Se podría hacer una analogía de Power Query con Integration Services, aunque sus fines y capacidades son diferentes, en el sentido de que es con estas dos herramientas con las que se extrae y limpia la información.
2. Power Pivot: Con esta herramienta se puede hacer una espacie de diseño de base de datos a raíz de la información extraída, por lo que se entenderá que se pueden hacer relaciones de datos entre orígenes de datos tan variados como Oracle o Excel. Igualmente aquí es donde se hacen algo parecido a los cubos de Analisys Services.
3. Power View: Se puede decir que las herramientas anteriores a pesar de ser de cliente, igualmente requieren de alguien con algún conocimientos técnico, al menos para la mayoría de los casos, contrariamente en el Power View es en donde ya entraría ese usuario final con conocimiento del negocio, para procesar los datos y crear los reportes, a su mejor conveniencia, con el manejo de agrupamientos, totales, gráficos, etc.
4. Power Map: Al igual que el Power View, es una herramienta para procesar la información final, pero a través de geolocalización con ayuda de los mapas de Bing de Microsoft.

Hasta este punto se puede llegar sin necesidad de tener una inversión adicional a la que de por sí tiene típicamente una organización como lo es Excel y sus respectivos repositorios de datos, pero su distribución sería un poco arcaica a través de envío de correos electrónicos, o copias de archivos de Excel. El paso final viene a solventar esto, y consiste en la publicación y distribución a través del uso de herramientas colaborativas como Sharepoint. Y aquí es donde entra en escena el Microsoft Office 365.

Office 365 es una solución basada en la nube de Office que ofrece diferentes servicios como:

• Office 365 Platform Service Description
• Exchange Online Service Description
• Exchange Online Archiving Service Description
• Exchange Online Protection Service Description
• Exchange Online Advanced Threat Protection Service Description
• SharePoint Online Service Description
• OneDrive for Business Service Description
• Skype for Business Online Service Description
• Office Online Service Description
• Office Applications Service Description
• Project Online Service Description
• Project Pro for Office 365 Service Description
• Yammer Service Description
• Power BI for Office 365 Service Description
• Power BI Service Description
• Microsoft Dynamics CRM Online Service Description

En este caso particular lo que se requeriría contratar como mínimo serían los servicios de Power BI Service Description y de Sharepoint Online Service Description. A través de esta herramienta se podrían compartir y visualizar los reportes en diferentes localidades geográficas con una cuenta de Office 365. Igualmente se puede utilizar una APP para Windows Mobile y Surface.

Algo muy importante a tomar en cuenta es que los datos que se acceden son los que se cargaron y se encuentran en el documento de Excel que se subió al Office 365, para este fin, Microsoft aumentó la capacidad mínima de filas que tiene Excel al utilizar estos plug-ins. Igualmente, al tratarse de una copia, dicha información requiere de cierta actualización que se puede llevar a cabo bajo demanda o a través de procesos programados dentro del mismo Office 365.

Authorization Manager

Como bien se sabe dos de las tareas más comunes en un sistema de seguridad es la “Autenticación” y la “Autorización”, la autenticación es el medio por el cual se comprueba que un usuario es quien dice ser y la autorización es la validación de las tareas que puede llevar a cabo un usuario autenticado.

El Authorization manager o AzMan es una herramienta de Microsoft, que se integra en muchos de sus sistemas operativos, de esta forma se reutilizan las bondades del sistema operativo para una de las tareas que se requieren en casi cualquier sistema como lo es la “Autorización”, del mismo modo se puede también reutilizar las características del sistema operativo para el manejo de la autenticación a través de los usuarios locales de máquinas o el Active Directory.

Esta herramienta, es una de las más flexibles, fáciles y escalables para administrar la seguridad basada en roles, es tan flexible que se pueden administrar varias aplicaciones (sistemas o módulos), cada una con sus operaciones (que es la unidad más pequeña de trabajo), tareas que están compuestas por operaciones y roles (los cuales pueden tener asignados operaciones o tareas), también se pueden crear roles que heredan características de otros roles, al mismo tiempo dichos roles pueden ser asignados a usuarios o grupos del sistema operativo. También se pueden usar scripts para cambiar permisos dinámicamente. Dicha política de seguridad puede estar almacenada en un Active Directory o un archivo XML, a dicho repositorio se le conoce con el nombre de “Store”.

La asignación de funciones y la corroboración de operaciones para un usuario se pueden configurar fuera de la aplicación y se pueden realizar mediante programación dentro de la aplicación.                        

A continuación paso a paso un ejemplo de la administración de seguridad con AzMan.

Paso 1

Clic en el menú inicio y escoger la opción run (Ejecutar), escribir AzMan.msc y dar clic en OK, este comando va a abrir el Authorization Manager.

 

Paso 2

Escoger la opción Action del menú y dar clic en Options…, se abre un cuadro de dialogo con los modo Developer o administrador. Se debe escoger el modo Developer como es de suponerse para la etapa de desarrollo (en este modo se tienen mayor cantidad de opciones, como la posibilidad de crear el store).

Paso 3

Escoger Action en el menú y dar clic en New authorization store. El usuario tiene la opción de crear un XML o utilizar el repositorio de Active Directory como authorization store. En la próxima imagen se utilizará un XML como authorization store.

Especificar la ruta del XML y digitar una descripción en caso de ser necesaria. Igualmente se recomienda en un repositorio XML durante la etapa de desarrollo y un Active Directory en producción.

Paso 4

Ingresar nuevamente al menú Action y seleccionar la opción New Application.

Paso 5

Indicar el nombre de la aplicación, una descripción y la versión de la misma.

Paso 6 

Expandir la aplicación y seleccionar la “Operation Definition” que está dentro de la carpeta Definitions. Ahora ingresar al menú “Action” o posicionar el cursor en el panel derecho y oprimir clic derecho para abrir el menú. Seleccionar la opción para crear una nueva definición de operación. Indicar el nombre, descripción y número, para la nueva operación. Se debe tener el cuidado de indicar un número único para cada una de las operaciones creadas.

Paso 7

Seleccionar la carpeta Task Definitions folder y escoger New Task en el menú Action o dar clic derecho y escoger la opción para crear una tarea nueva. Cada tarea que se crea va a tener una o más operaciones asociadas. Una tarea también puede tener tareas anidadas. Se debe indicar el nombre de la tarea y una descripción y luego dar clic en OK. 

Paso 8

Oprimir clic derecho sobre la nueva tarea y escoger la opción propiedades. En el tab Definition dar clic en Add y seleccionar las operaciones respectivas de la tarea.

Paso 9

Ya se tienen definidas todas las operaciones y tareas para cada módulo.

Paso 10

Oprimir clic derecho sobre Role definitions que está dentro de la carpeta Definitions, elegir la opción New Role Definition, indicar el nombre y la descripción del rol y dar clic en OK. 

Paso 11

Oprimir clic derecho sobre el rol y elegir la opción propiedades. En el tab Definition dar clic en Add, en la ventana que se despliega seleccionar el tab Task y escoger las tareas respectivas.

Paso 12

En el paso anterior se indicó como asignar las tareas a los roles. Ahora se debe asignar solo los roles adecuados para la aplicación creada. Seleccionar la carpeta "Role Assignments" que está en la carpeta Application y escoger la opción Action del Menú y de ahí Assign Roles. Seleccionar los roles adecuados de la lista.

Paso 13

Asignar usuarios y crear grupos para los roles definidos. Escoger la carpeta Group que está dentro de la carpeta de la aplicación, oprimir clic derecho y seleccionar la opción New application group. Indicar el nombre y la descripción del Application Group y oprimir OK.  Oprimir clic derecho sobre el nuevo Application Group y seleccionar propiedades. En la ventana de propiedades, escoger el tab Members y dar clic sobre la "Add Windows Users and Groups..." y agregar los usuarios correspondientes.

Paso 14

Seleccionar el rol que tiene asignada la aplicación (dentro de la carpeta Role Assigments), oprimir clic derecho en el rol y escoger la opción Assign Application Group y seleccionar los grupos de usuarios de la lista que se despliega.

Paso 15

Oprimir clic derecho sobre la carpeta de la aplicación y seleccionar la opción New Scope. Indicar el nombre y la descripción del Scope y oprimir OK.

Microsoft Certifications

Microsoft Certifications

Al estar muy de cerca de Microsoft durante muchos de los años en los que tengo de laborar y ser contacto principal de dicha empresa en el lugar en el que trabajo, además de que muchas personas me consultan sobre este respecto, se me ocurrió recopilar un poco de la información que he recolectado durante todo este tiempo y me pareció interesante agregar un artículo en el blog sobre esto, la idea es ver un poco la historia y documentar qué es lo que existe hoy en día (2014) y las preguntas más frecuentes sobre qué hacer para certificarse con Microsoft.

Primera Generación

Hasta donde tengo memoria, las primeras certificaciones proveídas por Microsoft incluían la MCP (Microsoft Certified Professional), MCAD (Microsoft Certified Application Developer), MCSD (Microsoft Certified Solution Developer), MCDBA (Microsoft Certified Data Base Administrator) en el área de desarrollo o MCSE (Microsoft Certified Systems Engineer) y MCSA (Microsoft Certified Systems Administrator) en el área de infraestructura, entre muchas otras, estas evolucionaron de entre tecnologías tan variadas como Visual Studio 5.0, 6.0 (Incluyendo Visual Fox), 2002, 2003, SQL Server 6.5, 7.0 o 2000.

Segunda Generación

Casi que Con la salida del Visual Studio 2005 y SQL Server 2005, surgió lo que Microsoft denominó certificaciones de la nueva generación que ahora eran más orientadas hacia una especialización particular:

MCTS (Microsoft Certified Technology Specialist): Digamos que Homólogo al MCP, una de sus principales similitudes es que consistían en certificaciones que se ganaban con tan solo un examen, aunque algunos MCTS requerían de dos exámenes, adicionalmente, el MCTS venía más orientado a una especialidad en específica, mientras que el MCP era totalmente genérico, tomando en cuenta gran variedad de especialidades como SQL Server 2005 o BizTalk 2006, así con el MCTS existían certificaciones con “apellido” por decirlo así como por ejemplo: “MCTS SQL Server 2005”.

MCITP: Microsoft Certified IT Professional, que podía tener especialidades en el área de Business Intelligence, como DB Developer o como DBA (Homólogo al MCDBA).

MCPD: Microsoft Certified Professional Developer, que podía tener especialidades en aplicaciones Windows, Web (Homólogo al MCAD) y aplicaciones Enterprise (Homólogo al MCSD, que era por decirlo así, un escalafón más por encima del MCAD). Esta certificación también tenía “apellido” como por ejemplo: “MCPD: Web Developer”.

Adicionalmente se incluye un nivel nuevo, el Microsoft Certified Architect Program que reúne como requisitos 10 años de experiencia y 3 años como arquitecto, además de una tutoría de un arquitecto certificado de Microsoft.

Una característica de esta generación de certificaciones era que existían muchos exámenes que se podían reutilizar, por ejemplo el examen 70-536 podía servir para varios MCTSs y para todos los MCPDs), por esta razón siempre es muy importante el conocer muy bien todos los exámenes requeridos para cada certificación lo que se conoce como el Certification RoadMap.

Tercera Generación

Actualmente ya existe una nueva generación, esta se divide en cuatro grandes áreas (Business, Client, Server, Database y Development) en prácticamente todas estas áreas existe la certificación (aunque al no tener la palabra “certified”, digamos que es más como un asociado) MTA (Microsoft Tecnology Associate), la cual llega a sustituir al MCTS, la principal diferencia radica en que los exámenes para los MTA no se reutilizan en las certificaciones de mayor nivel.

Un dato curioso es que en los siguientes niveles de esta generación prácticamente todos los acrónimos de las certificaciones coinciden con acrónimos de la primera generación, aunque no necesariamente tienen relación con los mismos, de hecho podríamos decir que prácticamente no tienen relación. Por ejemplo el siguiente nivel consiste en el MCSA (Microsoft Certified Solutions Associate) que aplica para las áreas de Client, Server y Database, el en área de Business el análogo al MCSA es el MOS Specialist (Microsoft Office Specialist), mientras que en el área de desarrollo (development) no hay una certificación para este primer nivel.

El siguiente nivel lo conforman el MOS Master (en el área de Business), MCSE (Microsoft Certified Solutions Expert) para las áreas de Server y Database, estas también poseen apellidos como por ejemplo (MCSE Data Platform) y digamos que están al nivel de los anteriores MCPD y MCITP, mientras que en el área de desarrollo a este nivel tenemos la certificación MCSD (Microsoft Certified Solutions Developer), interesante notar que esta dice “Solutions” y no “Solution” como la de la primera generación, estás también tienen “apellido” como por ejemplo: “MCSD Web Apps”.

En la cumbre de esta pirámide, nos encontramos con el Microsoft Certified Solutions Master (MCSM) y Microsoft Certified Architect (MCA).

Quiero certificarme, ¿qué hacer?

Cuando alguien va a empezar a certificarse siempre es recomendado empezar por la última generación disponible y estudiar muy bien el RoadMap, así se podría determinar por qué ruta empezar, por ejemplo podría determinarse que el área de su interés es desarrollo (development) y más específicamente el área Web por lo que tendría muy claro que el primer examen a llevar a cabo sería el 70-480.

En el sitio Web www.microsoft.com/learning, se puede encontrar información muy útil sobre todas las certificaciones disponibles de Microsoft, los exámenes que estos requieren, los cursos necesarios para optar por los diferentes exámenes, el temario completo de cada uno, así como libros recomendados entre los que se encuentran los famosos self-paced que según Microsoft contienen la información necesaria para aprobar un examen en específico. Por supuesto dicho sitio solamente incluye material de Microsoft pero existe mucho más material de estudio de terceros incluyendo libros, simuladores, etc. Siempre lo más importante de estos ejercicios de certificación es el homologar conocimientos e ir siempre aprendiendo cosas nuevas con el fin de utilizar dicha información en la labor diaria, talvez es muy difícil que alguien domine perfectamente cualquier tema y/o tecnología pero es muy útil el conocer al menos gran parte de las opciones que nos brinda Microsoft, para explotar de una mejor forma dichas tecnologías.

Para realizar un examen de certificación de Microsoft al igual que cualquier otro tipo de certificación como Cisco, Solaris, Oracle o Adobe, estos no pueden ser realizados por universidades si no que requiere de proveedores de exámenes reconocidos por el ente certificador (Exam Providers), como por ejemplo VUE, Thomson Prometric o Certiport, en el caso de Microsoft actualmente solamente tiene un proveedor certificado, Thomson Prometric (http://www.prometric.com), los exam providers, tienen a su vez asociados Test Centers que es donde se realiza físicamente el examen, por ejemplo en Costa Rica tenemos New Horizons o Biznet. Desde el sitio de Prometric se pueden revisar los test centers, además se pueden inscribir para programar y pagar un examen (actualmente el costo es de $100) también se puede revisar la disponibilidad de horarios.

Un poco de usuarios y permisos

En esta ocasión me gustaría hablar un poco sobre un tema que tiende mucho a confundir, pero a la vez es muy útil de conocer ya que se da en diversas situaciones dentro del desarrollo de aplicaciones ASPNET. Para empezar me gustaría diferenciar que principalmente hay tres usuarios asociados a una aplicación Web. El usuario autenticado que puede ser visualizado a través de la siguiente sentencia:

System.Threading.Thread.CurrentPrincipal.Identity.Name

, el usuario del contexto de seguridad, por lo general es el que va a tener acceso a algunos recursos, esta se puede ver a través de:

System.Security.Principal.WindowsIdentity.GetCurrent().Name

, y el usuario encargado de correr el proceso.

El usuario autenticado prácticamente puede tener cualquier cosa desde “vacío” en el caso de que se utilice autenticación anónima en el IIS o la aplicación esté configurada para no utilizar autenticación del todo (); hasta cualquier usuario customizado. El usuario del servicio, sí deberá poseer una cuenta de Windows válida siempre, ya sea como usuario de una máquina local o de un Active Directory, este usuario por defecto es ASPNET en IIS 5 (Windows XP, 2000) o NETWORK SERVICE en IIS 6 o 7 (Windows 2003, Vista, 7). Inicialmente y por lo regular el usuario que corre el proceso es el mismo del contexto de seguridad. Recordemos que en este caso, el proceso (Worker Process), es el proceso que ejecuta el IIS para el sitio y se llama “aspnet_wp” en IIS 5 y “w3wp” en IIS 6/7, por lo que usuario que lo ejecuta podría se visualizado desde el administrador de tareas de la máquina que hostea la aplicación Web.

Otro punto importante es la impersonificación (Impersonate). Si a través del web.config habilitamos la impersonificación () el usuario del contexto de seguridad, asume la identidad del usuario autenticado, esto puede ser útil en casos donde se necesitan accesar recursos especiales como un archivo de texto, el log de eventos, un WebService, una cola, una base de datos, etc. y el usuario por defecto (ASPNET o NETWORK SERVICE) al ser un usuario de bajos privilegios no tendría permisos para dicho fin. Pero hay que tener mucho cuidado al llevar a cabo esta acción, solo debería utilizarse para recursos en los que efectivamente el acceso es por usuario, porque de no ser así no tendría mucho sentido asignar permisos a todos los usuarios de la aplicación sobre un recurso en particular. Esta situación no se presentaría en el caso de que se asigne un usuario específico en la impersonificación (), pero igualmente sería un asunto de cuidado, además de que como sabemos la sentencia anterior no es muy segura.

En ambientes con IIS 6 o superior todo sitio Web se ejecuta bajo un aplication pool, el default application pool tiene asignada la cuenta de NETWORK SERVICE, es por esto que esta es la cuenta que corre el proceso por defecto, así las cosas, otra opción para resolver el problema anterior podría ser utilizar un pool customizado con una cuenta específica.

También hay situaciones en las que el acceso al recurso específico es por usuario, pero como medida de seguridad, no se desea impersonificar siempre, en estos casos se podría llevar a cabo una impersonificación temporal a través del objeto WindowsImpersonationContext, esto se ilustra en el siguiente ejemplo, accesando un WebService:

localhost.Service proxy = new localhost.Service();

IPrincipal p = this.User;
WindowsIdentity wi = (WindowsIdentity)p.Identity;
WindowsImpersonationContext wic = wi.Impersonate();
try
{
// Recurso que requiere cierto permisos
proxy.Credentials = CredentialCache.DefaultCredentials;
retorno = proxy.HelloWorld();
}
finally
{
wic.Undo();
}

Y ya que estamos con un ejemplo de acceso a un WebService cabe destacar que al accesar un WebService desde un sitio Web el usuario del contexto de seguridad, pasaría a ser el usuario autenticado dentro del mismo, por ejemplo si el usuario autenticado es “rzumbado” y el usuario del contexto de seguridad es ASPNET, al llamar al servicio Web, dentro del contexto del mismo, ASPNET pasaría a ser el usuario autenticado, siempre y cuando se utilice la sentencia se asignen las DefaultCredentials a las credenciales del proxy (proxy.Credentials = CredentialCache.DefaultCredentials;). De no asignarse las credenciales, el servicio Web se estaría accesando de forma anónima.

Una vez explicado esto se puede entender porqué, un WebService sin autenticación anónima por lo general da un error de acceso denegado si no se setean las credenciales y porqué en un WebService sobre el que no tiene acceso ASPNET o NETWORK SERVICE hay que impersonificar temporal o permanente o utilizar un usuario customizado a través de un aplication pool en IIS 6.

Sobre Cursores y Tablas Temporales

Investigando un poco por la Web y a raíz de diferentes posiciones de clientes con respecto al uso o no de tablas temporales, cursores y variables de tipo tabla en Sql Server, me percaté de que allí también existen opiniones muy variadas, por lo que decidí darme a la tarea de investigar un poco por mi cuenta y hacer mis propias pruebas. Para los que no saben les cuento que las tablas temporales se almacenan en una base de datos de sistema llamada TempDB, en cuanto a las variables tipo tabla y los cursores se almacenan en memoria hasta cierto límite, para luego, en caso de que sea necesario utilizar igualmente la base de datos TempDB.
La prueba consistió en lo siguiente, creé una tabla con cuatro columnas, nada especial, de hecho tomé una tabla de pruebas que ya existía en la base de datos:

CREATE TABLE Test(
Col1 int NULL,
Col2 int NULL,
Col3 numeric(16, 2) NULL,
Col4 int NULL
) ON PRIMARY

E inserté ciertos valores, probé con cantidades tan variadas como 10.000 o 700.000 registros

DECLARE @i decimal(8), @j decimal(8)
SET @i = 1
SET @j = 300000
WHILE @i <= @j
BEGIN
INSERT INTO Test(Col1, Col2, Col3, Col4) VALUES(1,10,500,8)
SET @i = @i + 1
END

La prueba básica consistió en realizar lo que más comúnmente hacemos con este tipo de objetos, que es crear la estructura, llenarla y procesarla obteniendo la información de la misma.

Primero hice pruebas con tablas temporales y variables tipo tabla, en teoría lo recomendable es utilizar variables tipo tabla con cantidades pequeñas de registros y tablas temporales con cantidades más grandes, me sorprendió que en todos los casos fue más veloz el uso de tablas temporales, en el peor de los casos duró 22 seguros, mientras que el uso de variables tipo tabla duró 29. Si bien es cierto la diferencia no es mucha comparativamente hablando, si fue un comportamiento que siempre se dio:

-- 22
SELECT * INTO #Test FROM Test
SELECT * FROM #Test
DROP table #Test

-- 29
DECLARE @Test TABLE (
Col1 int NULL,
Col2 int NULL,
Col3 numeric(16, 2) NULL,
Col4 int NULL)
INSERT @Test SELECT * FROM Test
SELECT * FROM @Test

Para constatar que no estubiera afectando el hecho de que con el uso de tablas temporales se estaba omitiendo la creación explícita de la misma, además de la forma de llenado, también hice las mismas pruebas con un tabla temporal, pero creándola explícitamente y llenándola con una cláusula INSERT-SELECT en vez del SELECT-INTO, utilizado en el ejemplo anterior. En este caso los tiempos de respuesta fueron prácticamente iguales que los arrojados con la prueba de la variable tipo tabla

-- 29
CREATE TABLE #Test (
Col1 int NULL,
Col2 int NULL,
Col3 numeric(16, 2) NULL,
Col4 int NULL)
INSERT #Test SELECT * FROM Test
SELECT * FROM #Test
DROP table #Test

Para enriquecer aun más la prueba, hice lo mismo con tablas permanentes. En este caso, el peor escenario duró más que el procesamiento de la tabla temporal (42 segundos), pero le di el beneficio de la duda al haberse creado en la base de datos actual, misma que para este efecto en particular estaba más saturada que TempDB, que es donde se almacenan las tablas temporales, por lo que hice otra prueba en donde creaba la tabla permanente en la misma base de datos de las tablas temporales y el comportamiento fue básicamente el mismo de estas con un tiempo en el peor caso de 30 segundos:

-- 42
CREATE TABLE Test2 (
Col1 int NULL,
Col2 int NULL,
Col3 numeric(16, 2) NULL,
Col4 int NULL)
INSERT Test2 SELECT * FROM Test
SELECT * FROM Test2
DROP table Test2

-- 30
CREATE TABLE tempdb.dbo.Test2 (
Col1 int NULL,
Col2 int NULL,
Col3 numeric(16, 2) NULL,
Col4 int NULL)
INSERT tempdb.dbo.Test2 SELECT * FROM Test
SELECT * FROM tempdb.dbo.Test2
DROP table tempdb.dbo.Test2


Este conviene traer a la reflexión lo que muchas veces pasa con las tablas temporales, como ya se mencionó se almacenan en TempDB, demás de otros objetos, como variables, cursores, objetos internos del motor, versiones de filas generadas por las transacciones, etc. En la medida en que se utilicen en exceso este tipo de objetos, dicha base de datos puede ver afectado su rendimiento, en el ejemplo que hice pasó lo inverso, porque en dicho servidor se utiliza muy poco la base de datos TempDB, pero la base de datos del sistema si tendía a sobrecargarse. Muchas veces se sataniza el uso de tablas temporales, pero al igual que todo, es cuestión de moderación.

Para terminar la prueba faltaba el caso de los recorridos, los cursores siempre han sido muy criticados por causar latencia, esto es cierto por lo que en la manera de los posible hay que evitar su uso, lamentablemente no siempre es ta sencillo evitar usarlos, por ejemplo en casos en que hay que realizar algún tipo de cálculo por cada registro. Las pruebas se realizaron con los mismos escenarios de las anteriores y por lo general rondó el doble o más de que tardaba el proceso con tablas temporales, en el peor escenario duró 61 segundos:

-- 61
DECLARE @Col1 int, @Col2 int, @Col3 numeric(16, 2), @Col4 int
DECLARE cursor_test CURSOR FOR
SELECT *
FROM Test
OPEN cursor_test
FETCH NEXT FROM cursor_test INTO @Col1, @Col2, @Col3, @Col4
WHILE @@FETCH_STATUS = 0
BEGIN
FETCH NEXT FROM cursor_test INTO @Col1, @Col2, @Col3, @Col4
END
CLOSE cursor_test
DEALLOCATE cursor_test

Para mostrar la alternativa a los cursores realicé otro caso con un recorrido a una variable de tipo tabla, a través de una lógica que me encontré en más de un sitio, a razón de ser sincero al ver dicho código no me parecía que fuera muy eficiente, de hecho esperaba una forma menos artesanal de llevar a cabo dicha labor, pero no encontré ninguna, sin embargo viendo un poco los comentarios de los artículos esperaba alguna sorpresa, sin embargo no fue así, de hecho no puedo decir cuánto duró el peor escenario porque no tuve la paciencia de esperar, pero tardó más de 6 minutos. Para poder ver resultados, con el fin de constatar que la lógica estubiera bien tuve que probar con 10.000 registros arrojando una duración de desesperantes 15 segundos, contra un tiempo menor a un segundo con los clásicos cursores.

-- > 300
DECLARE @rowId int, @maxRowId int
DECLARE @Col1 int, @Col2 int, @Col3 numeric(16, 2), @Col4 int
DECLARE @Test2 TABLE (
rowId int identity(1,1),
Col1 int NULL,
Col2 int NULL,
Col3 numeric(16, 2) NULL,
Col4 int NULL)
INSERT @Test2 SELECT * FROM Test
SELECT
@rowId = min(RowId),
@MaxRowId = max(RowId)
FROM @Test2
WHILE @RowId <= @MaxRowId BEGIN
SELECT @Col1 = Col1, @Col2 = Col2,
@Col3 = Col3, @Col4 = Col4
FROM @Test2
WHERE RowId = @RowId
SET @RowId = @RowId + 1
END