Las ediciones de Azure SQL Databases Web y Business están siendo retiradas

Las ediciones Web y Business serán retiradas en setiembre del 2015. Los niveles de servicio Basic, Standard y Premium reemplazarán las ediciones Web y Business.

En el portal las bases de datos se mostrarán como «Retired» debido a que no estarán disponibles a partir de setiembre 2015, puedes crear todavía bases de datos tipo Web y Business pero la etiqueta «retirado» será un recordatorio de que es mejor que pases a Basic, Standard o Premium para bases de datos nuevas. Deberías actualizar tus bases de datos. Puedes usar este pdf llamado «Web and Business Database Migration Guidance Cookbok», para planear tu migración y decidir qué opción te conviene más.

Las bases de datos Web y Business corren en un ambiente compartido y de múltiples inquilinos (cuentas en Azure) y no hay una capacidad reservada de recursos para las bases de datos. La actividad de otras base de datos dentro del ambiente compartido puede impactar el rendimiento de tus bases de datos. Esto tiene como resultado un rendimiento que varía mucho y es muy impredecible. La opinión de los clientes de Azure es que este rendimento impredecible es difícil de administrar y más un rendimiento más predecible es preferido.

Las nuevas ediciones o capas de servicio (Basic, Standard y Premium) ofrecen un rendimiento predecible y muchas características extra para asegurar la continuidad del negocio y la seguridad. Estos niveles de servicio están diseñados para proveer de un nivel específico de recursos para una base de datos sin importar las cargas de trabajo de otros clientes en ese ambiente.

La mejor opción para migrar es aquella que te brinde el nivel de rendimiento y tenga el balance óptimo entre características, rendimiento y costo. Además que satisfaga completamente los requerimientos específicos de tu aplicación.

Desde que las capas de servicio se pagan por hora tienes la habilidad de escalar cada base de datos hacia arriba o hacia abajo 4 veces durante un periodo de 24 horas (usando el portal de Azure o programáticamente).

Actualizar las bases de datos Web y Business.

Actualizar tus bases de datos Web y Business a una nueva capa de servicio no pone fuera de línea tu base de datos. La base de datos seguirá operando mientras se realiza la operación de actualización. Una vez que la transición termine habrá un corte de las conexiones temporal por una pequeña duración de tiempo (segundos). Si tu aplicación maneja errores de conexión, es suficiente para protegerte del corte de conexiones al final de la actualización.

Para más información ir al siguiente artículo.

En este enlace puedes ver las preguntas frecuentes sobre el tema.

SQL Server diferencias entre TOP y OFFSET FETCH

TOP y la dupla OFFSET – FETCH permiten limitar el número de registros devueltos.

TOP.

Devuelve un número específico de registros de una consulta.

Ha estado disponible desde la versión de SQL Server 2000.

La versión 2000 requería escribir directamente el entero, no se podía usar una variable.

SELECT TOP 10 a FROM tabla

Tampoco se puede usar paréntesis:

SELECT TOP (10) a from tabla

Desde la versión 2005 se puede usar una variable, una expresión o una sentencia.

SELECT TOP (@variable) a FROM tabla ORDER BY a

SELECT TOP (SELECT COUNT(*) FROM otraTabla) a FROM tabla ORDER BY a

SELECT TOP (@variable + 5 * 4 / 2) a FROM tabla ORDER BY a

TOP no cumple con el estándar ANSI y está limitado a productos de Microsoft tales como SQL Server y Access.

La cláusula TOP puede usarse con ORDER BY o sin ORDER BY.

ORDER BY no es requerido pero si no ordenas no hay garantías sobre que registros devolverá.

TOP soporta el uso de porcentajes.

SELECT TOP 10 PERCENT a FROM tabla

El número de registros devuelto se redondea hacia arriba. Ejemplo: 50.4 -> 51.

Para obtener los últimos registros puedes hacer lo siguiente:

SELECT TOP 10 a FROM tabla ORDER BY a DESC

Como está ordenado descendentemente los resultados están al revés.

Soporta WITH TIES que permite mostrar registros adicionales que tienen el mismo valor. Tener en cuenta que su rendimiento se verá afectado si no encuentra un buen índice.

Un poco de historia. Antes de SQL Server 2000 no había TOP se tenía que usar SET ROWCOUNT número entero o variable.

