Post original en JASoft.org: http://www.jasoft.org/Blog/post/Instancias-de-SQL-Server-191;que-son-y-para-que-sirven.aspx

Cuando instalas SQL Server se te pide que otorgues un nombre a la instancia que estás instalando. Y cuando te conectas desde una aplicación o con el SQL Server Management Studio (SSMS) también lo haces a una instancia determinada de SQL Server. Es tan común que todos lo damos por hecho, pero realmente ¿cuántos saben qué es una instancia de SQL Server y cuál es su utilidad?.

Bien, en SQL Server es posible ejecutar varias copias del servidor de datos al mismo tiempo, con sus usuarios, bases de datos y demás elementos independientes unos de otros. A cada una de esas copias se le llama “instancia”. Lo que tenemos con las instancias son varios SQL Server ejecutándose en paralelo en la misma máquina. El límite es de 50 de instancias por cada máquina.

Existen dos tipos de instancias:

• Las instancias con nombre: se accede usando una barra inclinada hacia la izquierda seguida del nombre de la instancia, que es la forma de identificarlas. Por ejemplo: (local)Instancia, .Instancia, localhostInstancia, 127.0.0.1Instancia, NombreServidorInstancia, 192.168.1.5Instancia.
• La instancia predeterminada: a ésta accedemos simplemente usando el nombre del servidor o su dirección IP. Por ejemplo, con todas estas expresiones: (local), . (un punto), localhost, 127.0.0.1, NombreServidor, 192.168.1.5 (la IP del servidor). No es obligatorio tenerla, por lo que podemos tener solamente instancias con nombre en el servidor y obviar esta instancia por defecto (o sin nombre).

Así, por ejemplo, cuando instalamos SQL Server Express éste suele instalarse en una instancia con nombre llamada “SQLExpress” por eso accedemos usando .SQLExpress y similares.

Pero… ¿para qué podríamos necesitar más de una instancia? ¿Acaso no nos llega con una copia de SQL Server ejecutándose y dando servicios a todos los clientes? Pues en algunos casos no.

Es cierto que una instancia de SQL Server puede gestionar un número ilimitado de bases de datos y usuarios, y mientras la máquina aguante es capaz de hacerse cargo de tantas conexiones como le lleguen en busca de información. Lo normal, de hecho, es tener solamente una instancia instalada en nuestros servidores. Es más, en una misma máquina el hecho de tener varias instancias a la vez bajaría de hecho un poco el desempeño, ya que cada copia en funcionamiento consume memoria extra. Así que por rendimiento no es.

Las principales razones serían:

• Seguridad: Si necesitamos dar acceso y control a diferentes personas para que puedan usar con cierta libertad SQL Server es interesante tener varias instancias ya que así cada una podrá tener sus propios usuarios y ejecutarse suplantando a un usuario diferente. Así el usuario administrador puede ser distinto en cada caso y acceder solamente a sus propias bases de datos. Si hay varias aplicaciones con diferentes requisitos de seguridad de acceso a SQL Server podemos tenerlas separadas para que no interfieran unas con otras. Lo cual nos lleva a…
• Hosting o segregación por departamentos: si hacemos hosting de bases de datos para pocos clientes o queremos compartir los recursos de una máquina entre varios departamentos de una empresa, tener una instancia para cada uno de ellos nos permite dedicar una determinada memoria y procesador a cada uno y compartir el sistema entre todos ellos de la manera más apropiada y aislándolos a unos de otros en lo que respecta a la seguridad. Cada instancia tiene sus ajustes de seguridad, de uso de hardware, de la intercalación (collation) por defecto, servidores enlazados, desencadenadores de login, etc… Lo cual nos lleva también a…
• Consolidación de servidores: si tenemos aplicaciones de datos que no son muy demandantes para los servidores ¿para qué vamos a tener varios servidores de datos y pagar varias licencias por lo tanto? Un plan mucho mejor que nos permite aprovechar mejor el hardware y aún así tener una abstracción idéntica en cuanto a servidores es usar una sola máquina con múltiples instancias separadas de SQL Server. Lo cual nos lleva a….
• Tener ediciones y SP diferentes: cada instancia se actualiza por separado y es una copia física también del servidor, por lo que puedes hacer que cada instancia sea diferente. Por ejemplo, una puede tener aplicados los últimos Service Pack y actualizaciones de SQL Server y otras instancias no o tener diferentes niveles de actualización. También puede que una sea una instancia sea la edición Express pero otra sea un edición Enterprise con capacidades diferentes. Esto es especialmente útil en entornos de desarrollo y pruebas. En lugar de instalar varias máquinas con ediciones o niveles de actualización diferentes los puedes montar todos juntos en la misma máquina de pruebas o desarrollo compartida por todo un equipo de programadores.

