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.