SET ROWCOUNT @max
SELECT * FROM tabla
SET ROWCOUNT 0

No olvidar la última línea para quitar el límite de n registros impuesto por el primer SET ROWCOUNT.

OFFSET y FETCH.

Devuelven una «ventana de registros» de los resultados. OFFSET especifica cuantos registros tiene que saltarse dentro del resultado y FETCH especifica cuantos registros desde ese punto en adelante tiene que devolver.

Fueron introducidos desde SQL Server 2012 y cumplen con ANSI.

Puedes usar OFFSET sin FETCH pero FETCH no se puede usar solo.

Se deben usar con una cláusula ORDER BY. Y la razón es muy simple: OFFSET y FETCH son parte de la cláusula ORDER BY.

SELECT a FROM tabla
ORDER BY a
 OFFSET 10 ROWS
 FETCH NEXT 10 ROWS ONLY

El siguiente ejemplo obtiene los mismos resultados que un TOP 10.

SELECT a FROM tabla
ORDER BY a
 OFFSET 0 ROWS
 FETCH NEXT 10 ROWS ONLY

Cuando OFFSET es igual a 0, ningún registro es saltado.

No tienen una forma innata para devolver un porcentaje de registros. Sin embargo puedes calcularlo tú mismo así:

SELECT a FROM tabla
ORDER BY a
 OFFSET 0 ROWS
 FETCH NEXT (SELECT CAST(CEILING(COUNT(*) * .1) AS INT) FROM tabla) ROWS ONLY

El truco es usar un subquery (sub-consulta).

Para obtener los últimos registros puedes invertir el orden como lo hicimos para el TOP.

SELECT a FROM tabla
ORDER BY a DESC
 OFFSET 0 ROWS
 FETCH NEXT 10 ROWS ONLY

Otra forma es usar una sub-consulta.

SELECT a
FROM tabla
ORDER BY a
 OFFSET (SELECT COUNT(*) FROM a)-10 ROWS
 FETCH NEXT 10 ROWS ONLY

Este método es peligroso ya que el cálculo de OFFSET podría resultar en un valor menor que 0. En el ejemplo si el número de registros es menor que 10. Para evitar esta condición tendrías que usar una sentencia CASE.

Si el OFFSET es superior al número de registros, no devuelve registros.

Paginación.

Uno de los usos populares de OFFSET y FETCH es la paginación.

Suponiendo que tenemos una página web que muestra empleados ordenados por FechaContratación. Si queremos mostrar 20 empleados por página y estamos mostrando la tercera página (empleados del 21 – 30) podemos usar lo siguiente:

SELECT ID, Titulo, FechaContratacion 
FROM Empleados
ORDER BY FechaContratacion
 OFFSET 20 ROWS
 FETCH NEXT 10 ROWS ONLY

Comparación.

Item	TOP	OFFSET y FETCH
ANSI	No	Sí
Versión de SQL Server	2000	2012
Requiere ORDER BY	No	Sí
Porcentajes	Sí	No (usar subqueries)
Limita número de registros devueltos	No	Sí
Devuelve últimos registros	Ordena Descendente	Sí
Bueno para paginación	No	Sí
Devuelve resultados del «medio»	No	Sí
WITH TIES	Sí	No

Enlace al documento original en inglés en CodeProject.

Diferencia entre llave primaria (Primary Key) y llave foránea (Foreign Key)

Llaves primarias (Primary Key o PK).

Para que una tabla califique como tabla relacional debe tener una llave primaria.

Las llaves primarias consisten de una o más columnas cuyos datos contenidos sean utilizados para identificar de manera única cada registro (fila) en la tabla.

Cuando la llave primaria se compone de múltiples columnas, los datos de cada columna son utilizados para determinar si un registro es único.

No puede haber duplicados en la columna(s) que compone(n) la llave primaria y no puede estar en blanco o ser NULL.

Sólo puede haber una llave primaria por tabla.

La llave primaria para cada tabla es almacenada en un índice. El índice se utiliza para asegurarse que cada registro (fila) es único.

Llaves foráneas (Foreign Key o FK).

Una llave foránea es un grupo de una o más columnas en una tabla que referencia la llave primaria de otra tabla. No existe un código especial, configuración o definición de tabla que necesites establecer para «designar» oficialmente una llave foránea.

