Gracias Carlos!, Habia pensado en hacer algo asi, pero nunca se cuan rapido es SQL y si es necesario hacer este tipo de cosas..
Saludos!, Diego -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Adolfo Codesido Sent: Domingo, 03 de Junio de 2007 13:36 To: Diego Jancic Subject: [dbms] RE: [dbms] RE: [dbms] Diseño en Performance Hola! Yo realizaría una tabla similar donde almacenaría a los usuarios que están logueados en ese momento y la otra histórica donde se almacenarán todos los registros de usuarios logueados, de esta manera tendrías una tabla con una cantidad de registros sensiblemente menor para consultar los usuarios activos. Saludos. Carlos Codesido Diego Jancic escribió: > > Hola Daniel, > > Gracias por la respuesta, pero el log no va a tener 3 campos como > decis, sino que deberia tener otros 3 o 4 campos int que indiquen > Donde, Para Que, etc.. > > El tema de los cubos es una muy buena idea, ya que lo normal va a ser > consultar estadisticas cada 6 meses que incluyan todos los campos del Log. > > En fin, muchas gracias!, > > Diego > > ------------------------------------------------------------------------ > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On Behalf Of *Daniel > Aisenberg > *Sent:* Domingo, 03 de Junio de 2007 12:28 > *To:* Diego Jancic > *Subject:* [dbms] RE: [dbms] Diseño en Performance > > Con el volumen de datos que decís no hay ningún problema. > > La tabla puede ser > > Dbo.Logs( idUsuario int, Entrada datetime not null, Salida datetime > null ) > > O sea unos 22 bytes por registro. > > En 2 años de registro ocupa unos 0,6 gigabytes. > > Estoy pensando que si Salida is null entonces está logueado. > > Podes crear un indice con idUsuario, Entrada > > O Entrada, idUsuario > > O ambos > > Pero: si por Entrada, te va a traer 25 o 26 millones de filas, el > índice no es de mucha ayuda o directamente estorba; salvo que traigas > períodos menores. > > Traer 26 millones de filas siempre va a tardar algùn tiempo más o > menos significativo, pero la estadística de quiénes se loguearon los > últimos 2 meses y cuanto tiempo estuvieron logueados, no creo que sea > el tipo de función donde el tiempo sea lo más crítico del universo. Si > tarda un minuto en armarla no creo que los gerentes se suiciden (o te > maten). Se puede emplear ese minuto para algo constructivo, como ser: > pensar para qué les puede ser útil semejante consulta. ;-) > > Si no, tendrías que mantener información resumida, tipo cubos o algo > por el estilo, para que la consulta sea instantánea. > > Saludos > > Daniel > > -----Mensaje original----- > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Diego Jancic > *Enviado el:* Sábado, 02 de Junio de 2007 03:14 a.m. > *Para:* Daniel Aisenberg > *Asunto:* [dbms] Diseño en Performance > > Hola gente! > > Estamos en el laburo empezando un nuevo proyecto y hay una parte en > donde hay un log de usuarios logueados (cuando se loguea y cuando se > desloguea). > > Esa información va a crecer muy rapido por la naturaleza de ser un log > (puede llegar a crecer unos 50000 registros por dia y si todo va muy > bien mejor aun..), y adicionalmente tiene que poder ser consultable > para saber quien esta logueado en ese momento de forma rapida. Tambien > tiene que ser viable hacer una estadistica de un periodo de 6 meses > (maximo) sin que se muera. > > La pregunta no apunta a saber como optimizarlo, sino a saber si > SQLServer puede ser configurado para trabajar con tanta info despues > de 2 años (calculemos unos 25 millones de registros). > > Puedo confiar en que contratando a un buen DBA eso se va a poder > dividir en diferentes archivos y hacer lo necesario para que funcione > bien o es conveniente copiar la información a otro lugar (otra tabla u > otra DB) y realizar las consultas hacia ahí Básicamente lo necesito > para contemplar esa logica adicional en la aplicación. > > Una pequeña información de cuales serian las tecnicas para optimizarlo > seran bienvenidos. > > Muchas Gracias, > > Diego > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.8.6/828 - Release Date: > 01/06/2007 11:22 a.m. >
