¿como evitar los hot blocks?

"AntonioFox" <antoniofox> escribió en el mensaje
news:

¿Que tal?

Estaba traspasando una clasica tabla de contadores (donde llevo contador
de facturas, documentos de venta, pedidos ...) a SQL Server y leo que esta
practica no es recomendada por el problema de los hot blocks

Entonses ¿que me recomienda para no tener el problema de los hot blocks y
como hago para tambien tener mis contadores? No me valen identities ya que
nesecito que me genere numeros realez

Hola, Antonio:

Una "clásica tabla de contadores" es un "hot block", lo quieras o no.

Lo peor es estructurar la tabla así:

ProximaFactura BigInt,
ProximaEntrega Bigint,
...
ProximaX Bigint

porque cada actualización bloquea toda la tabla para todas las operaciones.

Mas sensato es:

TipoDoc char(X)
ProximoNumero Bigint,

usando bloqueos a nivel de registro (que creo que es la conducta por omisión
de SQL Server).

Los "hot blocks" son una condición inevitable, no un "problema". Los
productos más vendidos, o la fila que contiene la cuenta de caja, o de
ingresos por ventas en una aplicación de punto de ventas, por ejemplo, serán
tan "hot spot" como una tabla de contadores. El tratamiento correcto es
reducir los tiempos de bloqueo tanto como sea posible.

La optimización más extrema de los tiempos de bloqueo es la que obtienes
cuando guardas todos los datos necesarios para el registro de la operacion
en tablas temporales y luego ejecutas un procedimiento del lado del servidor
que se ocupe de realizar todo el proceso en una sola pasada.

Si desde tu aplicacion creas las tablas temporales con un nombre precedido
por "#", y si ejecutas el SP de actualización desde la misma conexión
utilizada para crear las tablas temporales, puedes usar directamente esos
nombres dentro del SP, ahorrandote la necesidad de crear dinámicamente las
consultas.

Salud!

Hola Leonardo,

El Sun, 4 May 2008 12:57:59 -0430, Leonardo Azpurua escribi?:

Mas sensato es:

TipoDoc char(X)
ProximoNumero Bigint,

usando bloqueos a nivel de registro (que creo que es la conducta por omisi??

de SQL Server).

?Y por que no hacemos un simple:

insert into tabla select max(Id) + 1 from tabla, ...

Y as? nos ahorramos la tabla de contadores.


Saludos
Alfredo

Interesante explicacion; no conocia el concepto, aunque desde mi punto de
vista me parecio simple problema de normalizacion.


saludos,

Antonio Ortiz
asesor en sistemas
www.aortiz.net
www.progvisual.com



"Alfredo Novoa" escribio en el mensaje
news:

Hola Leonardo,

El Sun, 4 May 2008 12:57:59 -0430, Leonardo Azpurua escribi?:

Mas sensato es:

TipoDoc char(X)
ProximoNumero Bigint,

usando bloqueos a nivel de registro (que creo que es la conducta por
omisi??

de SQL Server).

?Y por que no hacemos un simple:

insert into tabla select max(Id) + 1 from tabla, ...

Y as? nos ahorramos la tabla de contadores.


Saludos
Alfredo

"Alfredo Novoa" escribio en el mensaje
news:

Hola Leonardo,

El Sun, 4 May 2008 12:57:59 -0430, Leonardo Azpurua escribi?:

Mas sensato es:

TipoDoc char(X)
ProximoNumero Bigint,

usando bloqueos a nivel de registro (que creo que es la conducta por
omisi??

de SQL Server).

?Y por que no hacemos un simple:

insert into tabla select max(Id) + 1 from tabla, ...

Y as? nos ahorramos la tabla de contadores.

Hola.

Imagino que por una mala costumbre arrastrada desde los tiempos de Access:
en las pruebas de concurrencia, pulsaba Enter simultaneamente en los dos
teclados de dos equpos diferentes, y con mucha frecuencia el "proximo
numero" se duplicaba.

Supongo que esto era posible porque Access usa Jet, que maneja fisicamente
el archivo MDB desde los dos equipos, el Select(MaxID) + 1 no bloquea, y
permitia que los dos procesos obtuvieran el mismo numero.

En cualquier caso, no seria INSERT INTO Tabla ... SELECT COALESCE(MAX(Id),
0) + 1? :)

Salud!

Hola Leonardo,

On May 5, 3:30 am, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p
s [punto] o r >

En cualquier caso, no seria INSERT INTO Tabla ... SELECT COALESCE(MAX(Id),
0) + 1?  :)

Es que a Alfredo como no le gustan los null
tampoco le hace mucho caso. :-)

Saludos,
Carlos