Una llave foránea puede también ser parte de una llave primaria.

En el ejemplo de arriba BusinessEntityID de la tabla PersonPhone es una llave foránea que apunta a la llave primaria BusinessEntityID de la tabla Person. La llave primaria de PersonPhone está conformada por 3 columnas: BusinessEntityID, PhoneNumber y PhoneNumberTypeID.

Es un poco confuso pero está permitido y no es una mala práctica.

A diferencia de las llaves primarias, las llaves foráneas pueden contener duplicados y permiten valores NULL.

Ningún índice es automáticamente creado para las llaves foráneas. Tú como buen DBA (Administrador de Bases de Datos) tienes que definirlos.

Una tabla puede tener múltiples llaves foráneas.

Encontrando llaves primarias y foráneas en el Explorador de Objetos.

Cuando usas Microsoft SQL Server Management Studio (SSMS), puedes ver claramente las llaves primarias, son las columnas que tienen las llaves doradas a su costado.

Si has definido un «constraint» de tipo llave foránea, esas columnas tendrán FK luego del nombre do columna. En la imagen de arriba están dentro de un círculo verde.

Restricciones de llaves foráneas o Foreign Key Constraints.

Algunos sistemas de bases de datos permiten establecer foreign key constraints. Ayudan a asegurar la integridad referencial. Evitan que puedas ingresar valores que no se encuentren en la llave primaria de la tabla relacionada.

Estos «constraints» funcionan de la siguiente manera:

• Evitan que puedas cambiar el valor de una llave foránea a uno que no exista como un valor en la llave primaria de la tabla relacionada.
• Evitan que borres un registro de la tabla de la llave primaria. Lo cual evita crear registros huérfanos. Registros huérfanos son registros hijos que no tienen padres.
• Evitan que agregues un valor a la llave foránea que no exista en la llave primaria.

En conclusión, las restricciones hacen cumplir las reglas de la relación de llaves primarias y llaves foráneas.

Tabla comparativa.

Item	Llave primaria	Llave foránea
1 o más columnas	Sí	Sí
Permite duplicados	No	Sí
Permite NULL	No	Sí
Identifica una fila de manera única	Sí	Quizás
Número permitido por tabla	1	1 o más
Indexado	Automáticamente	No se crea ningún índice automáticamente

Escrito por essentialSQL ver artículo aquí.

Mejora el rendimiento optimizando las consultas de ASP.NET Identity y otros proveedores de membresías.

Si tu aplicación utiliza ASP.NET Identity u otros sistemas de membresías tales como SQL, Universal o membresía simple, probablemente has tenido el siguiente problema.

Si utilizas ASP.NET Identity 2.x, la consulta para obtener el perfil utiliza la función UPPER() en el nombre de usuario, esto causa que los índices de nombre de usuario sean ignorados.

La solución es agregar una columna calculada (computed column) con la llamada a UPPER(username) y un índice sobre ese campo. Esto es extremadamente efectivo en mejorar el rendimiento y no requiere más cambios a la aplicación o actualizar el ASP.NET Identity Framework.

Aquí hay un ejemplo de los comandos SQL que necesitarías ejecutar en la base de datos (la tabla y los nombres de las columnas podrían ser diferentes en tu aplicación).

SQL Query para ASP.NET Identity 2.1

ALTER TABLE dbo.AspNetUsers
 ADD NormalizedName AS UPPER(UserName);

CREATE NONCLUSTERED INDEX
 [IX_NormalizedName] ON [dbo].[AspNetUsers] ([NormalizedName] ASC);

Si utilizas ASP.NET Universal Providers, la consulta para obtener los valores del perfil utiliza la función LOWER() en nombre de usuario. Tienes que hacer lo siguiente.

SQL Query para ASP.NET Universal Provider.

ALTER TABLE dbo.Users
 ADD NormalizedName AS LOWER(Username);

CREATE NONCLUSTERED INDEX
 [IX_NormalizedName] ON [dbo].[Users] ([NormalizedName] ASC);

Nota:

Aunque lo hemos hecho para Username, el mismo principio debería aplicar para otras columnas donde hagas muchas consultas.

Puedes usar LOWER() o UPPER() basado en que queries están siendo ejecutados.

Puedes seguir los mismos pasos para SQL Membership y Simple Membership también.

