Discussion:
Generar mi autonumerico
(demasiado antiguo para responder)
CHAR72
2008-05-21 20:02:51 UTC
Permalink
Hola compañeros! tengo cierto inconveniente que no puedo resolver. Tengo un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert de un
registro no hay inconveniente, pero ahora debo realizar varios insert y no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.

Como puedo resolver la cuestion con SQL 2000?

Saludos

Carlos
Alejandro Mesa
2008-05-21 20:23:01 UTC
Permalink
CHAR72,

Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY. Tendras que
usar un lazo / cursor e insertar las filas una por una.


AMB
Post by CHAR72
Hola compañeros! tengo cierto inconveniente que no puedo resolver. Tengo un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert de un
registro no hay inconveniente, pero ahora debo realizar varios insert y no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
CHAR72
2008-05-21 22:41:46 UTC
Permalink
Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
del sistema para ponerle IDENTITY.

Gracias
Post by Alejandro Mesa
CHAR72,
Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY. Tendras que
usar un lazo / cursor e insertar las filas una por una.
AMB
Post by CHAR72
Hola compañeros! tengo cierto inconveniente que no puedo resolver. Tengo un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert de un
registro no hay inconveniente, pero ahora debo realizar varios insert y no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
Miguel Egea
2008-05-22 08:42:10 UTC
Permalink
Si usas SQL 2005 puedes hacer un procedimiento como el siguiente y llamarlo
para obtener un identificador con tabla, tiene todos los inconvenientes y
ventas de los identities, no te obliga acambiar la estructura aunque ocupas
un schema. Si no usas SQL 2005 es adaptable. Creo que no tiene problemas de
inyección de código SQL en cualquier caso ahí tenéis las pruebas.


create schema Maestros;

go
create proc Maestros.GeneraClave (@tabla Sysname,@valor int output)
with execute as owner -- cambialo por alguien con permisos para crear tablas
de forma dinámica
as
begin
declare @sql nvarchar(4000);



if not exists(select 1 from information_Schema.tables where table_name =
@tabla and Table_schema='Maestros')
begin

set @sql = 'CREATE TABLE Maestros.'+ quotename(@tabla) + ' (id int
identity(1,1)) ' ;
exec sp_executeSQL @sql
end

if @@trancount>0
save transaction @tabla
else
begin tran

set @sql=N'SET NOCOUNT ON; INSERT INTO Maestros.'+ quotename(@tabla) + '
DEFAULT VALUES; SELECT @Valor=Scope_identity() '
exec sp_executesql @sql, N' @valor int output', @valor output

rollback tran

end
go

declare @valor int
exec Maestros.GeneraClave 'Mi tabla1',@valor output
select @valor
select * from information_schema.tables where table_schema='Maestros'
go
-- sin problemas de inyección de código.
declare @valor int
exec Maestros.GeneraClave 'Mi ] drop table Maestros.[Mi tabla1] -- ',@valor
output
select @valor
select * from information_schema.tables where table_schema='Maestros'


Saludos
Miguel Egea
Post by CHAR72
Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
del sistema para ponerle IDENTITY.
Gracias
Post by Alejandro Mesa
CHAR72,
Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY. Tendras que
usar un lazo / cursor e insertar las filas una por una.
AMB
Post by CHAR72
Hola compañeros! tengo cierto inconveniente que no puedo resolver. Tengo un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert de un
registro no hay inconveniente, pero ahora debo realizar varios insert y no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
Penta
2008-05-22 20:35:38 UTC
Permalink
Hola.
Favor que alguien me expique porque no puede hacer un max + 1

insert test select coalesce(max(testid),0)+1 From TEST

Atte.
Penta.
Miguel Egea
2008-05-23 07:54:24 UTC
Permalink
Por problemas de concurrencia.
Verás select max(text) puede ejecutarse a la vez para dos conexiones
distintas y dar el mismo resultado, y el segundo insert fallaría por clave
duplicada, la verdad es que el código que mandé puede resultar complejo
tiene truquillos , pero me pareció muy interesante de compartir.

Saludos
Post by Penta
Hola.
Favor que alguien me expique porque no puede hacer un max + 1
insert test select coalesce(max(testid),0)+1 From TEST
Atte.
Penta.
Carlos M. Calvelo
2008-05-23 09:34:03 UTC
Permalink
Hola Miguel,
Post by Miguel Egea
Por problemas de concurrencia.
Verás select max(text) puede ejecutarse a la vez para dos conexiones
distintas y dar el mismo resultado, y el segundo insert fallaría por clave
duplicada ...
Eso solo es verdad si se hace con transacciones con un isolation
level menor que serializable. Entonces dos trasacciones distintas
pueden determinar el max() con el mismo conjunto de registros y
después de que una de ellas haga un insert la otra no se dará
cuenta de una situación de 'phantom read'.

Con isolation level serializable se evitan phantom reads por medio
de locking. Esto a su vez puede resultar en un deadlock que hará
automáticamente un rollback de una de las transacciones y no será
posible obtener el mismo resultado (independientemente de si
con ello se genera un clave duplicada o no).

Saludos,
Carlos
Alfredo Novoa
2008-05-23 10:45:47 UTC
Permalink
Hola Carlos,

On Fri, 23 May 2008 02:34:03 -0700 (PDT), "Carlos M. Calvelo"
Post by Carlos M. Calvelo
Eso solo es verdad si se hace con transacciones con un isolation
level menor que serializable.
Y normalmente se debería de usar el nivel serializable.
Post by Carlos M. Calvelo
Con isolation level serializable se evitan phantom reads por medio
de locking. Esto a su vez puede resultar en un deadlock que hará
automáticamente un rollback de una de las transacciones y no será
posible obtener el mismo resultado (independientemente de si
con ello se genera un clave duplicada o no).
Y además de esto tenemos la protección de las claves primarias. Así
que en el caso de que haya un interbloqueo o una violación de clave
primaria lo único que habría que hacer es repetir la inserción.

Si el nivel de concurrencia no es enorme no hay problema por usar
Max() + 1 para obtener identificadores.


Saludos
Alfredo
Miguel Egea
2008-05-23 11:28:20 UTC
Permalink
Estais equivocados ambos por que no son lecturas fantasmas, es dificil con
un insert into select max() reproducir el problema pero es muy fácil
reproducirlo de esta forma

probad en 2 conexiones ejecutar este código

set transaction isolation level serializable
go
declare @id int
begin tran

select @id=max(id)+1 from foo
print @id
waitfor delay '00:00:10' -- esperamos 10 segundos
insert into foo select @id
commit



donde los metadatos son

USE tempdb
go
create table foo(id int primary key)
go
insert into foo select 1
go


Hay que tener muchísimo cuidado con la concurrencia,el nivel de aislamiento
serializable es realmente peligroso para el rendimiento, no por el
rendimiento y consumo en sí (que también aunque en un post no me da tiempo a
escribir por qué ese consumo ) sino por los bloqueos, me explico
Un select max() con nivel de aislamiento serializable no solamente bloquea
los registros que ya existen en la tabla sino que genera también un bloqueo
compartido de tipo range que impide que se inserte ningún número mayor, de
aquí el error de mucha gente, que impida que se inserte uno mayor que este
no quiere decir que no le pueda devolver el mismo número a los dos, de hecho
vereis que el segundo en llegar obtiene un error.

Los niveles de aislamiento son un tema muy interesante, si mal no recuerdo
en el Microsoft SQl Server 2005 Step by Step Database Essentials hablé
precisamente de este select max() como herramienta peligrosa en los
sistemas.

Espero que quede claro porqué

Saludos
Miguel Egea
Post by Alfredo Novoa
Hola Carlos,
On Fri, 23 May 2008 02:34:03 -0700 (PDT), "Carlos M. Calvelo"
Post by Carlos M. Calvelo
Eso solo es verdad si se hace con transacciones con un isolation
level menor que serializable.
Y normalmente se debería de usar el nivel serializable.
Post by Carlos M. Calvelo
Con isolation level serializable se evitan phantom reads por medio
de locking. Esto a su vez puede resultar en un deadlock que hará
automáticamente un rollback de una de las transacciones y no será
posible obtener el mismo resultado (independientemente de si
con ello se genera un clave duplicada o no).
Y además de esto tenemos la protección de las claves primarias. Así
que en el caso de que haya un interbloqueo o una violación de clave
primaria lo único que habría que hacer es repetir la inserción.
Si el nivel de concurrencia no es enorme no hay problema por usar
Max() + 1 para obtener identificadores.
Saludos
Alfredo
Miguel Egea
2008-05-23 11:36:31 UTC
Permalink
Hola Alfredo, creo que estas en un error.


El nivel de aislamiento serializalbe lo usaba por defecto las aplicaciones
com+ que accedian a datos y así funcionaban la mayoría que yo he visto, con
enormes problemas de escalabilidad.

Los phantom reads se evitan con todos los nivels de aislamiento menos con
read uncommitted, estáis en un error de concepto de lo que son phantom
reads.

El select max() en otros niveles de aislamiento dará error por Pk, un error
de pk violada es menos agresivo que un deadlock, por que un deadlock además
mata la conexión del elegido como víctima, y además el elegido como vícitma
depende del número de escrituras que lleve en la misma transacción, así que
ni siquiera sabes a priori cual elemento va a resultar eliminado (igual el
listado ese que lleva 2 horas para generarse), excepto que hayas usado la
c´lausula -escrita de memoria- Set deadlock priority.


Saludos Cordiales..
Post by Alfredo Novoa
Hola Carlos,
On Fri, 23 May 2008 02:34:03 -0700 (PDT), "Carlos M. Calvelo"
Post by Carlos M. Calvelo
Eso solo es verdad si se hace con transacciones con un isolation
level menor que serializable.
Y normalmente se debería de usar el nivel serializable.
Post by Carlos M. Calvelo
Con isolation level serializable se evitan phantom reads por medio
de locking. Esto a su vez puede resultar en un deadlock que hará
automáticamente un rollback de una de las transacciones y no será
posible obtener el mismo resultado (independientemente de si
con ello se genera un clave duplicada o no).
Y además de esto tenemos la protección de las claves primarias. Así
que en el caso de que haya un interbloqueo o una violación de clave
primaria lo único que habría que hacer es repetir la inserción.
Si el nivel de concurrencia no es enorme no hay problema por usar
Max() + 1 para obtener identificadores.
Saludos
Alfredo
Alfredo Novoa
2008-05-23 12:19:52 UTC
Permalink
Hola Miguel,

On Fri, 23 May 2008 13:36:31 +0200, "Miguel Egea"
Post by Miguel Egea
El select max() en otros niveles de aislamiento dará error por Pk, un error
de pk violada es menos agresivo que un deadlock, por que un deadlock además
mata la conexión del elegido como víctima,
Pues menuda castaña, entonces si que es preferible que te salga un
error por PK.

Un error por interbloqueo debería de resolverse de forma que no se
enterasen las aplicaciones.


Saludos
Alfredo
Miguel Egea
2008-05-23 12:48:00 UTC
Permalink
Así es, por eso la complejidad del procedure que mandé :)


