Millones de Registros

Si alguien ha tenido experiencia o tiene, en una base de datos que soporten
tablas de millones de registros, me gustaría preguntaros lo siguiente:

Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
principio una serie de tablas van a tener millones de registros, en torno a
10 millones anuales. Cada registro puede tener 175bytes en datos. En 10 años
y sólo por la tabla de marras me sale: 175x10.000.000x10/1024/1024/1024 =
16'3 Gigas.

El hardware no será problema, admito tambien sugerencias para el servidor,
procesador, memoria, sistema de redundacia de discos duros, etc.

Las preguntas son relativas al diseño de la base de datos. ¿Parto la tabla
por años, es decir, 10 tablas en 10 años?, no hace falta porque lo va a
soportar?

Opción de trasapaso a históricos desde el programa y traspaso lo que el
usuario desea a otra base de datos, sólo para consultas? En caso de esto,
aqui se me plantean tambien las mismas interrogantes que antes.

Bueno, creo que ya veis por donde voy.

Lo que no quisiera es desarrollar algo en base a un diseño malo, y después
cuando ya tengan un montonal de registros y empiecen los problemas,
solucionarlos en caliente con prisas, sin poder para el aplicativo, etc.

Gracias por vuestro tiempo y en espera de vuestras sugerencias...

Un saludo

Si alguien ha tenido experiencia o tiene, en una base de datos que
soporten tablas de millones de registros, me gustaría preguntaros lo
siguiente:

Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
principio una serie de tablas van a tener millones de registros, en torno
a 10 millones anuales. Cada registro puede tener 175bytes en datos. En 10
años y sólo por la tabla de marras me sale:
175x10.000.000x10/1024/1024/1024 = 16'3 Gigas.

El hardware no será problema, admito tambien sugerencias para el servidor,
procesador, memoria, sistema de redundacia de discos duros, etc.

Las preguntas son relativas al diseño de la base de datos. ¿Parto la tabla
por años, es decir, 10 tablas en 10 años?, no hace falta porque lo va a
soportar?

Opción de trasapaso a históricos desde el programa y traspaso lo que el
usuario desea a otra base de datos, sólo para consultas? En caso de esto,
aqui se me plantean tambien las mismas interrogantes que antes.

Bueno, creo que ya veis por donde voy.

Lo que no quisiera es desarrollar algo en base a un diseño malo, y después
cuando ya tengan un montonal de registros y empiecen los problemas,
solucionarlos en caliente con prisas, sin poder para el aplicativo, etc.

Gracias por vuestro tiempo y en espera de vuestras sugerencias...

Un saludo

Ese número de registros no será ni de lejos tan determinante como el
diseño de tu aplicación, yo si estoy manejando ese tamaño sin mayores
problemas, no obstante, recuerda que en SQL Server 2005 si tienes tablas
particionadas que podrían ayudar a mucho tipo de consultas.

Diseña la política de acceso a esa tabla siempre a través de
procedimientos almacenados, repasa que si haces joins, orders by o wheres
en esa tabla que esté correctamente indexado y deja a SQL el resto del
trabajo.


Miguel Egea Gómez

SQLServer MVP

Director de Servicios Corporativos

Solid Quality Learning Iberoamericana



"Solid Quality Learning es el proveedor global en el que puede confiar
para obtener soluciones y educación avanzada para la plataforma completa
de sistemas de bases de datos de Microsoft."

www.SolidQualityLearning.com

"Alf" escribió en el mensaje
news:%

Si alguien ha tenido experiencia o tiene, en una base de datos que
soporten tablas de millones de registros, me gustaría preguntaros lo
siguiente:

Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
principio una serie de tablas van a tener millones de registros, en torno
a 10 millones anuales. Cada registro puede tener 175bytes en datos. En 10
años y sólo por la tabla de marras me sale:
175x10.000.000x10/1024/1024/1024 = 16'3 Gigas.

El hardware no será problema, admito tambien sugerencias para el
servidor, procesador, memoria, sistema de redundacia de discos duros,
etc.

Las preguntas son relativas al diseño de la base de datos. ¿Parto la
tabla por años, es decir, 10 tablas en 10 años?, no hace falta porque lo
va a soportar?

Opción de trasapaso a históricos desde el programa y traspaso lo que el
usuario desea a otra base de datos, sólo para consultas? En caso de esto,
aqui se me plantean tambien las mismas interrogantes que antes.

Bueno, creo que ya veis por donde voy.

Lo que no quisiera es desarrollar algo en base a un diseño malo, y
después cuando ya tengan un montonal de registros y empiecen los
problemas, solucionarlos en caliente con prisas, sin poder para el
aplicativo, etc.

Gracias por vuestro tiempo y en espera de vuestras sugerencias...

Un saludo

Gracias a ambos por la temprana respuesta.

Según te entiendo Miguel, en principio, no me hace falta partir las

sino aplicarme en que los accesos estén bien realizados.

No tengo nada de experiencia con Sql Server 2005, ¿es mucho cambio?, lo
comento porque entre hablar con el cliente de la aplicación a desarrollar,
preparar el diseño de la base de datos e iniciarlo, no voy a tener mucho
tiempo de aprendizaje, si queremos cumplir plazos.

Po ello pregunto, ¿es mucho cambio? o ¿se puede afrontar porque las

no cambian la forma de trabajar?

un saludo.


