Generar mi autonumerico
![pa m]@gmail.com CHAR72's profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
pa m]@gmail.com CHAR72
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
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
pa m]@gmail.com CHAR72
del sistema para ponerle IDENTITY.
Gracias
"Alejandro Mesa" <Alejan...@discussions.microsoft.com> escribió en el
mensaje news:9110FC8E-647E-45AF...@microsoft.com...
Miguel Egea
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
"CHAR72" <char72[nos pa m]@gmail.com> wrote in message
news:OB%23saP5u...@TK2MSFTNGP04.phx.gbl...
Penta
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
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
"Penta" <crist...@gmail.com> wrote in message
news:4f40d44a-02ed-4aea...@p25g2000hsf.googlegroups.com...
Carlos M. Calvelo
On May 23, 9:54 am, "Miguel Egea" <webmas...@portalsql.com> wrote:
> 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
Hola Carlos,
On Fri, 23 May 2008 02:34:03 -0700 (PDT), "Carlos M. Calvelo"
<c_ja...@hotmail.com> wrote:
>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.
>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
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
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:br7d349s6hnh9duqr...@4ax.com...
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.
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" <c_ja...@hotmail.com> wrote in message
news:d0be1c62-de8c-44fc...@a1g2000hsb.googlegroups.com...
Hola Miguel,
On May 23, 9:54 am, "Miguel Egea" <webmas...@portalsql.com> wrote:
> 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
Miguel Egea
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..
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:br7d349s6hnh9duqr...@4ax.com...
>
Alfredo Novoa
Hola Miguel,
On Fri, 23 May 2008 13:33:09 +0200, "Miguel Egea"
<webm...@portalsql.com> wrote:
>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.
><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
Hola Miguel,
On Fri, 23 May 2008 13:36:31 +0200, "Miguel Egea"
<webm...@portalsql.com> wrote:
>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
De todas formas me confuncí en el post, leí lecturas sucias en lugar de
lecturas fantasmas :( mis disculpas.
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:1edd34tudg4flptud...@4ax.com...
Miguel Egea
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
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:6hcd349dm89qo1239...@4ax.com...
Alfredo Novoa
<webm...@portalsql.com> wrote:
>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.
>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
> On Fri, 23 May 2008 14:52:33 +0200, "Miguel Egea"
> <webm...@portalsql.com> wrote:
>
>>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.
>
> ¿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.
> Saludos
> Alfredo
Penta
hacer el select con HOLDLOCK, que segun entiendo es lo mismo que
SERIALIZABLE pero no se porque existen ambas :)
Salu2.
Penta.
Carlos M. Calvelo
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.
On May 23, 1:33 pm, "Miguel Egea" <webmas...@portalsql.com> wrote:
> 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 :-)
>
> 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
Alfredo Novoa
<webm...@portalsql.com> wrote:
>¿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.
> 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.
> 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.
>> ¿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
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" <c_ja...@hotmail.com> wrote in message
news:6cb1003f-3a7a-49e5...@59g2000hsb.googlegroups.com...
Miguel Egea
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
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:2fmd34l0u24ivqsbd...@4ax.com...
Alfredo Novoa
<webm...@portalsql.com> wrote:
>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
:-)
> 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 :-(
>Creo que la discusión técnica nos ha enriquecido un poco a todos.
Seguro que si.
Saludos
Alfredo
umak
> 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
umak
> 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
>> 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
Carlos M. Calvelo
No es precisamente ese el significado del nivel de aislamiento
serializable?
umak
> > 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
umak
> > 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
1,$? solo tu linea? o solo la mía?
En cualquier caso no aclara nada.
Saludos,
Carlos
umak
> > 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)
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.
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.
> sqlserver elige una sesion para matar y si mi aplicacion es matada por
> sqlserver me gusta saberlo
Es fácil saberlo :-)
Saludos
Gux (MVP)
"umak" wrote:
>
> 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 :-)
Gux (MVP)
> ?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.
Carlos M. Calvelo
> 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
> ?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.
> 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
Alfredo Novoa
Hola Carlos,
El Fri, 23 May 2008 13:20:35 -0700 (PDT), Carlos M. Calvelo escribió:
> On 23 mei, 22:06, Gux (MVP) <Gux...@discussions.microsoft.com> wrote:
>> 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
Alfredo Novoa
Hola Gux,
El Fri, 23 May 2008 13:13:01 -0700, Gux (MVP) escribió:
>> ?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
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
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:sbrd34dh2fodp6mjt...@4ax.com...
Miguel Egea
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
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:nbhvjb1ydvlv$.cz2p1m2nwpiv.dlg@40tude.net...
Alfredo Novoa
> 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.
> 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.
> 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
> 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
Alejandro Mesa
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
"Miguel Egea" wrote:
> 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
> create proc Maestros.GeneraClave (@tabla Sysname,@valor int output)
> with execute as owner -- cambialo por alguien con permisos para crear tablas
> de forma dinmica
> 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 inyeccin de cdigo.
> 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
>
>
>
> "CHAR72" <char72[nos pa m]@gmail.com> wrote in message
> news:OB%23saP5u...@TK2MSFTNGP04.phx.gbl...
> > Lamentablemente las cosas estan asi, habria que cambiar toda la estructura
> > del sistema para ponerle IDENTITY.
> >
> > Gracias
> >
> > "Alejandro Mesa" <Alejan...@discussions.microsoft.com> escribi en el
> > mensaje news:9110FC8E-647E-45AF...@microsoft.com...
> >> 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
> >>
> >> "CHAR72" wrote:
> >>
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >
> >
>
Gux (MVP)
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.
Gux (MVP)
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.
Miguel Egea
esta forma puedo insertarlos como sifuesen consecutivos sin que esto afecte
al tratamiento de lotes.
"Alejandro Mesa" <Alejan...@discussions.microsoft.com> wrote in message
news:2FF601E7-6A0D-44C5...@microsoft.com...
Alejandro Mesa
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
Miguel Egea
donde lo tengo y lo posteo
Gracias Alejandro!
"Alejandro Mesa" <Alejan...@discussions.microsoft.com> wrote in message
news:7991454B-A10B-4661...@microsoft.com...
Miguel Egea
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
"Alfredo Novoa" <alfr...@gmail.com> wrote in message
news:riu4p3ffu0up.d6m0m93raarm$.dlg@40tude.net...
Gux (MVP)
> 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.
Gux (MVP)
> > 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.
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
Hola Miguel,
El Sat, 24 May 2008 20:50:34 +0200, Miguel Egea escribió:
> 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.
> 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.
> 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.
> 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/
> 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
:-)
> 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
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)
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.
Gux (MVP)
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.
Carlos M. Calvelo
On 24 mei, 20:50, "Miguel Egea" <webmas...@portalsql.com> wrote:
> 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.
> 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.
> 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.
>
> 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.
> 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!
>
> 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
Alfredo Novoa
> 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
Gux (MVP)
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.
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
Carlos M. Calvelo
On 25 mei, 01:27, Gux (MVP) <Gux...@discussions.microsoft.com> wrote:
> 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
> 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
Gux (MVP)
>
> 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.
Alfredo Novoa
> "Alfredo Novoa" wrote:
>>> 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
Alfredo Novoa
Hola Carlos,
El Sat, 24 May 2008 16:12:33 -0700 (PDT), Carlos M. Calvelo escribió:
>> 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 :-)
> 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
Gux (MVP)
> pq sqlserver tiene diseño de los 80s, oracle y db2 de los 70s...
"Alfredo Novoa" wrote:
> Si, pero el diseño de los 3 es muy parecido. SQL Server no innovó mucho que
digamos.
> 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 :-)
Carlos M. Calvelo
On 25 mei, 01:44, Alfredo Novoa <alfred...@gmail.com> wrote:
> Hola Carlos,
>
> El Sat, 24 May 2008 16:12:33 -0700 (PDT), Carlos M. Calvelo escribió:
>
> >> 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
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?
> 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
Carlos M. Calvelo
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
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" <c_ja...@hotmail.com> wrote in message
news:8d54ed12-6367-45f2...@c65g2000hsa.googlegroups.com...
Carlos M. Calvelo
On 25 mei, 12:27, "Miguel Egea" <webmas...@portalsql.com> wrote:
> 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.
>
> 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
Maxi Accotto
> 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
-------------------------------
"Gux (MVP)" <Gux...@discussions.microsoft.com> escribió en el mensaje de
noticias:4FD7156E-7296-4DBD...@microsoft.com...
Alfredo Novoa
> 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
Alfredo Novoa
> 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
pa m]@gmail.com CHAR72
los records Guiness !
Choque de maestros!
"CHAR72" <char72[nos pa m]@gmail.com> escribió en el mensaje
news:OYzRn23u...@TK2MSFTNGP06.phx.gbl...
> 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
>
>
>