Me gustaría saber...

Como bien dices, no tiene mucho sentido y menos para una cantidad de
registros tan pequeña como comentas. El particionado, en general, se suele
recomendar solo a partir de bastantes millones de registros. En todo caso
tendreis que ver también el tamaño total de dicha tabla por si incluye muchos
datos por fila (por ejemplo ficheros de gran tamaño en un BLOB) en cuyo caso
si podrías pensar en particionar incluso verticalmente si fuese necesario.

Creo que una buena estrategia de indexado en tu caso de aplicacion ERP sería
más que suficiente. Desgraciadamente quizás te comentaron eso para no tener
que indexar correctamente tu base de datos y tirar de scans completos de
particion en cada consulta.

Rubén Garrigós
Solid Quality Mentors

"msnews.micrsoft.com" wrote:

TEngo un nuevo proveedor de informática que nos va a programa el ERP.
Ayer tuvimos la primera reunión técnica y nos comentaban que querían dividir
una de las tablas principales (miles de registros anuales) en varias según
el año.
Argumentaban que esto optimiza las busquedas ya que no tiene que recorrer
todos los años de una tabla (imaginemos que 300.000 registros) y solamente
tenía que recorrer según el año (a lo mejor el año actual es de 40.000).
Lo que hace el SQL Server 2005 internamente no lo se, pero, esto no tiene
gran sentido ¿verdad?. Si indexamos la fecha y hacemos busquedas por año
(consulta)... ¿da igual que la tabla esté en una o en varias, no?
Creo que este pensamiento de dividir las tablas ahora no tiene mucho sentido
¡no?
Alguien podria darme un argumento mas técnico que pudier autilizar...
Muchas gracias.,

Hola,

El Thu, 9 Oct 2008 10:20:31 +0200, msnews.micrsoft.com escribió:

TEngo un nuevo proveedor de informática que nos va a programa el ERP.
Ayer tuvimos la primera reunión técnica y nos comentaban que querían dividir
una de las tablas principales (miles de registros anuales) en varias según
el año.

¿Dividir físicamente o lógicamente?

Si divides físicamente eso no va a afectar a las aplicaciones y es un
cambio mínimo que se puede revertir en cualquier momento o posponer hasta
que sea necesario. Lo normal es esperar hasta que sea necesario.

Si lo que proponen es dividir la tabla lógicamente, es decir que haya que
consultar diferentes tablas según el año entonces eso es una barbaridad y
sería 'pa matarlos' :-)

Argumentaban que esto optimiza las busquedas ya que no tiene que recorrer
todos los años de una tabla (imaginemos que 300.000 registros) y solamente
tenía que recorrer según el año (a lo mejor el año actual es de 40.000).

Para eso están los índices, y 300.000 es muy poco para un índice.

Lo que hace el SQL Server 2005 internamente no lo se, pero, esto no tiene
gran sentido ¿verdad?. Si indexamos la fecha y hacemos busquedas por año
(consulta)... ¿da igual que la tabla esté en una o en varias, no?

Depende, si el índice por fecha es un índice agrupado entonces da igual.

Creo que este pensamiento de dividir las tablas ahora no tiene mucho sentido
¡no?

Pues antes de empezar y teniendo previsión de tan pocos registros pues no.
Aunque una partición física con una función de partición tampoco va a hacer
daño y se puede deshacer en cualquier momento.


Saludos

Ruben, yo lo entiendo como tú... pero quería asegurarme. Con las bases de
datos relacionales y con los motores de busquedas actuales lo encuentro una
aberración...
También tengo un problema con ellos. Quieren ponerme la base de datos que
gestionará toda la empresa (ERP) en MySql Server en lugar de M.Sql. Server
2005 y entiendo que no tiene tampoco mucho sentido.
Que argumentarías sobre este tema?
Gracias.,

"Rubén Garrigós" escribió en el
mensaje news:

Como bien dices, no tiene mucho sentido y menos para una cantidad de
registros tan pequeña como comentas. El particionado, en general, se suele
recomendar solo a partir de bastantes millones de registros. En todo caso
tendreis que ver también el tamaño total de dicha tabla por si incluye
muchos
datos por fila (por ejemplo ficheros de gran tamaño en un BLOB) en cuyo
caso
si podrías pensar en particionar incluso verticalmente si fuese necesario.

Creo que una buena estrategia de indexado en tu caso de aplicacion ERP
sería
más que suficiente. Desgraciadamente quizás te comentaron eso para no
tener
que indexar correctamente tu base de datos y tirar de scans completos de
particion en cada consulta.

Rubén Garrigós
Solid Quality Mentors

"msnews.micrsoft.com" wrote:

TEngo un nuevo proveedor de informática que nos va a programa el ERP.
Ayer tuvimos la primera reunión técnica y nos comentaban que querían
dividir
una de las tablas principales (miles de registros anuales) en varias
según
el año.
Argumentaban que esto optimiza las busquedas ya que no tiene que recorrer
todos los años de una tabla (imaginemos que 300.000 registros) y
solamente
tenía que recorrer según el año (a lo mejor el año actual es de 40.000).
Lo que hace el SQL Server 2005 internamente no lo se, pero, esto no tiene
gran sentido ¿verdad?. Si indexamos la fecha y hacemos busquedas por año
(consulta)... ¿da igual que la tabla esté en una o en varias, no?
Creo que este pensamiento de dividir las tablas ahora no tiene mucho
sentido
¡no?
Alguien podria darme un argumento mas técnico que pudier autilizar...
Muchas gracias.,

El Thu, 9 Oct 2008 12:53:30 +0200, msnews.micrsoft.com escribió:

También tengo un problema con ellos. Quieren ponerme la base de datos que
gestionará toda la empresa (ERP) en MySql Server en lugar de M.Sql. Server
2005 y entiendo que no tiene tampoco mucho sentido.
Que argumentarías sobre este tema?

Yo te aconsejaría cambiar de proveedor ahora que estás a tiempo.


Saludos

Como ya te han dicho parecen ser muy pocos registros para preocuparse por
eso. Eso viene de como se acostumbraba en viejas plataformas que no eran
Cliente/Servidor donde era necesario estar dividiendo tablas por año.
No creo que haya que complicarse la vida dividiendo tablas.


"msnews.micrsoft.com" escribió en el mensaje
news:%

TEngo un nuevo proveedor de informática que nos va a programa el ERP.
Ayer tuvimos la primera reunión técnica y nos comentaban que querían
dividir una de las tablas principales (miles de registros anuales) en
varias según el año.
Argumentaban que esto optimiza las busquedas ya que no tiene que recorrer
todos los años de una tabla (imaginemos que 300.000 registros) y solamente
tenía que recorrer según el año (a lo mejor el año actual es de 40.000).
Lo que hace el SQL Server 2005 internamente no lo se, pero, esto no tiene
gran sentido ¿verdad?. Si indexamos la fecha y hacemos busquedas por año
(consulta)... ¿da igual que la tabla esté en una o en varias, no?
Creo que este pensamiento de dividir las tablas ahora no tiene mucho
sentido ¡no?
Alguien podria darme un argumento mas técnico que pudier autilizar...
Muchas gracias.,