Millones de Registros

Bueno... todoooo todo no es cierto.

Yo de hecho no puedo migrar a 2005 porque trabajamos con java y el JDK
que necesita el JDBC es 1.4 (o superior), mientras que el que nosotros
tenemos es el 1.3

Así que hasta que no actualicemos a la 1.4 (probablemente en septiembre)
seguiremos con la antigua... :(

Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Miguel Egea" escribió en el mensaje
news:uOvze$

Es un cambio impresionante, pero todo lo que funcionaba en 2000 funciona

en

2005, yo te recomendaría empezar directamente en 2005, si puedes elegir, y
en ese caso sí usaría tablas particionadas donde sea necesario. Cuentanos
más tu caso y vemos si podemos ayudarte en el diseño.


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:
> 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
>>>
>>>
>>
>>
>
>

jajaja, :) eso será cosa de java :D , llevas razón es muy complicado decir
que todo funciona y no mentir, aunque sea un poquito :).

Gracias Carlos!!
Un abrazo


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:

Bueno... todoooo todo no es cierto.

Yo de hecho no puedo migrar a 2005 porque trabajamos con java y el JDK
que necesita el JDBC es 1.4 (o superior), mientras que el que nosotros
tenemos es el 1.3

Así que hasta que no actualicemos a la 1.4 (probablemente en
septiembre)
seguiremos con la antigua... :(

Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Miguel Egea" escribió en el mensaje
news:uOvze$

Es un cambio impresionante, pero todo lo que funcionaba en 2000 funciona

en

2005, yo te recomendaría empezar directamente en 2005, si puedes elegir,
y
en ese caso sí usaría tablas particionadas donde sea necesario. Cuentanos
más tu caso y vemos si podemos ayudarte en el diseño.


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:
> 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
>>>
>>>
>>
>>
>
>

El aplicativo que tenemos que desarrollar no va a ser 100% nuevo. Parte ya
esta desarrollada y funcionando en Sql server 2000. Son programas ya en
funcionamiento, instalados en varios clientes.

El desrrollo completo de la nueva aplicación, requiere programas ya
realizados y el crear otros nuevos.

Es en lo nuevo a desarrollar donde me surgian las dudas por el tamaño
ciertas tablas.

Si 2005 es compatible, podré traspasar la base de datos de sql server 2000,
donde estan toda todo lo necesario para los programas ya desarrollados, y
después sobre
este diseño inicial, ir añadiendo las nuevas tablas, relaciones, etc.

Las tablas con millones de registros es la información de cada unidad que se
va a fabricar, donde se quiere guardar un montón de datos, cara a
trazabilidad y calidad, quién, cuando, como, donde, etc. Y con estos datos
se realizan posteriores consultas estadisiticas, por diferentes motivos,
¿cuanto frabico fulanito y menganito?, ¿cuanto compro menganito de una
caracteristica determinada?, etc.

Además estan las consultas puntuales, por quejas o reclamaciones de
clientes, rechazos interntos, etc,


Si me comentas que lo que funciona en 2000 funciona en 2005, con la
inversión que el cliente esta realizando, la diferencia de precio entre
ambas versiones no creo que sea decisoria.

Gracias por vuestras respuestas.



"Miguel Egea" escribió en el mensaje
news:uOvze$

Es un cambio impresionante, pero todo lo que funcionaba en 2000 funciona
en 2005, yo te recomendaría empezar directamente en 2005, si puedes
elegir, y en ese caso sí usaría tablas particionadas donde sea necesario.
Cuentanos más tu caso y vemos si podemos ayudarte en el diseño.


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:

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