Como ordenar una dimension por un atributo

Como ordenar una dimensión por un atributo.

Alguien me hizo la siguiente pregunta:

"Hola, quisiera saber cómo hago para ordenar mi dimensión de tiempo por el identificador, actualmente mi dimensión esta ordenada alfabéticamente y yo quisiera que el ordenamiento fuese distinto, por ejemplo, actualmente mi dimensión de tiempo se despliega así

La idea es poder desplegar la dimensión de la siguiente manera

Muchas gracias"

La solución es bastante simple en realidad, primero debemos crear la dimensión sobre la que queremos trabajar, luego simplemente vamos al atributo que deseamos ordenar

En las propiedades del atributo, buscamos la propiedad KeyColumn

Seleccionamos el atributo por el cual deseamos ordenar, para este caso es el atributo ID de la tabla MESES

Finalmente buscamos la propiedad NameColumn

Y buscamos el atributo que aparecerá como texto, para este caso es el atributo NOMBRE de la tabla MESES.

Procesamos, actualizamos y listo…

 

Saludos

Oracle compra SUN Microsystems

Es dura la realidad, pero asi es, Oracle (Larry Ellison) compro SUN, seguramente ahora destruiran a MySQL para posicionar Oracle Database Express Edition, un motor con todas las limitantes que Oracle pudo poner.

Hay cosas mas dificiles de entender y quiero que me ayuden a comprenderlas.

1. Oracle es propietario de Star Office, sin embargo ninguno de sus productos (Siebel, iFlex, Peoplesoft, Oracle Business Intelligence, etc) funcionan con Star Office…
2. Todos los empleados de Oracle usan Microsoft Office…
3. Todos los empleados de Oracle usan Microsoft Windows
4. Oracle tiene un convenio con HP para mover Exadata (Una maquina gigante, costosa y poco util en la vida practica)
5. Los servidores de Oracle corren sobre Microsoft Windows… y donde esta Enterprise Linux?
6. Que pasara con MySQL ahora, donde quedara todo el speech de MySQL hacia Oracle en temas de competencia?
7. Sera que el nuevo velero de Larry es mas grande que el actual?

Hasta pronto

Technorati Tags: Oracle,Microsystems,Larry,Ellison,MySQL,Database,Edition,Star,Office,Siebel,Peoplesoft,Intelligence,Todos,Microsoft,Windows,Exadata,Enterprise,Linux,speech,Sera,Hasta,ahora,para,empleados,usan,donde

Windows Live Tags: Oracle,Microsystems,Larry,Ellison,MySQL,Database,Edition,Star,Office,Siebel,Peoplesoft,Intelligence,Todos,Microsoft,Windows,Exadata,Enterprise,Linux,speech,Sera,Hasta,ahora,para,empleados,usan,donde

WordPress Tags: Oracle,Microsystems,Larry,Ellison,MySQL,Database,Edition,Star,Office,Siebel,Peoplesoft,Intelligence,Todos,Microsoft,Windows,Exadata,Enterprise,Linux,speech,Sera,Hasta,ahora,para,empleados,usan,donde

Blogger Labels: Oracle,Microsystems,Larry,Ellison,MySQL,Database,Edition,Star,Office,Siebel,Peoplesoft,Intelligence,Todos,Microsoft,Windows,Exadata,Enterprise,Linux,speech,Sera,Hasta,ahora,para,empleados,usan,donde

Desarrollo en SQL Server 2008

Hace poco estaba revisando unos procedimientos almacenados que tengo andando en mis bases de datos, probando las nuevas opciones de codigo de SQL Server 2008 me encontre con algo que a decir verdad me parece muy interesante, y considero importante compartirlo con ustedes.

Recuerden que en SQL Server 2005 no podiamos llegar a asignarle un valor a una variable sobre la misma linea; es decir, en SQL Server 2005 no podiamos hacer algo como esto:

  1: Declare @MiVariable int = 10;

Ahora en Microsoft SQL Server 2008, esto si es posible, eso significa que ya no tenemos que llegar a hacer cosas como:

  1: Declare @MiVariable int;
  2: Set @MiVariable = 10;

Esto no solamente nos ayuda en la reduccion de lineas de codigo, sino que tambien nos habilita opciones como +=, de esta manera podriamos llegar a hacer cosas como:

  1: Declare @MiVariable int = 10;
  2: Set @MiVariable += 7;

Esto nos abre una gran cantidad de opciones en temas de desarrollo dentro de SQL Server 2008.

Saludos

Comprimir o no comprimir, esa es la cuestion

Muchas personas preguntan acerca de las ventajas de comprimir, muchos quieren saber si deben o no deben comprimir sus tablas, saber con cuales ganan y con cuales no, saber si van a mejorar o si por el contrario, los algoritmos pueden jugar en su contra.

Bueno, dedique una tarde a determinar como hacer para que cualquier persona pueda saber si debe o no debe comprimir sus datos.

1. Determinemos cuanto espacio podriamos ahorrar en una tabla, para esto usaremos el procedimiento almacenado sp_estimate_data_compression_savings, con este vamos a determinar que ventajas tenemos al comprimir una tabla, para esto vamos a ejecutar el siguiente codigo

EXEC sp_estimate_data_compression_savings 
'Production', 
'TransactionHistory', 
null, null, 'ROW'