Es interesante saber que la licencia de SQL Server (complicada como ella sola, sobre todo ahora en su versión 2012) permite ejecutar tantas instancias como queramos en una máquina (hasta el máximo soportado) sin coste adicional.

Aquí tienes la documentación de MSDN sobre las instancias de SQL Server y su manejo (aunque curiosamente no aclara bien cuáles son las ventajas de tener más de una instancia, de ahí este post).

¡Espero que te sea útil!

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Los-selectores-CSS-se-procesan-de-derecha-a-izquierda-(y-por-que-eso-te-debe-importar).aspx

Las hojas de estilo en cascada o CSS son indispensables en cualquier aplicación Web no trivial. Nos permiten definir el estilo visual (e incluso el comportamiento) que mostrarán los diferentes elementos de contenido de una página o aplicación Web. Sin ellas serían imposibles la separación entre contenido y visualización o la adaptación de un mismo diseño de página a diferentes dispositivos.

Todos estamos acostumbrados a escribir CSS con sus diversas combinaciones de selectores, y cuando adquieren su verdadera potencia es, precisamente, al combinar las definiciones de selectores para poder asignar estilos con mucha exactitud.

Por ejemplo, imaginemos que tenemos una página con multitud de listas no ordenadas (por ejemplo colecciones de recursos en Internet) y queremos darle un estilo particular a los elementos de determinadas de estas listas. Podríamos especificar un selector como este:

   1: .recursos li {

   2:     font-weight: bold;

   3:     font-size: large;

   4: }

Con ello estamos indicando al navegador que cuando se encuentre con un elemento de lista que esté contenido dentro de un elemento que tenga aplicada la clase “recursos”, ponga su letra en tamaño grande y con negrita.

Así que si tenemos una lista como esta en la página:

   1: <ul class="recursos">

   2:     <li>Krasis</li>

   3:     <li>MAILCast</li>

   4:     <li>campusMVP</li>

   5:     <li>SELF</li>

   6: </ul>

Lo que obtendríamos sería algo similar a esto:

Hasta aquí todo muy simple y normal. No parece haber nada raro ¿verdad?

Bueno, en realidad no hay nada raro pero lo cierto es que en páginas grandes en las que debiésemos aplicar un estilo así podríamos tener problemas de rendimiento. Ahora explico por qué.

El “extraño” comportamiento de los navegadores

Cuando un programador ve un selector de estilos como el anterior lo primero que piensa, como es normal, es que el navegador buscará todos los elementos que tengan aplicada la clase “recursos” y luego dentro de cada uno de esos elementos buscará los elementos de lista, de modo que le aplicará el estilo indicado a los que encuentre ¿verdad?

Sin embargo los navegadores no trabajan de esa manera, sino de otra que puede parecer anti-intuitiva para la mayor parte de las situaciones.

La forma de proceder es justo la contraria. El navegador no carga la CSS y la procesa para aplicarla, sino que simplemente la procesa para crear una “base de datos en memoria” de las reglas que tiene definidas. Es más tarde al ir procesando el árbol de elementos de la página donde para cada elemento examina qué reglas le pueden corresponder y se las aplica.

Este comportamiento es lógico ya que las hojas CSS pueden contener cientos o miles de selectores, y una página sin embargo contiene habitualmente muchos menos elementos. Cuánto más tarde el navegador en procesar la página completa (incluidos los estilos) peor será la experiencia de usuario y menos útil y peor valorado estará. Así que es crucial que todo se procese a la mayor velocidad posible, y es más eficiente hacerlo a partir de los elementos que a partir de las definiciones contenidas en la CSS.