De todas formas me confuncí en el post, leí lecturas sucias en lugar de
lecturas fantasmas :( mis disculpas.
Post by Carlos M. Calvelo
Hola Miguel,
On Fri, 23 May 2008 13:36:31 +0200, "Miguel Egea"
Post by Miguel Egea
El select max() en otros niveles de aislamiento dará error por Pk, un error
de pk violada es menos agresivo que un deadlock, por que un deadlock además
mata la conexión del elegido como víctima,
Pues menuda castaña, entonces si que es preferible que te salga un
error por PK.
Un error por interbloqueo debería de resolverse de forma que no se
enterasen las aplicaciones.
Saludos
Alfredo
umak
2008-05-23 18:51:03 UTC
Permalink
que idea pelotuda...
Post by Alfredo Novoa
Un error por interbloqueo debería de resolverse de forma que no se
enterasen las aplicaciones.
que la aplicacion se entere y sepa que hacer en consecuencia, incluso
ignorar el problema

chau
uyke
Alfredo Novoa
2008-05-23 19:15:14 UTC
Permalink
Post by umak
Post by Alfredo Novoa
Un error por interbloqueo debería de resolverse de forma que no se
enterasen las aplicaciones.
que la aplicacion se entere y sepa que hacer en consecuencia, incluso
ignorar el problema
¿Para que querría enterarse la aplicación de un problema que ya está
resuelto?

Si el SGBD resuelve el interbloqueo entonces la aplicación ya no tiene que
hacer nada. Para ella no existe el problema.


Saludos
umak
2008-05-23 19:29:00 UTC
Permalink
Post by Alfredo Novoa
Post by umak
que la aplicacion se entere y sepa que hacer en consecuencia, incluso
ignorar el problema
¿Para que querría enterarse la aplicación de un problema que ya está
resuelto?
Si el SGBD resuelve el interbloqueo entonces la aplicación ya no tiene que
hacer nada. Para ella no existe el problema.
el tema es que no estamos hablando de cualquier rdbms

sqlserver elige una sesion para matar y si mi aplicacion es matada por
sqlserver me gusta saberlo

chau
~gux
Gux (MVP)
2008-05-23 20:10:00 UTC
Permalink
chau
~gux
Umak, hay muchas personalidades importantes que merecen ser imitadas. La mía
no se merece tal honor. O un problema de cut&paste tal vez?

Saludos,
Umak :-)
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Alfredo Novoa
2008-05-23 20:11:36 UTC
Permalink
Post by umak
Post by Alfredo Novoa
Si el SGBD resuelve el interbloqueo entonces la aplicación ya no tiene que
hacer nada. Para ella no existe el problema.
el tema es que no estamos hablando de cualquier rdbms
Es una mejora que se le podría hacer a SQL Server.
Post by umak
sqlserver elige una sesion para matar y si mi aplicacion es matada por
sqlserver me gusta saberlo
Es fácil saberlo :-)


Saludos
umak
2008-05-23 18:47:01 UTC
Permalink
Post by Alfredo Novoa
Y normalmente se debería de usar el nivel serializable.
claro claro... tambien se puede bloquear toda la base de datos y resolvemos
la enfermedad asesinando al paciente

lo que se debe usar es un nivel que deje el resultado final COMO SI la
transaccion fuera serializable

chau
uyke
Carlos M. Calvelo
2008-05-23 19:25:28 UTC
Permalink
Post by umak
Post by Alfredo Novoa
Y normalmente se debería de usar el nivel serializable.
claro claro... tambien se puede bloquear toda la base de datos y resolvemos
la enfermedad asesinando al paciente
lo que se debe usar es un nivel que deje el resultado final COMO SI la
transaccion fuera serializable
No es precisamente ese el significado del nivel de aislamiento
serializable?
umak
2008-05-23 19:40:01 UTC
Permalink
Post by Carlos M. Calvelo
Post by umak
lo que se debe usar es un nivel que deje el resultado final COMO SI la
transaccion fuera serializable
No es precisamente ese el significado del nivel de aislamiento
serializable?
fe de erratas: s/serializable/serial

chau
uyke
Carlos M. Calvelo
2008-05-23 19:52:19 UTC
Permalink
Post by umak
Post by Carlos M. Calvelo
Post by umak
lo que se debe usar es un nivel que deje el resultado final COMO SI la
transaccion fuera serializable
No es precisamente ese el significado del nivel de aislamiento
serializable?
fe de erratas: s/serializable/serial
1,$? solo tu linea? o solo la mía?

En cualquier caso no aclara nada.

Saludos,
Carlos
Gux (MVP)
2008-05-23 20:06:01 UTC
Permalink
El resultado final de la ejecución de dos transacciones concurrentes debe ser
similar a la ejecución SERIAL (en serie o secuencia) de las mismas.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by umak
Post by Alfredo Novoa
Y normalmente se debería de usar el nivel serializable.
claro claro... tambien se puede bloquear toda la base de datos y resolvemos
la enfermedad asesinando al paciente
lo que se debe usar es un nivel que deje el resultado final COMO SI la
transaccion fuera serializable
chau
uyke
Carlos M. Calvelo
2008-05-23 20:20:35 UTC
Permalink
Post by Gux (MVP)
El resultado final de la ejecución de dos transacciones concurrentes debe ser
similar a la ejecución SERIAL (en serie o secuencia) de las mismas.
Pues eso es lo que significa que las transacciones sean
'serializables'.

Gux? Gustavo? (no me lo creo!)
Pero si así es... Gux, tu has fumado algo? :-)

Saludos,
Carlos
Alfredo Novoa
2008-05-23 20:35:49 UTC
Permalink
Hola Carlos,
Post by Carlos M. Calvelo
Post by Gux (MVP)
El resultado final de la ejecución de dos transacciones concurrentes debe ser
similar a la ejecución SERIAL (en serie o secuencia) de las mismas.
Pues eso es lo que significa que las transacciones sean
'serializables'.
Hombre, supongo que lo que quieren decir es que si sabes que no se van a
producir lecturas no repetibles ni lecturas fantasma pues que en ese caso
llega con hacer una transacción con nivel READ COMMITTED.

Lo que no tengo muy claro es que se gana realmente con eso ni como estar
seguro de que no van a ocurrir esas anomalías.


Saludos
Alfredo
Gux (MVP)
2008-05-24 00:34:20 UTC
Permalink
Sí, lo tengo claro. Mi mensaje era para corregir lo que puso Umak que estaba
incorrecto.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by Carlos M. Calvelo
Post by Gux (MVP)
El resultado final de la ejecución de dos transacciones concurrentes debe ser
similar a la ejecución SERIAL (en serie o secuencia) de las mismas.
Pues eso es lo que significa que las transacciones sean
'serializables'.
Gux? Gustavo? (no me lo creo!)
Pero si así es... Gux, tu has fumado algo? :-)
Saludos,
Carlos
Gux (MVP)
2008-05-24 00:44:00 UTC
Permalink
Aclaro un poco más, porque a medida que el hilo se extiende se va
dificultando saber de qué habla cada uno:

Cuando digo SERIAL me refiero a una ejecución SECUENCIAL de transacciones.
Ejecuta una transacción, luego otra, luego la otra, por lo que no hay
concurrencia. Esto nunca produce resultados incorrectos

Cuando digo SERIALIZABLE me refiero a una ejecucion CONCURRENTE de
transacciones cuyo resultado final es igual al de alguna ejecución serial de
las mismas.

Eso es lo que le estaba corrigiendo el mensaje de Umak, que confundió
SERIALIZABLE donde debió decir SERIAL. Espero que el amigo Umak lo haya
entendido ahora.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by Gux (MVP)
Sí, lo tengo claro. Mi mensaje era para corregir lo que puso Umak que estaba
incorrecto.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by Carlos M. Calvelo
Post by Gux (MVP)
El resultado final de la ejecución de dos transacciones concurrentes debe ser
similar a la ejecución SERIAL (en serie o secuencia) de las mismas.
Pues eso es lo que significa que las transacciones sean
'serializables'.
Gux? Gustavo? (no me lo creo!)
Pero si así es... Gux, tu has fumado algo? :-)
Saludos,
Carlos
Miguel Egea
2008-05-23 11:33:09 UTC
Permalink
Hola Carlos, no suelo comentar cada párrafo de los que me dicen, creo que se
hace dificil de leer, pero como es una opinión personal y tu lo has hecho te
contesto de la misma forma :-). Respetuosamente y siempre hablando desde el
punto de vista técnico estás en un error, espero que te ayude a aclararlo.

Por otra parte, para cualquier neofito que lea este post no me gustaría que
se llevase la idea de que nivel serializable = bueno o adecuado, el nivel de
aislamiento adecuado lo determina el problema que quieras resolver, lo que
hay que hacer es conocerlos todos, poner serializable para usar select max()
en una aplicación me parece un suicidio.

Manejo bases de datos con miles de usuarios concurrentes, y en estos
escenarios el nivel de aislamiento serializables es inviable, simplemente
inviable.

Mis otros comentarios bajo tus lineas


"Carlos M. Calvelo" <***@hotmail.com> wrote in message news:d0be1c62-de8c-44fc-a77d-***@a1g2000hsb.googlegroups.com...
Hola Miguel,
Post by Miguel Egea
Por problemas de concurrencia.
Verás select max(text) puede ejecutarse a la vez para dos conexiones
distintas y dar el mismo resultado, y el segundo insert fallaría por clave
duplicada ...
Eso solo es verdad si se hace con transacciones con un isolation
level menor que serializable. Entonces dos trasacciones distintas
pueden determinar el max() con el mismo conjunto de registros y
después de que una de ellas haga un insert la otra no se dará
cuenta de una situación de 'phantom read'.
<Miguel Egea>
No, no es cierto, el ejemplo que le he puesto a alfredo lo demuestra, además
no son phantom read, una lectura fantasma solo se puede producir en el nivel
de aislamiento read uncommited, equivocas el concepto.
</Miguel Egea>

Con isolation level serializable se evitan phantom reads por medio
de locking. Esto a su vez puede resultar en un deadlock que hará
automáticamente un rollback de una de las transacciones y no será
posible obtener el mismo resultado (independientemente de si
con ello se genera un clave duplicada o no).
<Miguel Egea>
Te equivocas de nuevo, obtendrás el mismo valor, pero no podrás insertarlo ,
la insercion es lo que provoca el deadloc,
</Miguel Egea>


Saludos,
Carlos
Alfredo Novoa
2008-05-23 12:16:27 UTC
Permalink
Hola Miguel,

On Fri, 23 May 2008 13:33:09 +0200, "Miguel Egea"
Post by Miguel Egea
Por otra parte, para cualquier neofito que lea este post no me gustaría que
se llevase la idea de que nivel serializable = bueno o adecuado
Hombre, el nivel de aislamiento serializable es el bueno, otra cosa es
que por culpa del obsoleto sistema de control de concurrencia de SQL
Server haya que hacer la chapuza de utilizar niveles de concurrencia
defectuosos en algunos casos.
Post by Miguel Egea
<Miguel Egea>
No, no es cierto, el ejemplo que le he puesto a alfredo lo demuestra, además
no son phantom read, una lectura fantasma solo se puede producir en el nivel
de aislamiento read uncommited, equivocas el concepto.
</Miguel Egea>
Parece que estás confundiendo las filas fantasma con las lecturas
sucias. Las filas fantasma se pueden dar con niveles inferiores a
SNAPSHOT, es decir con READ UNCOMMITTED, READ COMMITTED y REPEATABLE
READ.


Saludos
Alfredo
Miguel Egea
2008-05-23 12:52:33 UTC
Permalink
Es cierto que hablaba de lecturas sucias y no fantasma, leí mal tu mensaje,
mis disculpas.

Que sistema de control de concurrencia que sea obsoleto es una opinión, que
como tuya respeto, pero no comparto.