Los clientes han visto significativas mejoras en rendimiento con esta solución, recomendamos que las hagas en tu aplicación.

.NET Web Development and Tools Blog – Pranav Rastogi.

Descargar SQL Express.

Hay un artículo muy divertido sobre como descargar SQL Express en 12 pasos, puedes verlo aquí (en inglés). Fue escrito por Long Zheng .

En el artículo Long Zheng menciona que a pesar que el equipo que hace Microsoft SQL Server ha logrado muchas metas, una de ellas parece que es hacer difícil poder descargar dicho software.

Anteriormente el equipo ha utilizado una confusa estrategia para los nombres de los archivos. Este año con SQL Server 2014 han hecho su mejor trabajo. Aquí están los pasos:

1. En la página web de SQL Server tienes que adivinar que lo que quieres hacer es «evaluar» SQL Server 2014 Express.
2. Sigue una página que muestra 5 enlaces cada uno con su botón de «Descarga». Cada uno de los botones enlaza el mismo lugar. (Y no es el lugar donde está la descarga todavía).
3. Llegamos a otra página que todavía no es la página para la descarga pero hay un botón verde que indica que estamos en el camino correcto. También tienes otra oportunidad para leer sobre todas las versiones de SQL Express en caso que hayas cambiado de parecer hace un segundo.
4. Tienes que ingresar con tu usuario y clave de una cuenta Microsoft.
5. Aparece un formulario con tu nombre y cuenta de correo. Sin importar como igual te van a mandar correo. «Al descargar SQL Server 2014 Express podrías recibir correos de Microsoft con recursos sobre SQL Server 2014 Express», dice en la página. En la parte superior de la página hay una opción «si no quieres enviar tu información déle clic a Cancelar», parece buena idea pero te regresa a la página anterior sin poder hacer la descarga. En otras palabras es la manera de Microsoft o ninguna manera. Y no olvides cual versión de SQL Server Express querías descargar porque aquí ya no hay ninguna descripción de que versión contiene qué en la página que realmente importa.
6. Escoje si quieres la versión 32 o 64 bits, hay una opción interesante que dice «otro» pero no tenemos idea que es ni nos importa.
7. Luego otra página que te pregunta que lenguaje quieres. Es interesante saber que la opción «Chino (simplificado» está por defecto. Debería ser «Inglés» pero que le vamos a hacer.
8. Nuevo mensaje de diálogo, Hay que descargar Akamai. ¿Por qué no podemos hacer una descarga normal HTTP en un servidor web normal?
9. Ajá pensaste que ya estabas descargando SQL Server, ahora estás descargando Akamai NetSession. Y «my_downloader_installer.exe» realmente suena como un virus o malware.
10. Ahora hay que aceptar la licencia de Akamai NetSession.
11. De seguro la sospechosa aplicación quiere tener acceso a Internet. Así que hay que darle clic en «Permitir».  Luego te pregunta (por fin) donde quieres poner la descarga de SQL Server Express mostrándote una ventana de diálogo Windows para salvar.
12. Increíble luego de descargar el gran «descargador», tenemos que ver el progreso de la descarga en una página web.

Descargar SQL Server Express es innecesariamente difícil, y lo han hecho más difícil con el nuevo Centro de Descargas y la interfáz para descargar múltiples archivos que no incluye descripciones o alguna recomendación de que archivos descargar porque son importantes. Debería ser una lista de enlaces donde puedas darle clic derecho y «Guardar como…».

Introduciendo http://downloadsqlserverexpress.com (este enlace va directo al artículo de Scott Hanselman)

Descargar SQL Server 2014 Express.

• Probablemente querrás descargar SQL Server 2014 Express con herramientas. Esta descarga incluye SQL Management Studio.
  • SQL Server 2014 Express x64
  • SQL Server 2014 Express x86
• Aquí sólo SQL Server 2014 Management Studio.
  • SQL Management Studio x64
  • SQL Management Studio x86
• SQL Server 2014 Express with Advanced Services.
  • Advanced Services x64
  • Advanced Services x86

Descargar SQL Server 2012 Express.

• Probablemente querrás descargar SQL Server 2012 con herramientas. Esta descarga incluye SQL Management Studio.
  • SQL Server 2012 Express x64
• Aquí sólo SQL Server 2012 Management Studio.
  • SQL Management Studio x64
  • SQL Management Studio x86

Descargar SQL Server 2008 Express R2 SP2.

• Probablemente querrás descargar SQL Server 2008 Express con herramientas. Esta descarga incluye SQL Management Studio
  • SQL Server 2008 Express x64
  • SQL Server 2008 Express x86
• Aquí sólo SQL Server 2008 Management Studio.
  • SQL Management Studio x64
  • SQL Management Studio x86

Extraído del Blog de Scott Hanselman.

SQL Server, pregunta de entrevista: ¿Cuáles son las diferencias entre @@IDENTITY, SCOPE_IDENTITY() e IDENT_CURRENT()?

Este artículo aplica a SQL Server. Explicaremos como obtener el último valor identity usando la variable @@IDENTITY y las funciones SCOPE_IDENTITY() e IDENT_CURRENT().

@@IDENTITY y SCOPE_IDENTITY() devuelven el último valor identity que es producido en una sola sesión (o conexión). IDENT_CURRENT() devuelve el último valor identity de acuerdo a una tabla para cualquier sesión.

@@IDENTITY

Devuelve el último valor identity generado para una tabla en la sesión actual. Esta tabla puede ser cualquier tabla de la base de datos. En otras palabras @@IDENTITY tiene un alcance global  en la base de datos para obtener el último valor identity, este valor es generado para cualquier tabla. Está limitado a la sesión actual pero no límitado en el alcance actual.

Ejemplo: Tenemos 2 tablas UNIT y SUBUNIT. La tabla UNIT tiene un «trigger» de INSERT que inserta un registro a la tabla SUBUNIT. Ahora inserta un registro a la tabla UNIT el «trigger» será ejecutado e insertará un registro en la tabla SUBUNIT también. Si revisamos el valor de @@IDENTITY será el identity de SUBUNIT en vez del de la tabla UNIT.

SCOPE_IDENTITY()

Devuelve el último valor identity generado para una tabla particular en la sesión actual. No está limitado a la sesión actual pero está limitado en el alcance actual.

Ejemplo: Tenemos dos tablas UNIT y SUBUNIT. La tabla UNIT tiene un «trigger» de INSERT que inserta un registro a la tabla SUBUNIT. Ahora inserta un registro a la tabla UNIT el «trigger» será ejecutado e insertará un registro en la tabla SUBUNIT también. Si revisamos el valor de SCOPE_IDENTITY() será el identity de UNIT en vez del de la tabla SUBUNIT.

IDENT_CURRENT()

Devuelve el último valor identity generado por cualquier tabla que es pasada como parámetro a esta función. No está limitado a la sesión actual o al alcance actual. Pero está limitado a una tabla, en otras palabras, depende de la tabla que se pase como parámetro.

IDENT_CURRENT('nombre_de_la_tabla');

Conclusión.

Ambos @@IDENTITY y SCOPE_IDENTITY devolverán el último valor identity en la sesión actual pero son diferentes en su alcance. IDENT_CURRENT() no depende de la sesión actual o en alcance actual.

Extraído de CodeProject.

Google, LinkedIn, Twitter y Facebook se unen para modernizar MySQL.

Google cambió completamente el mundo de las bases de datos cuando publicó un documento de investigación describiendo «Big Table» o tabla grande, un sistema que construyó para almacenar información para su imperio en línea.

Fue lanzado en el 2006, el documento reveló un enfoque del almacenamiento de datos que descarta el modelo tradicional utilizado por las bases de datos relacionales (almacenar en filas y columnas en una sóla máquina). Básicamente Big Table hace más fácil la propagación de los datos en cientos o miles de servidores. Junto con el documento que publicó Amazon sobre sus propias aventuras en almacenamiento de datos, el concepto de Big Table dio origen a docenas de imitadores de código abierto. Estas bases de datos «NoSQL» juegan un rol dentro de firmas grandes de la web y más allá, incluyendo Facebook, LinkedIn y Twitter así como Google.

Pero la necesidad de bases de datos relacionales a la manera antigua no desapareció. Hasta este día, las compañías web todavía dependen de la base de datos de código abierto MySQL y sus variantes como MariaDB. Hay casos donde tiene sentido almacenar los datos en filas y columnas, para que puedan ser recuperados rápidamente. A causa de operaciones tan grandes, tales compañias necesitan también de formas de ejecutar estas bases de datos en muchos servidores.

Ésa es la razón por la que Facebook, LinkedIn, Twitter y Google se han juntado para crear lo que ellos llaman WebScaleSQL, una versión personalizada de MySQL, diseñada para compañías web de gran escala. Los cambios a la base de datos serán código abierto, lo que significa que serán libremente compartidas con todo el mundo y el plan de las compañías es contribuir sus cambios de regreso al projecto original MySQL. Steaphan Greene de Facebook comenta «Nuestra meta en lanzar WebScaleSQL es permitir a los miembros orientados a escala de la comunidad MySQL, trabajar de manera más cercana juntos para poder priorizar los aspectos que son más importantes para nosotros».

El projecto es un gran ejemplo de como el código abierto puede ayudar a los competidores trabajar juntos para resolver problemas. Facebook, LinkedIn y Twitter ya colaboran con muchas otras compañías en el proyecto Hadoop, una forma de analizar grandes cantidades de datos. El hacer que Google se una a la mesa es una gran ventaja.

Extraído de Wired por Klint Finley.

SQL Server 2014 ya está en RTM.

Microsoft SQL Server 2014 está en RTM (Released To Manufacturing) desde el 18 de marzo. Estará disponible para los clientes el 1ro de abril.

La nueva característica es que tiene capacidad OLTP (Online Transaction Processing) en memoria, lo cual puede mejorar el rendimiento de la base de datos hasta 30 veces (no 30%, 30 veces), sin cambiar el código existente de las aplicaciones o el hardware. Esta característica tiene el nombre código «Hekaton».

Según Paul Larson, un investigador, con modelos de bases de datos tradicionales la data vive en disco y es almacenado en páginas de disco. Esto crea un mayor costo a la hora de acceder los registros. Cuando la data vive totalmente en memoria, se pueden usar estructuras de datos más simples.

SQL Server 2014 fue diseñado para sacar copias de seguridad de manera más simple y sin interrupciones en Windows Azure (nube de Microsoft), permitiendo respaldar los datos de sus instalaciones hacia la nube a nivel de instancia con propósitos de recuperación en caso de desastres. La copia de respaldo puede ser automática o manual y una copia de seguridad puede ser restaurada en un máquina virtual en Windows Azure, si se llegara a necesitar.

Aquí hay un vídeo explicando lo que Hekaton puede hacer.

Nota: Sólo la versión «Enterprise» de SQL Server 2014 incluye Hekaton.

Extraído de ZDnet por Mary Jo Foley

¿Habrá una continuación para NoSQL?

El título es un juego de palabras en inglés SQL se pronuncia «sequel» que significa secuela más información aquí.

La reciente noticia que MongoDB Inc. aseguró un inversión de capital de $150 millones, subraya el hecho de que las bases de datos «open source» o de código libre ya no están en su infancia.

De hecho juzgando por los nombres de los inversionistas es justo decir que estas fuentes de datos de código libre han pasado a la fase final de la adolescencia. No están completamente maduras pero muy pronto lo estarán. Y Wall Street está apostando que algún día lanzará piedras lo suficientemente grandes como para dañar a los gigantes como IBM y Oracle.

El camino a la adultez de NoSQL no sido del todo suave.

En el año 2010 hubo un serio problema cuando «Foursquare» dejó de funcionar por 11 horas seguidas. Esto se debió a un problema con el balance de carga y escalamiento de MongoDB.

El entonces Director de Operaciones de Foursquare  publicó un artículo y explicación técnica con el título «So, that was a bummer.» «Eso fue decepcionante». El CTO de 10gen (la compañía cambió de nombre a MongoDB, Inc este año), condujo un riguroso análisis de qué salió mal con el código y una discusión sobre las correcciones necesarias como consecuencia para los desarrolladores de MongoDB en todo el mundo.

Las razones exactas son complicadas pero simplificándolo Foursquare no pudo mantener el crecimiento de los datos de sus clientes. El equipo falló en planear adecuadamente ese crecimiento y la implementación de MongoDB tenía fallas profundas.

Para agosto del 2010, Foursquare tenía más de 3 millones de usuarios pero solo 32 empleados. La compañía tenía cerca de un año de edad. Bienvenidos al extraño y sorprendente mundo de la codificación de los datos del siglo 21.

En la era de las aplicaciones distribuidas y datos en tiempo real, el camino hacia un millón de clientes puede suceder en un latido del corazón. A eBay y a AOL le tomó años llegar a su primer millón de clientes; Instagram alcanzó el mismo logro en unos cuantos meses. Escalar aplicaciones y datos no es un problema nuevo. Lo que es nuevo es el corto intervalo de tiempo para hacerlo bien.

Tres años después del problema de Foursquare, MongoDB ha emergido como el claro líder del movimiento NoSQL. Cisco y Craiglist lo están usando y también Shutterfly y McAfee. Hoy, la compañía MongoDB, Inc. está valorada en más de un billón de dólares – nada mal para una empresa «startup» que se alimenta de la innovación del código libre.

A la fecha tiene más de 5 millones de descargas y ese número crece en 150,000 al mes. Alrededor de MongoDB hay muchos otros jugadores no-relacionales, incluyendo Cassandra, HBase, CouchDB y Riak. En términos de tecnología, estos sistemas NoSQL comparten características comunes.

Generalmente, todas son no-relacionales, código libre, amistosos con los «clusters», no tienen esquemas y son construidos para el siglo 21 de la computación web. Todos tratan de tener un pedazo de una industria de $30 billones. Sólo porque el código es generalmente gratuito no significa que el espacio de NoSQL es una caridad. El valor real no está en el código pero en el conocimiento requerido para ejecutarlo a una escala masiva.

Lo que las compañías y desarrolladores se están dando cuenta es que cuando se trata de ejecutar aplicaciones con datos intensivos todo lo que importa es el rendimiento. No sólo del código pero también de la arquitectura y hardware.

Conforme estos ecosistemas de NoSQL evolucionen una clase de selección natural se producirá. Algunos sabores de NoSQL saldrán del mapa y otros se acelerarán. Las empresas demandarán más de sus socios NoSQL, incluyendo herramientas para que el escalamiento sea más fácil y eficiente.

Una plataforma como MongoDB tiene una gran demanda porque permite a los desarrolladores usar estructuras de datos nativas en muchos populares lenguajes de codificación. Los desarrolladores prefieren codificar que ponerse el sombrero del DBA (Administrador de Base de Datos) y preocuparse de cosas como escalamiento. Con MongoDB, el escalamiento automático y balance de carga de los datos está esencialmente cableado en la plataforma. Es fácil ver porqué los desarrolladores lo aman.

Pero hay una sutil distinción entre escalamiento automático (parte del diseño) y escalamiento automatizado (sucede sin intervención del usuario). Y esto es donde la siguiente gran fase de innovación de NoSQL está sucediendo, muy debajo de la aplicación.

MongoDB automáticamente soporta escalamiento horizontal o «sharding». Por defecto el balanceador de carga moverá trozos de datos para balancear la carga de trabajo entre el «cluster» de «shards». A MongoDB no le preocupa si estos «shards» residen en servidores «físicos», «virtuales» o en la «nube» pero a tus clientes le importará.

Resulta que los servidores virtualizados de la nube pública o «barata» no equiparan el rendimiento que la expansión de datos de NoSQL requieren. Sin un método para automatizar el escalamiento horizontal  de los dato conforme van creciendo en una infraestructura de nube, te encontrarás persiguiendo infinitamente los datos.

Entonces, ¿cómo una aplicación obtiene la escalabilidad de la nube pero el rendimiento de servidores físicos? Este es el Santo Grial (Holy Grail) de los datos en el mundo de la computación. Las buenas noticias es que algunos proveedores están haciendo serios esfuerzos por encontrarlo.

De seguro es posible construir una nube privada y mantener todos los datos detrás de tu propio firewall pero a menos que te guste construir centros de datos masivos, es probable que no encuentres un inversionista o aprobación del CFO (Jefe de Finanzas). Aquí es donde una nueva generación de proveedores de «datos-como-servicio» aparecen. Están haciendo la ingeniería de cada capa de la pila – desde el núcleo (kernel) hasta las unidades de disco pasando por el sistema de archivos – todo para optimizar el rendimiento de los datos.

MongoDB por ejemplo, están desarrollando herramientas para automatizar la selección de la clave correcta de «shard» (el separador de las cargas de trabajo de datos) y están automáticamente añadiendo «shards» pre-aprovisionados para el «cluster» conforme los datos crecen. Piensa de este nuevo modelo como usar una clase de «unidad de capacidad contenida».

Donde difiere de la nube tradicional es que no utiliza la forma de «un-tamaño-para-todos». En vez de eso toma un manera super-personalizada para desplegar una unidad de escalabilidad que tiene las características de rendimiento de los más poderosos servidores físicos. Estos nuevos proveedores también entienden que muchas aplicaciones se basan igualmente en el lado relacional y NoSQL del mundo de los datos, ellos están construyendo formas para unir los 2 reinos y que permanezcan sincronizados. Finalmente entenderán el hecho que NoSQL y MySQL han sido siempre aliados y no enemigos jurados.

Si hay una secuela para NoSQL, es tener la promesa de escalamiento integrado y recuperación de masivas cantidades de datos inmediatamente, cumplida. La línea entre la infraestructura y la tecnología de base de datos en sí misma continua siendo borrosa. El contenedor de capacidad de datos se volverá la unidad de ingeniería, no el servidor.

En mi libro, esa es una secuela que vale la pena mirar.

Extraído de The Next Web por Kenny Gorman

Funciones de Fecha útiles en SQL Server.

1. Para obtener el día de hoy.

SELECT GETDATE() 'Hoy'

2. Para obtener el día de ayer.

SELECT DATEADD(d,-1,GETDATE()) 'Ayer'

3. Inicio del día actual.

SELECT DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0) 'Inicio de este día'