Aqui, sencillamente estamos estimando el mejoramiento que tendremos al comprimir la tabla TransactionHistory, del esquema Production.

Aqui lo que podemos leer es lo siguiente:

Por ejemplo, en el indice 1, podemos determinar que tenemos un tamano actual de 6352 KB, y podemos estimar que al comprimirlo, lograriamos un tamano de 4208 KB, que es una reduccion del 33,5%.

Ahora, podemos hacer esto una y otra vez, objeto por objeto, o podemos sentarnos unos minutos y escribir una consulta que nos permita ejecutar esto para todos los objetos, yo decidi hacerlo, y aqui lo tengo para ustedes.

   1: Create table ##tb ([object_name] varchar(500), 

   2: [schema_name] varchar(500),  

   3: [index_id] int, partition_number int,

   4: [size_with_current_compression_setting (KB)] bigint,

   5: [size_with_requested_compression_setting (KB)] bigint,

   6: [sample_size_with_current_compression_setting (KB)] bigint,

   7: [sample_size_with_requested_compression_setting (KB)] bigint)

   8: Declare @Esquema varchar(200), @Tabla varchar(200)

   9: declare Tabla_Cursor cursor for

  10: Select s.[name] Esquema, t.[name] Tabla  from sys.schemas s

  11: inner join sys.tables t on s.[schema_id] = t.[schema_id]

  12: Order by s.[name], t.[name]

  13: OPEN Tabla_Cursor

  14: Fetch next from Tabla_Cursor into @Esquema, @Tabla

  15: While @@FETCH_STATUS = 0

  16: Begin

  17:     insert ##tb 

  18:     exec sp_estimate_data_compression_savings 

  19:     @Esquema, @Tabla, NULL, NULL, @Tipo ;

  20:     Fetch next from Tabla_Cursor into @Esquema, @Tabla;

  21: End

  22: Close Tabla_Cursor

  23: Deallocate Tabla_Cursor

  24: select * From ##tb

  25: Drop table ##tb

Sin embargo debemos tener en cuenta que esto debe ser ejecutado bajo el contexto de cada base de datos.

Igualmente, senti la necesidad de hacer un reporte que nos permitiera hacer esto mucho mas rapido.

Aqui lo que podemos ver es una diferenciacion simple, de cuanto podriamos llegar a ahorrar en espacio comparando la compresion actual de su base de datos, versus la compresion seleccionada.

Si quieres descargar este reporte puedes dar clic aqui

Technorati Tags: SQL Server,Compresion de datos,Reporting Services,Database Compression

Backups comprimidos en SQL Server 2008 – Cuanto me cuesta?

Este tema ha sonado bastante recientemente, y efectivamente, como seguramente muchos de ustedes habrán escuchado, SQL Server 2008 tiene la característica de poder tener los backups comprimidos, y hacerlo es muy fácil, vamos a ver aquí de que se trata:

De que se trata?

En realidad es muy sencillo, ahora con SQL Server 2008, tenemos la opción de determinar si queremos que nuestros backups estén o no estén comprimidos, hagamos un cálculo rápido para ver de qué se trata; hoy en día estamos pagando alrededor de 50 Centavos de Dólar por cada Giga (GB) de almacenamiento, es decir, si tenemos una base de datos de 2 GB, estaríamos pagando diariamente aproximadamente 1 Dólar por el hecho de tener ese Backup, muchas organizaciones no piensan en esto y consideran que no es un tema relevante, pero veámoslo de una forma mas traumática.

Pensemos en una base de datos de Un Terabyte 1 TB, esto es bastante común en una empresa de comunicaciones, ahora, calculemos entonces cuanto nos costaría tener esa base de datos.

1 TB = 1000 GB

1 GB = 0,5 USD

1 TB = 500 USD

Hasta aquí, todo normal, para una empresa de comunicaciones seguramente 500 USD no es una cantidad significativa.

Ahora vamos a implementar un sistema de backups muy simple, una copia full cada día (Recuerden que estas empresas funcionan segundo a segundo, así que uno por día es MUY poco)

1 Día = 500 USD (Costo de almacenamiento de la copia de seguridad de la base de datos)

1 Semana = 7 Días

1 Mes = 30 Días

Pensemos ahora que ellos solo deben mantener esta copia de seguridad por 2 meses, y pensemos también que estos medios pueden ser reutilizados 4 veces (Algo que sería un milagro, normalmente estos pueden ser utilizados una sola vez).

Estamos siendo muy optimistas.

60 Días = $ 30.000 USD

1 Unidad = 4 Copias

240 Días = $ 30.000 USD

1 Año = 360 Días (Para hacerlo más fácil)

3 Años = $ 135.000 USD

Bastante dinero no?, y recuerden, esto siendo optimistas, haciéndolo con recursos que prácticamente hoy no existen, ya que las copias de seguridad se supone que deben ser almacenados en un dispositivo, y este jamás ser reutilizado.

Ahora bien, si hacemos un calculo rapido de las ventajas de tener backups comprimidos, versus el tenerlos descomprimidos, sabremos rapidamente que nos conviene mas.

Esta caracteristica esta incluida de forma GRATUITA con Microsoft SQL Server 2008 Enterprise Edition.

Project Natal for XBOX 360