Es cierto que otros gestores manejan de otra forma la concurrencia, de ahí
la aparición en 2005 de los niveles de aislamiento snapshot. que aportan
sabores parecidos a lo que hacen otros gestores en los que lectores no
bloquean escritores, aún así, serializable no es un nivel SQL Server sino un
nivel ISO aunque obviamente la implementación es microsoft.

En cualquier caso creo que queda claro del hilo que el nivel de aislamiento
serializable por defecto no es, por regla general, una buena idea en SQL
Server si se pretenden hacer aplicaciones escalables.

Saludos
Miguel Egea
Post by Carlos M. Calvelo
Hola Miguel,
On Fri, 23 May 2008 13:33:09 +0200, "Miguel Egea"
Post by Miguel Egea
Por otra parte, para cualquier neofito que lea este post no me gustaría que
se llevase la idea de que nivel serializable = bueno o adecuado
Hombre, el nivel de aislamiento serializable es el bueno, otra cosa es
que por culpa del obsoleto sistema de control de concurrencia de SQL
Server haya que hacer la chapuza de utilizar niveles de concurrencia
defectuosos en algunos casos.
Post by Miguel Egea
<Miguel Egea>
No, no es cierto, el ejemplo que le he puesto a alfredo lo demuestra, además
no son phantom read, una lectura fantasma solo se puede producir en el nivel
de aislamiento read uncommited, equivocas el concepto.
</Miguel Egea>
Parece que estás confundiendo las filas fantasma con las lecturas
sucias. Las filas fantasma se pueden dar con niveles inferiores a
SNAPSHOT, es decir con READ UNCOMMITTED, READ COMMITTED y REPEATABLE
READ.
Saludos
Alfredo
Alfredo Novoa
2008-05-23 14:16:22 UTC
Permalink
On Fri, 23 May 2008 14:52:33 +0200, "Miguel Egea"
Post by Miguel Egea
Que sistema de control de concurrencia que sea obsoleto es una opinión, que
como tuya respeto, pero no comparto.
Hombre, depende de lo que quieras entender por obsoleto, pero es un
hecho que la investigación en sistemas de control de concurrencia
basados en bloqueos está prácticamente abandonada desde hace bastantes
años en favor de los sistemas de control de concurrencia optimistas y
libres de bloqueos.

Y lo de que un interbloqueo desconecte la conexión tampoco es una cosa
que vaya muy a la última en sistemas de control de concurrencia.

No hay que olvidar que SQL Server tiene un diseño de los años 80. Si
lo volviesen a hacer ahora desde 0, las cosas cambiarían bastante.
Post by Miguel Egea
Es cierto que otros gestores manejan de otra forma la concurrencia, de ahí
la aparición en 2005 de los niveles de aislamiento snapshot. que aportan
sabores parecidos a lo que hacen otros gestores en los que lectores no
bloquean escritores
¿Y que pasaría entonces con el select Max() + 1 con el nivel snapshot?


Saludos
Alfredo
Miguel Egea
2008-05-23 14:32:35 UTC
Permalink
Post by Alfredo Novoa
On Fri, 23 May 2008 14:52:33 +0200, "Miguel Egea"
Post by Miguel Egea
Que sistema de control de concurrencia que sea obsoleto es una opinión, que
como tuya respeto, pero no comparto.
Hombre, depende de lo que quieras entender por obsoleto, pero es un
hecho que la investigación en sistemas de control de concurrencia
basados en bloqueos está prácticamente abandonada desde hace bastantes
años en favor de los sistemas de control de concurrencia optimistas y
libres de bloqueos.
Y lo de que un interbloqueo desconecte la conexión tampoco es una cosa
que vaya muy a la última en sistemas de control de concurrencia.
No hay que olvidar que SQL Server tiene un diseño de los años 80. Si
lo volviesen a hacer ahora desde 0, las cosas cambiarían bastante.
¿has visto el código fuente de SQL Server? Aseverar que el diseño de la
concurrencia es de los años 80, si bien las teorias son desde por ahí,
implica conocer eso. Conzco a alguna gente del equipo de desarrollo y son
cualquier cosa menos obsoletos. Mucha parte del código se reescribió en el
paso de SQL Server 6.0 a 6.5 cuando se independizó por completo de sybase (o
eso entendí de lo que dice el Inside SQL Server).

En lo que estoy totalmente de acuerdo es que si lo volviensen a escribir
cambiaría bastante, supongo que casi como cualquier código de cualquier
aplicación.
Post by Alfredo Novoa
¿Y que pasaría entonces con el select Max() + 1 con el nivel snapshot?
Pues dependiendo del sabor de snapshot también tendrías claves duplicadas
también. El Read committed snapshot te daría un valor válido si el otro
usuario ha hecho commit, el nivel de aislamiento snapshot te daría el
máximo que había cuando la conexión actual ejecutó la primera instrucción
después de begin tran.
Post by Alfredo Novoa
Saludos
Alfredo
Penta
2008-05-23 14:56:55 UTC
Permalink
Pues a mi no me ha quedado otra que tener una tabla de correlativos y
hacer el select con HOLDLOCK, que segun entiendo es lo mismo que
SERIALIZABLE pero no se porque existen ambas :)

Salu2.
Penta.
Alfredo Novoa
2008-05-23 15:40:24 UTC
Permalink
On Fri, 23 May 2008 16:32:35 +0200, "Miguel Egea"
Post by Miguel Egea
¿has visto el código fuente de SQL Server? Aseverar que el diseño de la
concurrencia es de los años 80, si bien las teorias son desde por ahí,
implica conocer eso.
No, solo hace falta saber en que año salió la primera versión.
Post by Miguel Egea
Conzco a alguna gente del equipo de desarrollo y son
cualquier cosa menos obsoletos.
Y yo tampoco soy obsoleto, pero trabajo a menudo con tecnología
obsoleta.
Post by Miguel Egea
Mucha parte del código se reescribió en el
paso de SQL Server 6.0 a 6.5 cuando se independizó por completo de sybase (o
eso entendí de lo que dice el Inside SQL Server).
Si, pero se mantuvieron muchas cosas de la arquitectura de los años 80
como el control de la concurrencia basado en bloqueos y el
almacenamiento basado en filas.
Post by Miguel Egea
Post by Alfredo Novoa
¿Y que pasaría entonces con el select Max() + 1 con el nivel snapshot?
Pues dependiendo del sabor de snapshot también tendrías claves duplicadas
también. El Read committed snapshot te daría un valor válido si el otro
usuario ha hecho commit, el nivel de aislamiento snapshot te daría el
máximo que había cuando la conexión actual ejecutó la primera instrucción
después de begin tran.
Claro que leen el mismo valor, pero el primero que confirme la
transacción convierte a la lectura del otro en una lectura fantasma y
por lo tanto la segunda transacción se tiene que abortar. Lo que pasa
es que abortar una transacción es algo perfectamente normal, no tiene
sentido tirar la conexión.

Los únicos sistemas con alto nivel de concurrencia con los que he
trabajado estaban hechos en Interbase, y los interbloqueos eran una
cosa normal y no había ningún problema. Se repetía la transacción
abortada y listo.


Saludos
Alfredo
Miguel Egea
2008-05-23 16:08:22 UTC
Permalink
antiguo no tiene por que ser sinónimo de obsoleto. En cualquier caso aquí ya
no queda discusión técnica, y el resto de discusiones a mi me gustan delante
de un café :-) que por mensajes de newsgroups quedan algo extrañas, no se ve
la sonrisa de la gente y pueden "malinterpretarse".

Creo que la discusión técnica nos ha enriquecido un poco a todos.

Un Abrazo
Post by Alfredo Novoa
On Fri, 23 May 2008 16:32:35 +0200, "Miguel Egea"
Post by Miguel Egea
¿has visto el código fuente de SQL Server? Aseverar que el diseño de la
concurrencia es de los años 80, si bien las teorias son desde por ahí,
implica conocer eso.
No, solo hace falta saber en que año salió la primera versión.
Post by Miguel Egea
Conzco a alguna gente del equipo de desarrollo y son
cualquier cosa menos obsoletos.
Y yo tampoco soy obsoleto, pero trabajo a menudo con tecnología
obsoleta.
Post by Miguel Egea
Mucha parte del código se reescribió en el
paso de SQL Server 6.0 a 6.5 cuando se independizó por completo de sybase (o
eso entendí de lo que dice el Inside SQL Server).
Si, pero se mantuvieron muchas cosas de la arquitectura de los años 80
como el control de la concurrencia basado en bloqueos y el
almacenamiento basado en filas.
Post by Miguel Egea
Post by Alfredo Novoa
¿Y que pasaría entonces con el select Max() + 1 con el nivel snapshot?
Pues dependiendo del sabor de snapshot también tendrías claves duplicadas
también. El Read committed snapshot te daría un valor válido si el otro
usuario ha hecho commit, el nivel de aislamiento snapshot te daría el
máximo que había cuando la conexión actual ejecutó la primera instrucción
después de begin tran.
Claro que leen el mismo valor, pero el primero que confirme la
transacción convierte a la lectura del otro en una lectura fantasma y
por lo tanto la segunda transacción se tiene que abortar. Lo que pasa
es que abortar una transacción es algo perfectamente normal, no tiene
sentido tirar la conexión.
Los únicos sistemas con alto nivel de concurrencia con los que he
trabajado estaban hechos en Interbase, y los interbloqueos eran una
cosa normal y no había ningún problema. Se repetía la transacción
abortada y listo.
Saludos
Alfredo
Alfredo Novoa
2008-05-23 16:21:21 UTC
Permalink
On Fri, 23 May 2008 18:08:22 +0200, "Miguel Egea"
Post by Miguel Egea
antiguo no tiene por que ser sinónimo de obsoleto.
Pero anticuado si lo es. Y el control de la concurrencia basado en
bloqueos está anticuado por que los sistemas de control optimista son
superiores.