4. Fin del día actual

SELECT DATEADD(ms,-3,DATEADD(dd,DATEDIFF(dd,0,GETDATE()),1)) 'Fin de este día'

5. Inicio de ayer.

SELECT DATEADD(dd,DATEDIFF(dd,0,GETDATE()),-1) 'Inicio de ayer'

6. Fin de ayer.

SELECT DATEADD(ms,-3,DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0)) 'Fin de ayer'

7. Primer día de la semana actual.

SELECT DATEADD(wk,DATEDIFF(wk,0,GETDATE()),0) 'Primer día de la semana actual'

8. Último día de la semana actual.

SELECT DATEADD(wk,DATEDIFF(wk,0,GETDATE()),6) 'Último día de la semana actual'

9. Primer día de la semana pasada.

SELECT DATEADD(wk,DATEDIFF(wk,7,GETDATE()),0) 'Primer día de la semana pasada'

10. Último día de la semana pasada.

SELECT DATEADD(wk,DATEDIFF(wk,7,GETDATE()),6) 'Último día de la semana pasada'

11. Primer día del mes actual.

SELECT DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0) 'Primer día del mes actual'

12. Último día del mes actual.

SELECT DATEADD(ms,-3,DATEADD(mm,0,DATEADD(mm,DATEDIFF(mm,0,GETDATE())+1,0))) 'Último día del mes actual'