"Miguel Egea" escribió en el mensaje
news:%
> Ese número de registros no será ni de lejos tan determinante como el
> diseño de tu aplicación, yo si estoy manejando ese tamaño sin mayores
> problemas, no obstante, recuerda que en SQL Server 2005 si tienes tablas
> particionadas que podrían ayudar a mucho tipo de consultas.
>
> Diseña la política de acceso a esa tabla siempre a través de
> procedimientos almacenados, repasa que si haces joins, orders by o

> en esa tabla que esté correctamente indexado y deja a SQL el resto del
> trabajo.
>
>
> Miguel Egea Gómez
>
> SQLServer MVP
>
> Director de Servicios Corporativos
>
> Solid Quality Learning Iberoamericana
>
>
>
> "Solid Quality Learning es el proveedor global en el que puede confiar
> para obtener soluciones y educación avanzada para la plataforma completa
> de sistemas de bases de datos de Microsoft."
>
> www.SolidQualityLearning.com
>
> "Alf" escribió en el mensaje
> news:%
>> Si alguien ha tenido experiencia o tiene, en una base de datos que
>> soporten tablas de millones de registros, me gustaría preguntaros lo
>> siguiente:
>>
>> Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
>> principio una serie de tablas van a tener millones de registros, en

>> a 10 millones anuales. Cada registro puede tener 175bytes en datos. En

>> años y sólo por la tabla de marras me sale:
>> 175x10.000.000x10/1024/1024/1024 = 16'3 Gigas.
>>
>> El hardware no será problema, admito tambien sugerencias para el
>> servidor, procesador, memoria, sistema de redundacia de discos duros,
>> etc.
>>
>> Las preguntas son relativas al diseño de la base de datos. ¿Parto la
>> tabla por años, es decir, 10 tablas en 10 años?, no hace falta porque

>> va a soportar?
>>
>> Opción de trasapaso a históricos desde el programa y traspaso lo que el
>> usuario desea a otra base de datos, sólo para consultas? En caso de

>> aqui se me plantean tambien las mismas interrogantes que antes.
>>
>> Bueno, creo que ya veis por donde voy.
>>
>> Lo que no quisiera es desarrollar algo en base a un diseño malo, y
>> después cuando ya tengan un montonal de registros y empiecen los
>> problemas, solucionarlos en caliente con prisas, sin poder para el
>> aplicativo, etc.
>>
>> Gracias por vuestro tiempo y en espera de vuestras sugerencias...
>>
>> Un saludo
>>
>>
>
>

Gracias a ambos por la temprana respuesta.

Según te entiendo Miguel, en principio, no me hace falta partir las
tablas, sino aplicarme en que los accesos estén bien realizados.

No tengo nada de experiencia con Sql Server 2005, ¿es mucho cambio?, lo
comento porque entre hablar con el cliente de la aplicación a desarrollar,
preparar el diseño de la base de datos e iniciarlo, no voy a tener mucho
tiempo de aprendizaje, si queremos cumplir plazos.

Po ello pregunto, ¿es mucho cambio? o ¿se puede afrontar porque las
mejoras no cambian la forma de trabajar?

un saludo.


"Miguel Egea" escribió en el mensaje
news:%

Ese número de registros no será ni de lejos tan determinante como el
diseño de tu aplicación, yo si estoy manejando ese tamaño sin mayores
problemas, no obstante, recuerda que en SQL Server 2005 si tienes tablas
particionadas que podrían ayudar a mucho tipo de consultas.

Diseña la política de acceso a esa tabla siempre a través de
procedimientos almacenados, repasa que si haces joins, orders by o wheres
en esa tabla que esté correctamente indexado y deja a SQL el resto del
trabajo.


Miguel Egea Gómez

SQLServer MVP

Director de Servicios Corporativos

Solid Quality Learning Iberoamericana



"Solid Quality Learning es el proveedor global en el que puede confiar
para obtener soluciones y educación avanzada para la plataforma completa
de sistemas de bases de datos de Microsoft."

www.SolidQualityLearning.com

"Alf" escribió en el mensaje
news:%

Si alguien ha tenido experiencia o tiene, en una base de datos que
soporten tablas de millones de registros, me gustaría preguntaros lo
siguiente:

Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
principio una serie de tablas van a tener millones de registros, en
torno a 10 millones anuales. Cada registro puede tener 175bytes en
datos. En 10 años y sólo por la tabla de marras me sale:
175x10.000.000x10/1024/1024/1024 = 16'3 Gigas.

El hardware no será problema, admito tambien sugerencias para el
servidor, procesador, memoria, sistema de redundacia de discos duros,
etc.

Las preguntas son relativas al diseño de la base de datos. ¿Parto la
tabla por años, es decir, 10 tablas en 10 años?, no hace falta porque lo
va a soportar?

Opción de trasapaso a históricos desde el programa y traspaso lo que el
usuario desea a otra base de datos, sólo para consultas? En caso de
esto, aqui se me plantean tambien las mismas interrogantes que antes.

Bueno, creo que ya veis por donde voy.

Lo que no quisiera es desarrollar algo en base a un diseño malo, y
después cuando ya tengan un montonal de registros y empiecen los
problemas, solucionarlos en caliente con prisas, sin poder para el
aplicativo, etc.

Gracias por vuestro tiempo y en espera de vuestras sugerencias...

Un saludo