Y el nivel de aislamiento que no produce anomalías es el serializable
:-)
Post by Miguel Egea
En cualquier caso aquí ya
no queda discusión técnica,
Bueno, quedaba por saber que pasaba cuando las dos transacciones leían
el mismo valor con el nivel snapshot. Supongo que también ocurrirá un
interbloqueo :-(
Post by Miguel Egea
Creo que la discusión técnica nos ha enriquecido un poco a todos.
Seguro que si.


Saludos
Alfredo
Miguel Egea
2008-05-23 21:13:16 UTC
Permalink
En el nivel de aislamiento read commited snapshot el resultado sería le
mismo que en read commited, una clave duplicada (no lo he probado) en el
nivel de aislamiento snapshot no estoy muy seguro si fuese un update daría
un error de que no puede actualizarse porque es como una especie de bloqueo
optimista y los resultados han cambiado desde que los leiste, en este caso
creo que lo mismo, pero no lo he probado.

Saludos
Miguel Egea
Post by Alfredo Novoa
On Fri, 23 May 2008 18:08:22 +0200, "Miguel Egea"
Post by Miguel Egea
antiguo no tiene por que ser sinónimo de obsoleto.
Pero anticuado si lo es. Y el control de la concurrencia basado en
bloqueos está anticuado por que los sistemas de control optimista son
superiores.
Y el nivel de aislamiento que no produce anomalías es el serializable
:-)
Post by Miguel Egea
En cualquier caso aquí ya
no queda discusión técnica,
Bueno, quedaba por saber que pasaba cuando las dos transacciones leían
el mismo valor con el nivel snapshot. Supongo que también ocurrirá un
interbloqueo :-(
Post by Miguel Egea
Creo que la discusión técnica nos ha enriquecido un poco a todos.
Seguro que si.
Saludos
Alfredo
umak
2008-05-23 19:48:01 UTC
Permalink
lo que dije antes...
No hay que olvidar que SQL Server tiene un diseo de los aos 80. Si
lo volviesen a hacer ahora desde 0, las cosas cambiaran bastante.
has visto el cdigo fuente de SQL Server? Aseverar que el diseo de la
concurrencia es de los aos 80, si bien las teorias son desde por ah,
implica conocer eso.
?usaremos entonces mysql que tiene diseño de los 90s?
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...

chau
uyke
Gux (MVP)
2008-05-23 20:13:01 UTC
Permalink
Post by umak
?usaremos entonces mysql que tiene diseño de los 90s?
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
En general la elección del producto no se basa en la época en que está
basado su diseño, pero puede ser un criterio a considerar, como cuando uno
compra vino :-)
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by umak
?usaremos entonces mysql que tiene diseño de los 90s?
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
Alfredo Novoa
2008-05-23 20:43:21 UTC
Permalink
Hola Gux,
Post by Gux (MVP)
Post by umak
?usaremos entonces mysql que tiene diseño de los 90s?
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
En general la elección del producto no se basa en la época en que está
basado su diseño,
Eso es cierto solo en parte. Uno puede diseñar un producto en el siglo XXI
usando tecnologías que llevan décadas obsoletas, y desgraciadamente muchos
lo hacen :-(

Pero si ocurren grandes avances técnológicos entonces el saber que la fecha
de diseño del producto es anterior a esos avances es un indicador bastante
bueno de que no los usan :-)

Por ejemplo si te ofrecen un televisor diseñado en los años 40 es bastante
difícil que tenga 1080p y decodificador de TDT :-)


Saludos
Alfredo
Miguel Egea
2008-05-23 21:17:07 UTC
Permalink
pero es que no es comparable, los televisores de los años 40 no han tenido
revisiones, como si el software, no se cuantas lineas del primitivo sybase
quedan en sqlserver 2008, en 2005 hay xml puro, los conceptos son de los 70
o de los 50, ¿volar no se inspira en da vinci? Creo que estamos
frivolizando el tema y desde luego todos aquí tocamos de oido, porque
realmente no sabemos lo que hay debajo, apostaría 1 quilmes si fuese
argentino o 1 estrella de levante porque soy murciano a que todos llevamos
parte de razón y todos estamos muy equivocados ... En cualquier caso yo
juzgo las bases de datos por como se comportan y SQL Server para mí se ha
comportado de forma excelente en los escenarios en los que lo he usado, y
algunos han sido realmente exigentes..

Saludos
Post by Alfredo Novoa
Hola Gux,
Post by Gux (MVP)
Post by umak
?usaremos entonces mysql que tiene diseño de los 90s?
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
En general la elección del producto no se basa en la época en que está
basado su diseño,
Eso es cierto solo en parte. Uno puede diseñar un producto en el siglo XXI
usando tecnologías que llevan décadas obsoletas, y desgraciadamente muchos
lo hacen :-(
Pero si ocurren grandes avances técnológicos entonces el saber que la fecha
de diseño del producto es anterior a esos avances es un indicador bastante
bueno de que no los usan :-)
Por ejemplo si te ofrecen un televisor diseñado en los años 40 es bastante
difícil que tenga 1080p y decodificador de TDT :-)
Saludos
Alfredo
Alfredo Novoa
2008-05-23 21:43:27 UTC
Permalink
Post by Miguel Egea
pero es que no es comparable, los televisores de los años 40 no han tenido
revisiones, como si el software, no se cuantas lineas del primitivo sybase
quedan en sqlserver 2008,
Estoy hablando del diseño y no del código. Y todavía quedan montones y
montones de decisiones de diseño del primitivo SyBase (y del System R
también) en SQL Server 2008.
Post by Miguel Egea
en 2005 hay xml puro,
Cosa que no es más que un pequeño añadido que no cambia la arquitectura de
forma sustacial.
Post by Miguel Egea
Creo que estamos
frivolizando el tema y desde luego todos aquí tocamos de oido, porque
realmente no sabemos lo que hay debajo
Podemos saber muchas cosas sobre lo que hay debajo y hay un montón de
detalles sobre la arquitectura que son públicos.

http://www.amazon.com/Inside-Microsoft-SQL-Server-2005/dp/0735621055
http://www.amazon.com/Inside-Microsoft%C2%AE-SQL-Server-2005/dp/0735621969/ref=pd_rhf_f_t_cs_3
Post by Miguel Egea
parte de razón y todos estamos muy equivocados ... En cualquier caso yo
juzgo las bases de datos por como se comportan y SQL Server para mí se ha
comportado de forma excelente en los escenarios en los que lo he usado, y
algunos han sido realmente exigentes..
Por que tampoco hay muchas alternativas en el mercado. Pero cualquiera que
esté al tanto de la investigación sobre sistemas de bases de datos sabe que
SQL Server está muy lejos de ser todo lo óptimo que es posible con los
conocimientos actuales.


Saludos
Alfredo
Miguel Egea
2008-05-24 18:50:34 UTC
Permalink
He leido los Inside de la versión 2000, algunos de la 2005, de hecho los
escritores de esos libros son o han sido compañeros de empresa mios (en
Solid Quality Mentors). Tanto Itzik como Kalen, como Ron.como Dejan,
Sabemos algunos detalles de la arquitectura, y algunos detalles de diseño
también, sin embargo y aún leyendo esos detalles, me parece frívolo decir
que es obsoleto y que SQL es poco óptimo con los conocimientos actuales,
esas cosas se pueden sin pruebas decir de todos los sistemas, de hecho de
eso viven los consultores, de decir que lo que hay no vale.

Hace unos años se puso de moda hablar de bases de datos orientadas a objetos
y de lo buenísimas que eran, (de hecho el estandar ISO va por ahí) sin
embargo no creo que nadie conozca un caso de éxito de bases de datos
orientadas a objetos funcionando en sistemas serios ¿de que estamos
hablando? En base de datos no hay modernidades, lo que necesitamos es que
funcione y que funcione rápido.

Sobre la arquitectura pues lo de antigua pues no sé que decirte, el puente
romano de mérida es antiguo, más de mil años, y han pasado coches por él
hasta hace unos años ¿mal diseño de arquitectura el de los romanos?, en
informática pasa algo parecido, yo soy de los que creen que lo que funciona
no se arregla, es cierto que en microsoft investigan (para eso está
research) y que las universidades de todo el mundo también lo hacen, pero
solo incorporan decisiones robustas, ¿no te parece lógico?

En cualquier caso voy a ver si puedo encontrarte en los próximos días datos,
porque sigo insistiendo en que aseverar según que cosas, sin datos pues no
me parece muy científico. Soy de los que les gusta decir eso de "En Dios
confío , el resto traigan datos".


Saludos
Miguel Egea
Post by Alfredo Novoa
Post by Miguel Egea
pero es que no es comparable, los televisores de los años 40 no han tenido
revisiones, como si el software, no se cuantas lineas del primitivo sybase
quedan en sqlserver 2008,
Estoy hablando del diseño y no del código. Y todavía quedan montones y
montones de decisiones de diseño del primitivo SyBase (y del System R
también) en SQL Server 2008.
Post by Miguel Egea
en 2005 hay xml puro,
Cosa que no es más que un pequeño añadido que no cambia la arquitectura de
forma sustacial.
Post by Miguel Egea
Creo que estamos
frivolizando el tema y desde luego todos aquí tocamos de oido, porque
realmente no sabemos lo que hay debajo
Podemos saber muchas cosas sobre lo que hay debajo y hay un montón de
detalles sobre la arquitectura que son públicos.
http://www.amazon.com/Inside-Microsoft-SQL-Server-2005/dp/0735621055
http://www.amazon.com/Inside-Microsoft%C2%AE-SQL-Server-2005/dp/0735621969/ref=pd_rhf_f_t_cs_3
Post by Miguel Egea
parte de razón y todos estamos muy equivocados ... En cualquier caso yo
juzgo las bases de datos por como se comportan y SQL Server para mí se ha
comportado de forma excelente en los escenarios en los que lo he usado, y
algunos han sido realmente exigentes..
Por que tampoco hay muchas alternativas en el mercado. Pero cualquiera que
esté al tanto de la investigación sobre sistemas de bases de datos sabe que
SQL Server está muy lejos de ser todo lo óptimo que es posible con los
conocimientos actuales.
Saludos
Alfredo
Alfredo Novoa
2008-05-24 22:06:45 UTC
Permalink
Hola Miguel,
Post by Miguel Egea
He leido los Inside de la versión 2000, algunos de la 2005, de hecho los
escritores de esos libros son o han sido compañeros de empresa mios (en
Solid Quality Mentors). Tanto Itzik como Kalen, como Ron.como Dejan,
Sabemos algunos detalles de la arquitectura, y algunos detalles de diseño
también, sin embargo y aún leyendo esos detalles, me parece frívolo decir
que es obsoleto y que SQL es poco óptimo con los conocimientos actuales,
Pues a mi me parece que la tuya es una posición muy desinformada sobre los
conocimientos actuales en sistemas de bases de datos. Si le digo esto a
cualquier investigador me responderá: menuda perogrullada.
Post by Miguel Egea
esas cosas se pueden sin pruebas decir de todos los sistemas, de hecho de
eso viven los consultores, de decir que lo que hay no vale.
En esos libros hay muchas pruebas. Los SGBD experimentales modernos tienen
arquitecturas radicalmente diferentes. Lo que hay en esos libros llega de
sobra para decir que SQL Server tiene un diseño de otros tiempos. Otra cosa
es que no estés familiarizado con el estado del arte en investigación sobre
bases de datos. Yo si lo estoy y por eso te lo digo.
Post by Miguel Egea
Hace unos años se puso de moda hablar de bases de datos orientadas a objetos
y de lo buenísimas que eran,
Todos los verdaderos expertos sabían que eso era una idiotez. Una vuelta al
modelo de red.
Post by Miguel Egea
hablando? En base de datos no hay modernidades, lo que necesitamos es que
funcione y que funcione rápido.
Claro que las hay, otra cosa es que tu las conozcas.

Ahora hay conocimientos para hacer SGBD que funcionen mucho mejor y mucho
más rápido. Las ganancias en velocidad de las nuevas arquitecturas pueden
estar entre las 10 y las 100 veces.

Mira lo que dice Stonebraker:

These papers presented reasons and experimental evidence that showed that
the major RDBMS vendors can be outperformed by 1-2 orders of magnitude by
specialized engines in the data warehouse, stream processing, text, and
scientific database markets. Assuming that specialized engines dominate
these markets over time, the current relational DBMS code lines will be
left with the business data processing (OLTP) market and hybrid markets
where more than one kind of capability is required. In this paper we show
that current RDBMSs can be beaten by nearly two orders of magnitude in the
OLTP market as well.

...

Hence, they are 25 year old legacy code lines that should be retired in
favor of a collection of “from scratch” specialized engines. The DBMS
vendors (and the research community) should start with a clean sheet of
paper and design systems for tomorrow’s requirements, not continue to push
code lines and architectures designed for yesterday’s needs.

http://www.vldb.org/conf/2007/papers/industrial/p1150-stonebraker.pdf