13. Primer día del mes pasado.

SELECT DATEADD(mm,-1,DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0)) 'Primer día del mes pasado'

14. Último día del mes pasado.

SELECT DATEADD(ms,-3,DATEADD(mm,0,DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0))) 'Último día del mes pasado'

15. Primer día de este año.

SELECT DATEADD(yy,DATEDIFF(yy,0,GETDATE()),0) 'Primer día de este año'

16. Último día de este año.

SELECT DATEADD(ms,-3,DATEADD(yy,0,DATEADD(yy,DATEDIFF(yy,0,GETDATE())+1,0))) 'Último día de este año'

17. Primer día del año pasado.

SELECT DATEADD(yy,-1,DATEADD(yy,DATEDIFF(yy,0,GETDATE()),0)) 'Primer día del año pasado'

18. Último día del año pasado.

SELECT DATEADD(ms,-3,DATEADD(yy,0,DATEADD(yy,DATEDIFF(yy,0,GETDATE()),0))) 'Último día del año pasado'

19. Primer día del próximo mes.

SELECT DATEADD(mm,1,DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0)) 'Primer día del próximo mes'

20. Último día del próximo mes.

SELECT DATEADD(ms,-3,DATEADD(mm,DATEADD(mm,(DATEDIFF(mm,0,GETDATE()),0))) 'Último día del próximo mes'

Extraído de CodeProject