Así que lo normal es asumir que la mayor parte de los selectores CSS no van a coincidir con la mayoría de los elementos, lo cual es cierto para la mayoría de las páginas. Ciertas aplicaciones Web grandes pueden tener perfectamente más de mil selectores en sus hojas CSS (si no me crees echa un vistazo a SkyDrive o a GMail por ejemplo), por lo que buscar en la página los elementos que coincidan con el selector de cada una de ellas puede tardar muchísimo, y se hace justo al revés que es mucho más rápido y eficiente.

Esto implica que para un selector CSS como el del ejemplo:

   1: .recursos li

lo que se hace es primero buscar todos los li y luego ver cuáles están contenidos dentro de algún elemento con la clase “recursos”.

Es decir, en HTML los selectores CSS se procesan de derecha a izquierda y no al revés que parece más intuitivo.

En realidad, para ser más exactos, cuando el procesador de la página se encuentra con un elemento <li> lo que hace es ver qué reglas CSS existen que afecten a los elementos de este tipo. En nuestro ejemplo el selector le fuerza comprobar si cada <li> está o no contenido en algún nivel de la jerarquía dentro de un elemento con la clase “recursos” y si es así le aplica lo que indica el estilo para ese selector.

Si nos imaginamos una página con muy pocos estilos parece poco razonable actuar así. Sin embargo cuando la página contiene relativamente pocos elementos y muchos selectores CSS este modo de proceder hace que el procesamiento gane mucho en velocidad y eficiencia.

¿Y esto en qué me afecta?

Todo lo anterior parece mucho más ineficiente que procesar el selector y por lo tanto buscar todos los <li> contenidos en elementos con la clase “recursos”. Y de hecho lo es para este caso considerado aisladamente. Pero como ha quedado demostrado en páginas con muchos selectores es mucho más rápido en realidad que hacerlo de la forma que nos parece más intuitiva a priori.

En realidad en una página común todo esto no tiene demasiada importancia más allá de ser una curiosidad teórica, ya que en cualquier caso el procesamiento será muy rápido. Sin embargo en aplicaciones o sitios webs complejos como los mencionados, cada décima de segundo cuenta para dar una respuesta rápida a los usuarios y hacerlos más agradables de usar. Si cada vez que se cargase una carpeta de correo en Hotmail se tardase medio segundo más en visualizar la página la gente huiría en masa del servicio.

Ahora considera de nuevo nuestro sencillo ejemplo de las listas de recursos con el selector anterior, pero que actúa dentro de una página muy grande, que contenga miles de elementos <li> en nuestras listas de recursos. Podría ser por ejemplo una página auto-generada con listas enormes de datos generadas desde una base de datos, algunos de los cuales son recursos y se les debe aplicar el selector de ejemplo anterior, y otros son elementos de otros tipos de listas que no llevan ese estilo.

Con el nuevo conocimiento que hemos adquirido sobre cómo funciona el procesamiento de selectores lo que ocurriría es que por cada elemento <li> que se encuentra al procesar el DOM, el navegador tiene que mirar qué estilo le debe aplicar, y por lo tanto para cada uno de ellos debe comprobar en nuestro ejemplo si tiene un padre en algún nivel superior de la página que tenga aplicada la clase “recursos”. Esto hará que la aplicación de los estilos sea muy ineficiente y costosa. Y más si consideramos que puede haber listas anidadas y otros selectores CSS que le afecten.

Sabiendo esto podemos solucionar el posible problema cambiando el modo de seleccionar los elementos. Por ejemplo, sería mucho mejor aplicarles un identificador o una clase específica para que el navegador localice el estilo a aplicarles de manera directa.

Como digo, en cualquier página normal (incluso aunque tenga mil elementos <li>) el impacto de una ineficiencia así será inapreciable. Sin embargo en páginas complejas con muchos estilos solapados y muchos elementos a los que aplicárselos (piensa en GMail o SkyDirve) el impacto puede ser muy apreciable. Así que si el rendimiento nos importa debemos analizar más a fondo nuestros selectores CSS.

Este post está basado en material extraído de mi curso online de HTML(5) y CSS(3) en campusMVP. Si quieres aprender de verdad este tema y tenerme como tutor para contestar tus dudas empieza hoy mismo.

Obviamente esta es una sola de las muchas optimizaciones que podemos aplicar al CSS, pero como es muy poco conocida me ha parecido interesante resaltarla aquí.

¡Espero que te sea útil!