Por ejemplo este prototipo le pega grandes palizas a SQL Server en
velocidad de consultas para Datawarehouses:

http://db.csail.mit.edu/projects/cstore/
Post by Miguel Egea
Sobre la arquitectura pues lo de antigua pues no sé que decirte, el puente
romano de mérida es antiguo, más de mil años, y han pasado coches por él
hasta hace unos años ¿mal diseño de arquitectura el de los romanos?
Fue bueno para su época y obsoleto para la nuestra. Igual que otras cosas
:-)
Post by Miguel Egea
En cualquier caso voy a ver si puedo encontrarte en los próximos días datos,
porque sigo insistiendo en que aseverar según que cosas, sin datos pues no
me parece muy científico.
Si quieres te puedo pasar montones de referencias. Pero si buscas un poco
también las puedes encontrar tú.


Saludos
Alfredo
Carlos M. Calvelo
2008-05-24 23:12:33 UTC
Permalink
Hola Miguel,
Post by Miguel Egea
He leido los Inside de la versión 2000, algunos de la 2005, de hecho los
escritores de esos libros son o han sido compañeros de empresa mios (en
Solid Quality Mentors). Tanto Itzik como Kalen, como Ron.como Dejan,
Has leído a Date, Darwen, Pascal? Itzik sí ha leído algo.
Post by Miguel Egea
Sabemos algunos detalles de la arquitectura, y algunos detalles de diseño
también, sin embargo y aún leyendo esos detalles, me parece frívolo decir
que es obsoleto y que SQL es poco óptimo con los conocimientos actuales,
SQL (el lenguage) era un mal diseño (y obsoleto) con los
conocimientos del día en que se concibió. Y con cada nuevo
estandar va de mal en peor.
Post by Miguel Egea
esas cosas se pueden sin pruebas decir de todos los sistemas, de hecho de
eso viven los consultores, de decir que lo que hay no vale.
Ahí está la historia. Si vale decir que profundices en lo que pasó
en IBM en los años 1069, 70, 71, etc., todo lo que vino después
y la investigación que sigue hasta hoy en día.
Post by Miguel Egea
Hace unos años se puso de moda hablar de bases de datos orientadas a objetos
y de lo buenísimas que eran, (de hecho el estandar ISO va por ahí) sin
embargo no creo que nadie conozca un caso de éxito de bases de datos
orientadas a objetos funcionando en sistemas serios ¿de que estamos
hablando?
La OODBMS son una burrada que a podido tener lugar a ser concebida
debido a los fallos de los años que he mencionado arriba. Por no
conocer la historia. Por no saber que el modelo relacional era una
reacción a los modelos de red y jerárquico. Por no tener un sistema
de tipos como es debido en vez de la ridiculez de 'dominios' que nos
ofrecen los productos. Y porque SQL no es relacional.

'The Third Manifesto' es una reacción a todo esto.
Post by Miguel Egea
En base de datos no hay modernidades, lo que necesitamos es que
funcione y que funcione rápido.
'Modernidades' no. Pero diseños malos (como SQL) sí.
Y lo malo es que tenemos SQL para rato!
Post by Miguel Egea
Sobre la arquitectura pues lo de antigua pues no sé que decirte, el puente
romano de mérida es antiguo, más de mil años, y han pasado coches por él
hasta hace unos años ¿mal diseño de arquitectura el de los romanos?, en
informática pasa algo parecido, yo soy de los que creen que lo que funciona
no se arregla, es cierto que en microsoft investigan (para eso está
research) y que las universidades de todo el mundo también lo hacen, pero
solo incorporan decisiones robustas, ¿no te parece lógico?
En cualquier caso voy a ver si puedo encontrarte en los próximos días datos,
porque sigo insistiendo en que aseverar según que cosas, sin datos pues no
me parece muy científico. Soy de los que les gusta decir eso de "En Dios
confío , el resto traigan datos".
Cuantos libros de estos has leido?
http://www.dbdebunk.com/books.html

Conoces estó?
http://www.thethirdmanifesto.com/
y todas las actividades en torno al 'manifesto'?

Has oído alguna vez sobre la ortogonalidad del modelo relacional y
de tipos (dominios)? Pero que el modelo relacional depende de
un buen sistema de tipos?
En cuanto a tipos y herencia, sabes algo (por ejemplo) sobre
especialización por medio de restricción? (specialization by
constraint)

'Independencia física de datos', 'independencia lógica de datos'
'transrelational model', ... te dicen algo estas cosas?

Para no habar de programación declarativa de resticciones de
integridad.

Estas cosas no se van a aclarar aquí en el foro. Hay que currarselo
y el aspecto histórico es esencial.
Referencias y datos tienes (si quieres) para divertirte una buena
temporada. :-)

Después sabrás que SQL Server, por muy 'bonito' que pueda parecer
por dentro, pues no da la talla. Pero mucho de eso lo hereda por
ser SQL.

Saludos,
Carlos
Gux (MVP)
2008-05-24 23:27:00 UTC
Permalink
Carlos y Miguel, me temo que están ustedes discutiendo cosas distintas.

Cuando hablan ustedes de lo óptimo o no, Miguel habla de SQL Server y Carlos
habla de SQL (el lenguaje). La discusión no tiene puntos de comparación.

Opino de temas que no domino si Alfredo Novoa me autoriza, por supuesto ;-)
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by Carlos M. Calvelo
Hola Miguel,
Post by Miguel Egea
He leido los Inside de la versión 2000, algunos de la 2005, de hecho los
escritores de esos libros son o han sido compañeros de empresa mios (en
Solid Quality Mentors). Tanto Itzik como Kalen, como Ron.como Dejan,
Has leído a Date, Darwen, Pascal? Itzik sí ha leído algo.
Post by Miguel Egea
Sabemos algunos detalles de la arquitectura, y algunos detalles de diseño
también, sin embargo y aún leyendo esos detalles, me parece frívolo decir
que es obsoleto y que SQL es poco óptimo con los conocimientos actuales,
SQL (el lenguage) era un mal diseño (y obsoleto) con los
conocimientos del día en que se concibió. Y con cada nuevo
estandar va de mal en peor.
Post by Miguel Egea
esas cosas se pueden sin pruebas decir de todos los sistemas, de hecho de
eso viven los consultores, de decir que lo que hay no vale.
Ahí está la historia. Si vale decir que profundices en lo que pasó
en IBM en los años 1069, 70, 71, etc., todo lo que vino después
y la investigación que sigue hasta hoy en día.
Post by Miguel Egea
Hace unos años se puso de moda hablar de bases de datos orientadas a objetos
y de lo buenísimas que eran, (de hecho el estandar ISO va por ahí) sin
embargo no creo que nadie conozca un caso de éxito de bases de datos
orientadas a objetos funcionando en sistemas serios ¿de que estamos
hablando?
La OODBMS son una burrada que a podido tener lugar a ser concebida
debido a los fallos de los años que he mencionado arriba. Por no
conocer la historia. Por no saber que el modelo relacional era una
reacción a los modelos de red y jerárquico. Por no tener un sistema
de tipos como es debido en vez de la ridiculez de 'dominios' que nos
ofrecen los productos. Y porque SQL no es relacional.
'The Third Manifesto' es una reacción a todo esto.
Post by Miguel Egea
En base de datos no hay modernidades, lo que necesitamos es que
funcione y que funcione rápido.
'Modernidades' no. Pero diseños malos (como SQL) sí.
Y lo malo es que tenemos SQL para rato!
Post by Miguel Egea
Sobre la arquitectura pues lo de antigua pues no sé que decirte, el puente
romano de mérida es antiguo, más de mil años, y han pasado coches por él
hasta hace unos años ¿mal diseño de arquitectura el de los romanos?, en
informática pasa algo parecido, yo soy de los que creen que lo que funciona
no se arregla, es cierto que en microsoft investigan (para eso está
research) y que las universidades de todo el mundo también lo hacen, pero
solo incorporan decisiones robustas, ¿no te parece lógico?
En cualquier caso voy a ver si puedo encontrarte en los próximos días datos,
porque sigo insistiendo en que aseverar según que cosas, sin datos pues no
me parece muy científico. Soy de los que les gusta decir eso de "En Dios
confío , el resto traigan datos".
Cuantos libros de estos has leido?
http://www.dbdebunk.com/books.html
Conoces estó?
http://www.thethirdmanifesto.com/
y todas las actividades en torno al 'manifesto'?
Has oído alguna vez sobre la ortogonalidad del modelo relacional y
de tipos (dominios)? Pero que el modelo relacional depende de
un buen sistema de tipos?
En cuanto a tipos y herencia, sabes algo (por ejemplo) sobre
especialización por medio de restricción? (specialization by
constraint)
'Independencia física de datos', 'independencia lógica de datos'
'transrelational model', ... te dicen algo estas cosas?
Para no habar de programación declarativa de resticciones de
integridad.
Estas cosas no se van a aclarar aquí en el foro. Hay que currarselo
y el aspecto histórico es esencial.
Referencias y datos tienes (si quieres) para divertirte una buena
temporada. :-)
Después sabrás que SQL Server, por muy 'bonito' que pueda parecer
por dentro, pues no da la talla. Pero mucho de eso lo hereda por
ser SQL.
Saludos,
Carlos
Carlos M. Calvelo
2008-05-24 23:37:29 UTC
Permalink
Hola Gustavo,
Post by Gux (MVP)
Carlos y Miguel, me temo que están ustedes discutiendo cosas distintas.
Cuando hablan ustedes de lo óptimo o no, Miguel habla de SQL Server y Carlos
habla de SQL (el lenguaje). La discusión no tiene puntos de comparación.
Es cierto Gux.
Lo que digo es aplicable a todos los productos SQL en
general y SQL Server no se escapa.

Saludos,
Carlos
Alfredo Novoa
2008-05-24 23:44:59 UTC
Permalink
Hola Carlos,
Post by Carlos M. Calvelo
Post by Miguel Egea
Sabemos algunos detalles de la arquitectura, y algunos detalles de diseño
también, sin embargo y aún leyendo esos detalles, me parece frívolo decir
que es obsoleto y que SQL es poco óptimo con los conocimientos actuales,
SQL (el lenguage) era un mal diseño (y obsoleto) con los
conocimientos del día en que se concibió. Y con cada nuevo
estandar va de mal en peor.
Si, yo solo estaba hablando de la arquitectura interna y la implementación,
pero si nos ponemos a hablar de los defectos de SQL como lenguaje
relacional entonces no acabamos :-)
Post by Carlos M. Calvelo
Estas cosas no se van a aclarar aquí en el foro. Hay que currarselo
y el aspecto histórico es esencial.
Referencias y datos tienes (si quieres) para divertirte una buena
temporada. :-)
Pues sobre técnicas de implementación modernas todavía hay mucho más
material.


Saludos
Alfredo
Carlos M. Calvelo
2008-05-24 23:58:55 UTC
Permalink
Hola Alfredo,
Post by Alfredo Novoa
Hola Carlos,
Post by Carlos M. Calvelo
Post by Miguel Egea
Sabemos algunos detalles de la arquitectura, y algunos detalles de diseño
también, sin embargo y aún leyendo esos detalles, me parece frívolo decir
que es obsoleto y que SQL es poco óptimo con los conocimientos actuales,
SQL (el lenguage) era un mal diseño (y obsoleto) con los
conocimientos del día en que se concibió. Y con cada nuevo
estandar va de mal en peor.
Si, yo solo estaba hablando de la arquitectura interna y la implementación,
pero si nos ponemos a hablar de los defectos de SQL como lenguaje
relacional entonces no acabamos :-)
Me he dejado llevar por lo de " que SQL es poco óptimo ..." etc.
Yo debería haber entendido SQL Server. (mea culpa)

Quisiera de todas formas hacer hincapié en que el mal
diseño de SQL tiene muchas consecuencias negativas
a la hora de diseñar un buen SGBD.

Saludos,
Carlos
Carlos M. Calvelo
2008-05-25 00:34:43 UTC
Permalink
Hola Miguel,

Ya me han corregido Gustavo y Alfredo por mi reacción anterior y
ahora dudo.

Si tus comentarios sobre diseño y arquitectura de SQL Server son
para contrastar con otros productos SQL puedes considerar mi
reacción como 'no enviada'.

Si tus comentarios son en términos mas generales (SQLDBMS,
OODBMS, RDBMS, modelo relacional, technología, ciencia)
entonces mantengo mi aportación.

Saludos,
Carlos
Miguel Egea
2008-05-25 10:27:47 UTC
Permalink
Yo hablaba de SQL Server, no estaba intentanto entrar en una discusión
filosóifica sobre las investigaciones en base de datos, (que parece es lo
que se ha entendido), No ando metido en el mundo de la investigación, ni
siquiera estoy en el mundo relacional, hace más de un año que no estoy a
fondo con el sistema relacional, me pasé al multidimensional, de
datawarehouse si sé algo, también se que seguramente SQL 2008 multiplique el
rendimiento para datawarehouse con modelo en estrella en es 1 o 2 ordenes de
magnitud, sin ser necesario un cambio de arquitectura.

De todas formas este será el ultimo post que yo ponga en este hilo :) Ha
estado bonito.

Saludos

"Carlos M. Calvelo" <***@hotmail.com> wrote in message news:8d54ed12-6367-45f2-bbb2-***@c65g2000hsa.googlegroups.com...
Hola Miguel,

Ya me han corregido Gustavo y Alfredo por mi reacción anterior y
ahora dudo.

Si tus comentarios sobre diseño y arquitectura de SQL Server son
para contrastar con otros productos SQL puedes considerar mi
reacción como 'no enviada'.

Si tus comentarios son en términos mas generales (SQLDBMS,
OODBMS, RDBMS, modelo relacional, technología, ciencia)
entonces mantengo mi aportación.

Saludos,
Carlos
Carlos M. Calvelo
2008-05-25 22:29:29 UTC
Permalink
Hola Miguel,
Post by Miguel Egea
Yo hablaba de SQL Server, no estaba intentanto entrar en una discusión
filosóifica sobre las investigaciones en base de datos, (que parece es lo
que se ha entendido),
Entonces retiro mi aportación como he prometido. :)
Pero no es filosofía. Es tecnología que está ahí pero los
fabricantes... como que no quieren vamos. Y de la que se puede
aprender para utilizar mejor lo que sí tenemos. Y saber qué
hay que pedir a los fabricantes, claro.
Post by Miguel Egea
De todas formas este será el ultimo post que yo ponga en este hilo :) Ha
estado bonito.
Bueno. Veo el emoticón, no sé cómo interpretarlo y espero que
en todo caso no haya sido yo la causa de esa decisión.

Saludos
Carlos
Alfredo Novoa
2008-05-25 23:29:12 UTC
Permalink
Post by Miguel Egea
datawarehouse si sé algo, también se que seguramente SQL 2008 multiplique el
rendimiento para datawarehouse con modelo en estrella en es 1 o 2 ordenes de
magnitud, sin ser necesario un cambio de arquitectura.
Me parece muy raro. He buscado un poco por ahí y hablan de un aumento del
rendimiento de entre el 15 y el 20 por ciento, que no tiene nada que ver
con lo que dices.

http://technet.microsoft.com/en-us/magazine/cc434693.aspx?pr=blog

Saludos
Alfredo
Gux (MVP)
2008-05-24 19:55:01 UTC
Permalink
Post by Alfredo Novoa
Estoy hablando del diseño y no del código. Y todavía quedan montones y
montones de decisiones de diseño del primitivo SyBase (y del System R
también) en SQL Server 2008.
Tiene usted acceso a tal información interna del producto?

Sería un buen aporte al foro que usted brinde detalles de lo que afirma o dé
prueba documentada de lo que afirma, caso contrario no podremos tomar
demasiado en serio lo que usted dice.

Seria muy poco profesional afirmar tal cosa sin información contundente que
la avale.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Alfredo Novoa
2008-05-24 22:09:27 UTC
Permalink
Post by Gux (MVP)
Post by Alfredo Novoa
Estoy hablando del diseño y no del código. Y todavía quedan montones y
montones de decisiones de diseño del primitivo SyBase (y del System R
también) en SQL Server 2008.
Tiene usted acceso a tal información interna del producto?
Hola Gux, vuelve a leer mi mensaje y esta vez prestando más atención.



Saludos
Alfredo
Gux (MVP)
2008-05-24 22:57:00 UTC
Permalink
Siguiendo su consejo volvi a leer su mensaje, Alfredo.

En su mensaje usted afirma que "quedan montones montones de decisiones de
diseño del primitivo SyBase (y del System R también) en SQL Server 2008."

Como usted evade contestar mi pregunta, vuelvo a preguntarle si usted tiene
acceso o participado en las decisiones de diseño de SQL Server 2008 como para
afirmar lo que afirmó.

Si la respuesta es "No" o no contesta, asumiré que está opinando
irresponsablemente por el mero placer de opinar o por querer introducir
confusion en el tema.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by Alfredo Novoa
Post by Gux (MVP)
Post by Alfredo Novoa
Estoy hablando del diseño y no del código. Y todavía quedan montones y
montones de decisiones de diseño del primitivo SyBase (y del System R
también) en SQL Server 2008.
Tiene usted acceso a tal información interna del producto?
Hola Gux, vuelve a leer mi mensaje y esta vez prestando más atención.
Saludos
Alfredo
Alfredo Novoa
2008-05-24 23:36:17 UTC
Permalink
Post by Gux (MVP)
Siguiendo su consejo volvi a leer su mensaje, Alfredo.
En su mensaje usted afirma que "quedan montones montones de decisiones de
diseño del primitivo SyBase (y del System R también) en SQL Server 2008."
Como usted evade contestar mi pregunta, vuelvo a preguntarle si usted tiene
acceso o participado en las decisiones de diseño de SQL Server 2008 como para
afirmar lo que afirmó.
Tengo acceso igual que tú. Hay un montón de documentación pública con un
nivel de detalle más que suficiente para poder afirmar lo que digo.

Y por supuesto lo mismo del System R, que es en el que están basados casi
todos sino todos los SGBD SQL de esa época.

Saludos
afredo
Alfredo Novoa
2008-05-23 20:31:32 UTC
Permalink
Post by umak
?usaremos entonces mysql que tiene diseño de los 90s?
Por desgracia cuando se diseñó MySQL no se utilizaron los conocimientos en
sistemas de control de concurrencia que estaban disponibles en esas fechas.

Aunque de todas formas MySQL tiene varios "motores de almacenamiento"
bastante diferentes. Los ISAM y MyISAM son muy primitivos, InnoDB es más
decente, y tienen varios más.
Post by umak
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.


Saludos
Alfredo
Gux (MVP)
2008-05-24 20:00:01 UTC
Permalink
Post by Alfredo Novoa
Post by umak
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.
Lo que puse en otro hilo: Evitemos la liviandad de afirmar cosas sin
documentación que la apoye.

Por supuesto, tal vez usted tiene o ha tenido acceso a la documentación de
diseño de todos los productos mencionados y sabe de lo que habla. De no ser
así, es una afirmación basada en una opinión personal simplemente, que
también es válido pero debe dejarse en claro al decirlo.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Alfredo Novoa
2008-05-24 22:11:32 UTC
Permalink
Post by Gux (MVP)
Post by Alfredo Novoa
Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.
Lo que puse en otro hilo: Evitemos la liviandad de afirmar cosas sin
documentación que la apoye.
Por supuesto, tal vez usted tiene o ha tenido acceso a la documentación de
diseño de todos los productos mencionados y sabe de lo que habla. De no ser
así, es una afirmación basada en una opinión personal simplemente, que
también es válido pero debe dejarse en claro al decirlo.
Gux, es mejor que no intervengas en conversaciones sobre temas que no
dominas.


Saludos
Alfredo
Gux (MVP)
2008-05-24 22:59:01 UTC
Permalink
Veo que prefiere no contestar una pregunta concreta que le hago y prefiere
ordenarme que no opine.

O sea que no solamente opina sin fundamentar sino que ademas prefiere atacar
a quien le pregunta. Muy bueno su aporte al foro, siga participando.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Post by Alfredo Novoa
Post by Gux (MVP)
Post by Alfredo Novoa
Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.
Lo que puse en otro hilo: Evitemos la liviandad de afirmar cosas sin
documentación que la apoye.
Por supuesto, tal vez usted tiene o ha tenido acceso a la documentación de
diseño de todos los productos mencionados y sabe de lo que habla. De no ser
así, es una afirmación basada en una opinión personal simplemente, que
también es válido pero debe dejarse en claro al decirlo.
Gux, es mejor que no intervengas en conversaciones sobre temas que no
dominas.
Saludos
Alfredo
Alfredo Novoa
2008-05-24 23:16:08 UTC
Permalink
Post by Gux (MVP)
Veo que prefiere no contestar una pregunta concreta que le hago y prefiere
ordenarme que no opine.
No era una orden, era una sugerencia.

Pero si insistes en querer una respuesta: todos esos productos son de
código abierto.

Espero que sepas lo que significa eso, por que ya no me atrevo a presuponer
nada.


Saludos
Alfredo
Alfredo Novoa
2008-05-24 23:29:57 UTC
Permalink
Post by Alfredo Novoa
Pero si insistes en querer una respuesta: todos esos productos son de
código abierto.
Bueno, aquí me refiero a MySQL, ISAM, MyISAM e InnoDB.

Respecto a DB2, Oracle y SQL Server hay un montón de documentación
disponible sobre su arquitectura, como por ejemplo la de los dos libros que
he citado.


Saludos
Gux (MVP)
2008-05-24 23:46:01 UTC
Permalink
Alfredo, cada vez usted confunde más al lector.
Post by umak
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.
Post by umak
Respecto a DB2, Oracle y SQL Server hay un montón de documentación
disponible sobre su arquitectura, como por ejemplo la de los dos libros que
he citado.
Diseño y arquitectura no es lo mismo, pero estoy seguro que eso usted lo
domina ya que habla del tema, no como otros especialmente yo mismo :-)

De todas formas opinar que el diseño es parecido, en base a que usted leyó
acerca de la arquitectura, es una opinión temeraria la que usted da. No puedo
negarle a usted una cierta dosis de locura aventurera :-)
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Alfredo Novoa
2008-05-25 00:03:11 UTC
Permalink
Post by Gux (MVP)
Post by Alfredo Novoa
Respecto a DB2, Oracle y SQL Server hay un montón de documentación
disponible sobre su arquitectura, como por ejemplo la de los dos libros que
he citado.
Diseño y arquitectura no es lo mismo,
Rectifico:

Respecto a DB2, Oracle y SQL Server hay un montón de documentación
disponible sobre su diseño y arquitectura, como por ejemplo la de los dos
libros que he citado.

¿Mejor ahora?
Post by Gux (MVP)
De todas formas opinar que el diseño es parecido, en base a que usted leyó
acerca de la arquitectura, es una opinión temeraria la que usted da. No puedo
negarle a usted una cierta dosis de locura aventurera :-)
Si tú también lo hubieses leído no dirías lo mismo. Me sobra información
para decir lo que digo.


Saludos
Alfredo
Gux (MVP)
2008-05-24 23:37:00 UTC
Permalink
Post by Alfredo Novoa
Pero si insistes en querer una respuesta: todos esos productos son de
código abierto.
Espero que sepas lo que significa eso, por que ya no me atrevo a presuponer
nada.
Se refiere usted a "open source" verdad? Si no es así, disculpe mi tremenda
ignorancia en tantos temas.

Espero que usted esté seguro en eso que dijo acerca de que SQL Server,
Oracle y DB2 son open source... o Ricard Stallman se pondrá furioso con usted.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Maxi Accotto
2008-05-25 22:49:08 UTC
Permalink
Post by Gux (MVP)
Espero que usted esté seguro en eso que dijo acerca de que SQL Server,
Oracle y DB2 son open source... o Ricard Stallman se pondrá furioso con usted.
jajaja, Gux, que sentido tiene darle de comer a los troll :-)
--
-----------------------------
Microsoft MVP SQLServer
www.sqltotalconsulting.com
-------------------------------
Post by Gux (MVP)
Post by Alfredo Novoa
Pero si insistes en querer una respuesta: todos esos productos son de
código abierto.
Espero que sepas lo que significa eso, por que ya no me atrevo a presuponer
nada.
Se refiere usted a "open source" verdad? Si no es así, disculpe mi tremenda
ignorancia en tantos temas.
Espero que usted esté seguro en eso que dijo acerca de que SQL Server,
Oracle y DB2 son open source... o Ricard Stallman se pondrá furioso con usted.
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gustavo.larriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Alfredo Novoa
2008-05-26 11:58:01 UTC
Permalink
Post by Maxi Accotto
jajaja, Gux, que sentido tiene darle de comer a los troll :-)
A menudo ocurre que alguien escribe un mensaje sincero sobre el que será
emocionalmente sensible. Los trolls habilidosos saben que una forma fácil
de enfadarle es afirmar deshonestamente que dicha persona es un troll. En
otras ocasiones una persona puede no entender o encajar inmediatamente en
las normas sociales de un foro donde la mayoría de los participantes sí lo
hacen. Como resultado, actuar ligeramente fuera de las normas (a menudo no
intencionadamente y por razones legítimas) hace que dicha persona sea
calificada de troll.

...

El término «troll» es altamente subjetivo. Ciertos lectores pueden
clasificar un mensaje como troll mientras otros verán el mismo mensaje como
una contribución legítima a la discusión, aunque sea controvertida. El
término se usa frecuentemente para desacreditar una posición contraria o a
su proponente mediante el argumento ad hominem. Igualmente, decir que
alguien es un troll significa hacer suposiciones sobre sus motivos, que
pueden ser incorrectas.

...

http://es.wikipedia.org/wiki/Troll_(Internet)


Saludos
Alfredo
Alfredo Novoa
2008-05-24 23:38:50 UTC
Permalink
Post by Gux (MVP)
Post by Alfredo Novoa
Post by umak
pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.
Lo que puse en otro hilo: Evitemos la liviandad de afirmar cosas sin
documentación que la apoye.
Lo siento, aquí no me fijé bien en que parte del mensaje estabas citando y
contesté a otra cosa. Mis disculpas.


Saludos
Alfredo
Carlos M. Calvelo
2008-05-23 15:21:18 UTC
Permalink
Hola Miguel,

Vaya! Me voy a una reunión de dos horitas y esto ya ha explotado :)

Solo un par de reacciones que veo que ya se han aclarado muchas
cosas.
Post by Miguel Egea
Hola Carlos, no suelo comentar cada párrafo de los que me dicen, creo que se
hace dificil de leer, pero como es una opinión personal y tu lo has hecho te
contesto de la misma forma :-). Respetuosamente y siempre hablando desde el
punto de vista técnico estás en un error, espero que te ayude a aclararlo.
He vuelto a leer mi reacción y no veo nada opinable en ella.
Los conceptos de 'serializabilidad de transacciones' y de
lo que es un 'phantom read' los tengo muy claros :-)
Post by Miguel Egea
Manejo bases de datos con miles de usuarios concurrentes, y en estos
escenarios el nivel de aislamiento serializables es inviable, simplemente
inviable.
Aquí si que tengo la tendencia a creerte.
Vamos... que estoy 'casi seguro' de que es así como dices;
pero ese es el problema de SQL Server y no de conceptos.

Saludos,
Carlos
Miguel Egea
2008-05-23 16:06:17 UTC
Permalink
Estupendo, el problema es que leí phantom reads y traduje lecturas sucias,
cosas del inglés y mi cabeza anticuada.

Creo que hasta aquí hubo discusión técnica, a partir de ahora lo mejor
sería discuir esto delante de un café, que pena que internet solo permita
cibercafés :)

Un Abrazo

"Carlos M. Calvelo" <***@hotmail.com> wrote in message news:6cb1003f-3a7a-49e5-8390-***@59g2000hsb.googlegroups.com...
Hola Miguel,

Vaya! Me voy a una reunión de dos horitas y esto ya ha explotado :)

Solo un par de reacciones que veo que ya se han aclarado muchas
cosas.
Post by Miguel Egea
Hola Carlos, no suelo comentar cada párrafo de los que me dicen, creo que se
hace dificil de leer, pero como es una opinión personal y tu lo has hecho te
contesto de la misma forma :-). Respetuosamente y siempre hablando desde el
punto de vista técnico estás en un error, espero que te ayude a aclararlo.
He vuelto a leer mi reacción y no veo nada opinable en ella.
Los conceptos de 'serializabilidad de transacciones' y de
lo que es un 'phantom read' los tengo muy claros :-)
Post by Miguel Egea
Manejo bases de datos con miles de usuarios concurrentes, y en estos
escenarios el nivel de aislamiento serializables es inviable, simplemente
inviable.
Aquí si que tengo la tendencia a creerte.
Vamos... que estoy 'casi seguro' de que es así como dices;
pero ese es el problema de SQL Server y no de conceptos.

Saludos,
Carlos
Alejandro Mesa
2008-05-23 22:46:01 UTC
Permalink
Hola Miguel,

Que gusto tenerte por aca.

El problema que afronta el OP, es que no se puede usar esa funcionalidad
cuando se inserta un batch o conjunto de filas, pues no podemos ejecutar el
procedimiento almacenado por cada fila que se inserta, si no es que se usa un
lazo o procesamiento de las filas de una en una.

Posiblemente se pueda crear un funcion de usuario y usar una de las puertas
de atras existentes (no recomendable) para poder traer ese numero. Para eso,
pudieramos crear un servidor ligado que apunte a si mismo y usar OPENQUERY
para hacer la insercion en la tabla y traer el valor identiy o posterior si
no es identity.


Ejemplo:

use master
go

/****** Object: LinkedServer [LOOPBACK] Script Date: 05/23/2008 18:42:29
******/
EXEC master.dbo.sp_addlinkedserver @server = N'LOOPBACK', @srvproduct=N'SQL
Server'
/* For security reasons the linked server remote logins password is changed
with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname=N'LOOPBACK',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'collation
compatible', @optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'data
access', @optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'dist',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'pub',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'rpc',
@optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'rpc out',
@optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'sub',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'connect
timeout', @optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'collation
name', @optvalue=null
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'lazy schema
validation', @optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'query
timeout', @optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @server=N'LOOPBACK', @optname=N'use remote
collation', @optvalue=N'true'
go

use tempdb
go

create table dbo.Claves (
Clave int not null identity(1, 1) primary key
)
go

create function dbo.ufn_ProximaClave(
@p1 varchar(50)
)
returns int
as
begin
declare @i int

select @i = Clave
from openquery(LOOPBACK, 'begin transaction insert into tempdb.dbo.Claves
output inserted.Clave default values; rollback transaction')

return @i
end
go

create table dbo.t1 (
c1 int not null primary key,
c2 varchar(50) not null unique
)
go

insert into dbo.t1(c1, c2)
select dbo.ufn_ProximaClave(t.c1), t.c1
from
(
select 'SQL Server 2000' as c1
union all
select 'SQL Server 2005' as c1
union all
select 'SQL Server 2008' as c1
) as t
go

select *
from dbo.t1
go

drop function dbo.ufn_ProximaClave
go

drop table dbo.Claves, dbo.t1
go


Saludos,
AMB
Post by Miguel Egea
Si usas SQL 2005 puedes hacer un procedimiento como el siguiente y llamarlo
para obtener un identificador con tabla, tiene todos los inconvenientes y
ventas de los identities, no te obliga acambiar la estructura aunque ocupas
un schema. Si no usas SQL 2005 es adaptable. Creo que no tiene problemas de
inyeccin de cdigo SQL en cualquier caso ah tenis las pruebas.
create schema Maestros;
go
with execute as owner -- cambialo por alguien con permisos para crear tablas
de forma dinmica
as
begin
if not exists(select 1 from information_Schema.tables where table_name =
@tabla and Table_schema='Maestros')
begin
identity(1,1)) ' ;
end
else
begin tran
rollback tran
end
go
select * from information_schema.tables where table_schema='Maestros'
go
-- sin problemas de inyeccin de cdigo.
output
select * from information_schema.tables where table_schema='Maestros'
Saludos
Miguel Egea
Post by CHAR72
Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
del sistema para ponerle IDENTITY.
Gracias
Post by Alejandro Mesa
CHAR72,
Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY. Tendras que
usar un lazo / cursor e insertar las filas una por una.
AMB
Hola compaeros! tengo cierto inconveniente que no puedo resolver. Tengo
un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert de un
registro no hay inconveniente, pero ahora debo realizar varios insert y no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
Miguel Egea
2008-05-24 08:54:46 UTC
Permalink
yo acompaño este tipo de procedimientos con otros que devuelven un rango, de
esta forma puedo insertarlos como sifuesen consecutivos sin que esto afecte
al tratamiento de lotes.
Post by Carlos M. Calvelo
Hola Miguel,
Que gusto tenerte por aca.
El problema que afronta el OP, es que no se puede usar esa funcionalidad
cuando se inserta un batch o conjunto de filas, pues no podemos ejecutar el
procedimiento almacenado por cada fila que se inserta, si no es que se usa un
lazo o procesamiento de las filas de una en una.
Posiblemente se pueda crear un funcion de usuario y usar una de las puertas
de atras existentes (no recomendable) para poder traer ese numero. Para eso,
pudieramos crear un servidor ligado que apunte a si mismo y usar OPENQUERY
para hacer la insercion en la tabla y traer el valor identiy o posterior si
no es identity.
use master
go
/****** Object: LinkedServer [LOOPBACK] Script Date: 05/23/2008 18:42:29
******/
@srvproduct=N'SQL
Server'
/* For security reasons the linked server remote logins password is changed
with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname=N'LOOPBACK',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
GO
GO
GO
@optvalue=N'false'
GO
@optvalue=N'false'
GO
@optvalue=N'true'
GO
@optvalue=N'true'
GO
@optvalue=N'false'
GO
GO
GO
GO
GO
go
use tempdb
go
create table dbo.Claves (
Clave int not null identity(1, 1) primary key
)
go
create function dbo.ufn_ProximaClave(
@p1 varchar(50)
)
returns int
as
begin
from openquery(LOOPBACK, 'begin transaction insert into tempdb.dbo.Claves
output inserted.Clave default values; rollback transaction')
end
go
create table dbo.t1 (
c1 int not null primary key,
c2 varchar(50) not null unique
)
go
insert into dbo.t1(c1, c2)
select dbo.ufn_ProximaClave(t.c1), t.c1
from
(
select 'SQL Server 2000' as c1
union all
select 'SQL Server 2005' as c1
union all
select 'SQL Server 2008' as c1
) as t
go
select *
from dbo.t1
go
drop function dbo.ufn_ProximaClave
go
drop table dbo.Claves, dbo.t1
go
Saludos,
AMB
Post by Miguel Egea
Si usas SQL 2005 puedes hacer un procedimiento como el siguiente y llamarlo
para obtener un identificador con tabla, tiene todos los inconvenientes y
ventas de los identities, no te obliga acambiar la estructura aunque ocupas
un schema. Si no usas SQL 2005 es adaptable. Creo que no tiene problemas de
inyeccin de cdigo SQL en cualquier caso ah tenis las pruebas.
create schema Maestros;
go
with execute as owner -- cambialo por alguien con permisos para crear tablas
de forma dinmica
as
begin
if not exists(select 1 from information_Schema.tables where table_name =
@tabla and Table_schema='Maestros')
begin
identity(1,1)) ' ;
end
else
begin tran
rollback tran
end
go
select * from information_schema.tables where table_schema='Maestros'
go
-- sin problemas de inyeccin de cdigo.
output
select * from information_schema.tables where table_schema='Maestros'
Saludos
Miguel Egea
Post by CHAR72
Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
del sistema para ponerle IDENTITY.
Gracias
Post by Alejandro Mesa
CHAR72,
Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY. Tendras que
usar un lazo / cursor e insertar las filas una por una.
AMB
Hola compaeros! tengo cierto inconveniente que no puedo resolver. Tengo
un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert
de
un
registro no hay inconveniente, pero ahora debo realizar varios insert
y
no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
Alejandro Mesa
2008-05-24 14:24:19 UTC
Permalink
Miguel Egea,

Creo que de esa manera puedes saber el rango insertado, pero no la clave
asignada a una fila en especifico. Crees que pudieras postear un ejemplo,
sobre todo de como hacerlo cuando usamos herramientas como BCP o SSIS package
para cargas masivas?

Gracías de antemano,
AMB
Post by Miguel Egea
yo acompaño este tipo de procedimientos con otros que devuelven un rango, de
esta forma puedo insertarlos como sifuesen consecutivos sin que esto afecte
al tratamiento de lotes.
Post by Carlos M. Calvelo
Hola Miguel,
Que gusto tenerte por aca.
El problema que afronta el OP, es que no se puede usar esa funcionalidad
cuando se inserta un batch o conjunto de filas, pues no podemos ejecutar el
procedimiento almacenado por cada fila que se inserta, si no es que se usa un
lazo o procesamiento de las filas de una en una.
Posiblemente se pueda crear un funcion de usuario y usar una de las puertas
de atras existentes (no recomendable) para poder traer ese numero. Para eso,
pudieramos crear un servidor ligado que apunte a si mismo y usar OPENQUERY
para hacer la insercion en la tabla y traer el valor identiy o posterior si
no es identity.
use master
go
/****** Object: LinkedServer [LOOPBACK] Script Date: 05/23/2008 18:42:29
******/
@srvproduct=N'SQL
Server'
/* For security reasons the linked server remote logins password is changed
with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname=N'LOOPBACK',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
GO
GO
GO
@optvalue=N'false'
GO
@optvalue=N'false'
GO
@optvalue=N'true'
GO
@optvalue=N'true'
GO
@optvalue=N'false'
GO
GO
GO
GO
GO
go
use tempdb
go
create table dbo.Claves (
Clave int not null identity(1, 1) primary key
)
go
create function dbo.ufn_ProximaClave(
@p1 varchar(50)
)
returns int
as
begin
from openquery(LOOPBACK, 'begin transaction insert into tempdb.dbo.Claves
output inserted.Clave default values; rollback transaction')
end
go
create table dbo.t1 (
c1 int not null primary key,
c2 varchar(50) not null unique
)
go
insert into dbo.t1(c1, c2)
select dbo.ufn_ProximaClave(t.c1), t.c1
from
(
select 'SQL Server 2000' as c1
union all
select 'SQL Server 2005' as c1
union all
select 'SQL Server 2008' as c1
) as t
go
select *
from dbo.t1
go
drop function dbo.ufn_ProximaClave
go
drop table dbo.Claves, dbo.t1
go
Saludos,
AMB
Post by Miguel Egea
Si usas SQL 2005 puedes hacer un procedimiento como el siguiente y llamarlo
para obtener un identificador con tabla, tiene todos los inconvenientes y
ventas de los identities, no te obliga acambiar la estructura aunque ocupas
un schema. Si no usas SQL 2005 es adaptable. Creo que no tiene problemas de
inyeccin de cdigo SQL en cualquier caso ah tenis las pruebas.
create schema Maestros;
go
with execute as owner -- cambialo por alguien con permisos para crear tablas
de forma dinmica
as
begin
if not exists(select 1 from information_Schema.tables where table_name =
@tabla and Table_schema='Maestros')
begin
identity(1,1)) ' ;
end
else
begin tran
rollback tran
end
go
select * from information_schema.tables where table_schema='Maestros'
go
-- sin problemas de inyeccin de cdigo.
output
select * from information_schema.tables where table_schema='Maestros'
Saludos
Miguel Egea
Post by CHAR72
Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
del sistema para ponerle IDENTITY.
Gracias
Post by Alejandro Mesa
CHAR72,
Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY. Tendras que
usar un lazo / cursor e insertar las filas una por una.
AMB
Hola compaeros! tengo cierto inconveniente que no puedo resolver. Tengo
un
sistema que tiene un id que lo detemina de una tabla donde guarda el ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert
de
un
registro no hay inconveniente, pero ahora debo realizar varios insert
y
no
se como obtener ese numero, intente crear una funcion que lo obtenga pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
Miguel Egea
2008-05-24 18:37:52 UTC
Permalink
Efectivamente no se que valor se le asigna a cada una :). Busco por ahí
donde lo tengo y lo posteo

Gracias Alejandro!
Post by Alejandro Mesa
Miguel Egea,
Creo que de esa manera puedes saber el rango insertado, pero no la clave
asignada a una fila en especifico. Crees que pudieras postear un ejemplo,
sobre todo de como hacerlo cuando usamos herramientas como BCP o SSIS package
para cargas masivas?
Gracías de antemano,
AMB
Post by Miguel Egea
yo acompaño este tipo de procedimientos con otros que devuelven un rango, de
esta forma puedo insertarlos como sifuesen consecutivos sin que esto afecte
al tratamiento de lotes.
Post by Carlos M. Calvelo
Hola Miguel,
Que gusto tenerte por aca.
El problema que afronta el OP, es que no se puede usar esa
funcionalidad
cuando se inserta un batch o conjunto de filas, pues no podemos
ejecutar
el
procedimiento almacenado por cada fila que se inserta, si no es que se
usa
un
lazo o procesamiento de las filas de una en una.
Posiblemente se pueda crear un funcion de usuario y usar una de las puertas
de atras existentes (no recomendable) para poder traer ese numero. Para eso,
pudieramos crear un servidor ligado que apunte a si mismo y usar OPENQUERY
para hacer la insercion en la tabla y traer el valor identiy o
posterior
si
no es identity.
use master
go
/****** Object: LinkedServer [LOOPBACK] Script Date: 05/23/2008 18:42:29
******/
@srvproduct=N'SQL
Server'
/* For security reasons the linked server remote logins password is changed
with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname=N'LOOPBACK',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
GO
@optname=N'collation
GO
GO
@optvalue=N'false'
GO
@optvalue=N'false'
GO
@optvalue=N'true'
GO
@optvalue=N'true'
GO
@optvalue=N'false'
GO
GO
@optname=N'collation
GO
GO
GO
go
use tempdb
go
create table dbo.Claves (
Clave int not null identity(1, 1) primary key
)
go
create function dbo.ufn_ProximaClave(
@p1 varchar(50)
)
returns int
as
begin
from openquery(LOOPBACK, 'begin transaction insert into
tempdb.dbo.Claves
output inserted.Clave default values; rollback transaction')
end
go
create table dbo.t1 (
c1 int not null primary key,
c2 varchar(50) not null unique
)
go
insert into dbo.t1(c1, c2)
select dbo.ufn_ProximaClave(t.c1), t.c1
from
(
select 'SQL Server 2000' as c1
union all
select 'SQL Server 2005' as c1
union all
select 'SQL Server 2008' as c1
) as t
go
select *
from dbo.t1
go
drop function dbo.ufn_ProximaClave
go
drop table dbo.Claves, dbo.t1
go
Saludos,
AMB
Post by Miguel Egea
Si usas SQL 2005 puedes hacer un procedimiento como el siguiente y llamarlo
para obtener un identificador con tabla, tiene todos los
inconvenientes y
ventas de los identities, no te obliga acambiar la estructura aunque ocupas
un schema. Si no usas SQL 2005 es adaptable. Creo que no tiene
problemas
de
inyeccin de cdigo SQL en cualquier caso ah tenis las pruebas.
create schema Maestros;
go
with execute as owner -- cambialo por alguien con permisos para crear tablas
de forma dinmica
as
begin
if not exists(select 1 from information_Schema.tables where
table_name
=
@tabla and Table_schema='Maestros')
begin
identity(1,1)) ' ;
end
else
begin tran
rollback tran
end
go
select * from information_schema.tables where table_schema='Maestros'
go
-- sin problemas de inyeccin de cdigo.
output
select * from information_schema.tables where table_schema='Maestros'
Saludos
Miguel Egea
Post by CHAR72
Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
del sistema para ponerle IDENTITY.
Gracias
en
el
Post by Alejandro Mesa
CHAR72,
Esa es una de las desventajas de generar el autonumerico de manera propia,
y no usar la facilidad de las columnas con propiedad IDENTITY.
Tendras
que
usar un lazo / cursor e insertar las filas una por una.
AMB
Hola compaeros! tengo cierto inconveniente que no puedo resolver. Tengo
un
sistema que tiene un id que lo detemina de una tabla donde guarda
el
ultimo
id y le va sumando uno por cada nuevo registro. Cuando es un insert
de
un
registro no hay inconveniente, pero ahora debo realizar varios insert
y
no
se como obtener ese numero, intente crear una funcion que lo
obtenga
pero
solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
CHAR72
2008-06-03 14:28:15 UTC
Permalink
Pues pense que mi post estaba concluido pero ahora veo que esta como para
los records Guiness !

Choque de maestros!
Post by CHAR72
Hola compañeros! tengo cierto inconveniente que no puedo resolver. Tengo
un sistema que tiene un id que lo detemina de una tabla donde guarda el
ultimo id y le va sumando uno por cada nuevo registro. Cuando es un insert
de un registro no hay inconveniente, pero ahora debo realizar varios
insert y no se como obtener ese numero, intente crear una funcion que lo
obtenga pero solo permite otras funciones o procedimientos extendidos.
Como puedo resolver la cuestion con SQL 2000?
Saludos
Carlos
Loading...