Procedimientos Almacenados

Sobre sobre esta última ...

Sobre todo esta última...

Yo no me trago todo lo que leo. Ni voy a darte un link donde puedas
leer eso. Si quieres me monto yo una página web, lo pongo allí y tu
lo lees. :)

Yo tampoco me trago todo lo que leo, pero si lo analizo y veo quienes lo
escriben, mis links no son de cualquier paginita, son de empresas como
Microsoft IBM y de personas expertas en bases de datos. Ahora bien no creo
que tengas el derecho a decir que son cualquier cosa, quizas no te gusta lo
que dicen pero son referencias importantes, no es Doña Rosa quien lo dice y
lo publica, son las empresas numero 1 y numero 2 de tecnologia quienes lo
exponen, son los gurues de SQLServer quienes opinan igual. Esta muy bien no
opinar lo mismo pero las cosas se deben demostrar amigo!

No, no me los imagino. No determina la aplicación lo que puede hacer
un usuario con una tabla sino el SGBD.

Perdona no, pero tu has trabajo en empresas donde tengan el departamento de
seguridad informatica? es cierto que las aplicaciones deben hacer uso de las
tablas pero en si no lo hace la aplicacion sino un login, el que tiene
permisos es un login, y lo que se busca a nivel seguridad informatica en
cualquier empresa seria (Bancos, organismos internaciones, etc) es que a los
datos no se acceda de cualquier lado, entonces si tu aplicacion usa el login
X, el X1 y asi por cada usuario, tu le tienes que dar permisos a las tablas
para poder hacer un select verdad? ahora bien, ese login podria ser usado
fuera de tu sistema por ese usuario y acceder a los datos, no es algo que
cumpla con los standares de seguridad esto en ningun lugar de estos que te
comente, ahora bien, en los sistemas para la casa de Doña Rosa que tiene un
SQL y ni DBA o ni gente de sistemas cualquier cosa es lo mismo.
ME gustaria si tienes otra experiencia que me cuentes en que empresa de
primer nivel a ti te dejan que los usuarios sql puedan desde cualquier
terminal (por ejemplo con un Excel) bajar informacion, insertar datos, etc.
Ahora bien si tu diseñas la aplicacion con un solo usuario a nivel SQL
entonces estamos en otro problema de seguridad mas grave, pero es importante
diferenciar una cosa de la otra, si es un solo usuario lo que dije no tiene
sentido porque la seguridad la terminas controlando a nivel aplicacion, pero
eso no es un motor de base de datos seguro, no podes hacer auditorias
serias, no podes hacer buenos monitoreos, etc, en fin perdes funcionalidad
importante que cualquier departamento de seguridad informatica necesida y
que ademas son auditados

>Y no es eso lo mismo que que entre y que pueda hacer
>un 'execute insert_proc'?

No, no es lo mismo y te explico porque, suponete que en tu SP de insert has
definido alguna regla de negocios, si lo hace por medio del SP la regla de
negocios (leer bien por favor, dije negocios y no integridad) se ejecutara,
si el usuario hace solo el insert la regla no existe a menos que la tengas
implementada en un trigger.

A mi no me interesa cuantos programadores ni desde cuantas
aplicaciones hagan ese select. Solo me interesa que sea cual sea la
forma que tenga el select/insert/update/delete, siempre se cumpla
con las reglas de integridad.

Eso no esta en discusion amigo, si las reglas de integridad estan en la base
de datos no problem. Ahora bien, yo aca hablaba de otra cosa, te deberia en
principio si importar en donde tienes el codigo y que aplicaciones hacen uso
de cual o tal tabla, es una cuestion de control y para hacer cambios en la
estructura de base de datos es fundamental

Si ademas de que quieras que no importa de donde llamen se cumplan las
reglas de negocio es en donde los Store te dan una mejor mano.

"Siempre hará lo mismo" no es una ventaja. Y las reglas de integridad
también se pueden poner sobre la tabla para determinar lo que puede
hacer con ella. (no ves que andamos en círculos?)

Si las de integirdad si y eso no tiene discusion, pero las de negocio no a
menos que uses triggers.

Ahora cada una de estas dos capas puedes dividirlas en todas las
capas físicas que tu quieras, pero el 'acceso a datos' pertenece al
lado del SGBD. En cuanto al business layer (supongo que eso quieres
decir con 'BI') será para implementar 'business rules'. Este es un
término que si se analiza bien, lo que realmente significa viene a
no ser más que 'reglas de integridad de datos'. Esta capa física es
también responsabilidad del SGBD.

Mmm BL = businnes rules eso en español significa (Regla de negocios y no
regla de datos) Viendo todo tu texto creo que hay confusion entre una regla
de datos o integridad y una regla de negocios.
Ejemplos de BL: Para poder vender este producto el cliente no debe tener
una mora
No se permiten pedidos de clientes que tengan
deudas
No se puede hacer una venta de un producto si
no hay en inventario

Reglas de integridad: En el campo Fecha solo se admiten valores datetime
El campo edad debe ir desde 1 a 99
En campo de la tabla detalle debe
corresponder con un pk de cabecera.

El acceso a datos no esta dentro del SGBD por eso se llama acceso a datos
DAL (Data Access Layer) es la capa que permite conectarnos con la capa de
datos, el mismo nombre lo indica.

Un select * ... no es un 'acceso a datos'. Es una interfaz de mucho
mayor nivel de abstracción que cualquier procedimiento (me repito otra
vez!)

Aca no te entiendo, un select es un acceso a datos, no es ninguna inerfaz,
cuando haces un select obtenes datos de la capa de datos, ese select esta en
la capa de acceso a datos.

Por qué insistes en llamarle a eso 'acceso a datos' y a una llamada
a un procedimiento que es mucho mas limitado y solo hace lo mismo
para un pequeño número de casos, no le llamas lo mismo?

Si es lo mismo, un EXEC SP es acceso a datos pero por medio de otro
componente, en este caso los Store Procedures y no los objetos directos de
tu aplicacion.

Como bien dices 'por toda query'! El plan es por query, no por SP.
Porque todo el mundo hable de planes para SP's habrá que seguir
pensando cada uno por si mismo, y tratar de saber que es lo que se
está diciendo exactamente.

A ver el SP guarda el plan precompilado amigo, te has leido los libros
online sobre la arquitectura de Store Procedures? te recomiendo una leida
asi ves como funciona.

Pues muy mal por los DTS!

Por tu aplicacion y diseño si no contemplas algunos factores

Y lo puedes poner en un check, o en un trigger. Entonces para eso no
hace falta denegar acceso a la tabla.

Si pero que tiene que ver el acceso a la tabla desde cualquier lado con el
login de SQL que estes usando (seguridad) a reglas de integridad?

Si que está mal! Debe ir con la bbdd y el SGBD es el que debe
asegurar que se cumpla esa lógica (integridad de datos!).

pero si la pones en un SP estas centralizandola.

y en check o trigger también.

Estasmos hablando de cosas distintas, tu hablas de reglas de integridad y yo
de negocios, las de integridad ya te dije que coincido contigo, pero las de
negocio pueden estar dentro o fuera de la bdd, si estan dentro para hacerlas
podes o usar trigger o Store, si usas trigger haras que las transacciones
duren mas y tengas mas bloqueos, imaginate si por cada factura a grabar hay
que verificar si el cliente tiene saldo deudor y de ser asi no permitir
grabar la factura, si comprobas durante una transaccion (como es el caso del
trigger) tus bloqueos aumentan de forma innecesaria haciendo el sistema mas
lento entre otros tantos problemas

Toda la estructura es 'reutilizable', etc.

No es cierto, si la consulta la haces desde la aplicacion es mas dificil de
reutilizar, quizas seas muy bueno y la hayas hecho con objetos y puedas
reutilizar ese objeto en si, pero los


Cerrando:

Creo que en muchas cosas estamos hablando de lo mismo pero sin
interpretarnos, cuando yo hable de reglas de negocio no eran las de
integridad y todo lo que tu explicas esta basado en reglas de integirdad lo
cual comparto 100% contigo.

Te mostre las ventajas del uso de Stores, te mostre documentos tecnicos de
las empresas mas importantes, bueno mi parte esta terminada aqui, a partir
de este momento puedo pensar algunas cosas

1) No has leido los documentos
2) No los has interpretado
3) Los has leido y los has interpretado pero a ti no te gustan los Store
Procedures (y estaria muy bien :-)

Ahora bien, es mejor decir yo no programo con Store porque en mi
arquitectura no me es util a decir que las ventajas que si estan documentas
son falsas, son cosas distintas, uno puede hacer su aplicacion como mas le
guste, aplicar una u otra cosa, lo que no puede uno hacer sin fundamentos o
demostraciones es contradecir lo que otro si ha demostrado y escrito, mas si
ese otro es un ente importante o algun referente, podriamos tambien
contradecir a varios matematicos y fisicos con ese criterios, pero para
poder hacerlo (que estaria bueno) seria cuestion de demostrar la otra teoria
:-)

Que se yo, desde lo tecnico esta todo dicho y con documentacion que avala lo
que exprese en todo este enorme hilo, de ahora en mas queda en ti, tu puedes
decirnos a todos que la tierra es cuadrada pero todos cuando vemos fotos,
leemos los libros, etc vemos que es redonda :-)

Un abrazo y espero verte pronto



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Carlos M. Calvelo" escribió en el mensaje de
noticias:

Hola Maxi,

On Apr 24, 10:56 pm, "Maxi" wrote:

Carlos, calmemos un poco las aguas,

Yo estoy muy calmado :)

a ver, yo he simplemente pasado una
serie de referencias pero hay miles mas de paginas
comowww.sql-server-performance.comdonde podras encontrar varios articulos
de
arquitectura y buenas practicas, tambien puedes revisar los documentos de
arquitectura de Microsoft en su pagina. Solo expuse algunos links si
quieres
busco mas y seran tan serios como los anteriores, tu solamente me has
indicado un libro, yo quiero que me indiques un link donde diga: El uso
de
SP no ayuda a la seguridad, no ayuda a la centralizacion no ayuda a la
performance. Quiero leer eso porque es lo que estamos discutiendo
basicamente, yo no digo que siempre hay que usarlos, pero digo que tienen
ventajas enormes usarlos y enumere los items donde las tienen.

Yo no me trago todo lo que leo. Ni voy a darte un link donde puedas
leer eso. Si quieres me monto yo una página web, lo pongo allí y tu
lo lees. :)

Yo no me trago cualquier cosa como buena práctica ni dejo que 'las
autoridades' decidan por mi lo que es una buena arquitectura. Leo
y determino, dentro de mis posibilidades, lo que creo que vale la
pena. Voy acumulando así cierta visión de las cosas y voy
determinando qué autores vale la pena tomar en en serio y cuales no.
De los que tomo en serio no me trago tampoco todo sino que evaluaré
todo lo que proponen según mi nivel en ese momento.

Ahora voy a
ir linea por linea de tus comentarios a reponderte :-) porque considero
que
todo suma.
Disculpame no me has ofendido

No problem!

y tienes razon, tomemos esto como debe ser y
es una discusion entre 2 profesionales de forma tecnica :-)

Vamos a los puntos.

Entonces si es necesario. Hay que darle acceso; o sea permiso de
ejecución.

R: Si pero no a los objetos finales sino solo al SP y no importa donde
este
SP haga la llamada ni a cuantos objetos, solo le das acceso al SP y nada
mas, entonces por ejemplo te aseguras que siempre hagan por ejemplo la
insercion de tu factura por medio del SP y no por ejemplo por medio de un
access, excel o cualquier otro sitio. Si cambias algo de logica lo haces
en
el SP y la llamada puede hasta ser la misma, imaginate que el proceso
ahora
requiere hacer una verificacion o bien guardar en otra tabla algo, eso lo
programas en el SP y desde tu aplicacion es transparente.

Aquí repites lo que ya has dicho antes. No voy a repetir mi
respuesta porque estamos dando vueltas en el mismo círculo.

>Y eso qué ventaja tiene?
>Las ventajas que tu has dado (tu mismo y en links) no son ventajas
>específicas de SP's, sino que también se puede decir de tablas base
>y de vistas.

bueno aca hay uno de los puntos, si este punto no se comprende entonces
no
podemos hablar de ventajas de los SP.
Tu no deberias permitir que los usuarios hagan insert sobre las tablas de
forma directa, de hecho ni las deberian conocer, es una cuestion de que
puedas controlar de donde y como se hace y que ademas las tablas no sean
accedidas de aplicaciones

Espero que no te sientas ofendido, porque no te estoy calificando a
ti sino lo que has puesto aquí arriba. Tengo que darle la razón
a Alfredo; es mas lo repito con ahínco: "Esto es una barbaridad!"
(A las cosas hay que llamarlas por su nombre.)

que no son las que tu has diseñado, imafginate un
soft de gestion donde tienes una tabla clientes, bien, si desde tu
aplicacion usas Select o insert el usuario que se conecta desde la misma
debe tener permisos sobre la tabla, ahora bien tu al darle permisos sobre
la
tabla ese usuario puede hacer uso de ella desde cualquier otro lado, por
ejemplo un excel, una aplicacion que a el se le ocurra desarrollar etc,
con
lo cual puede estar haciendo operaciones en tu sistema de forma externa y
no
controlada por ti. Te imaginas los problemas de esto no?

No, no me los imagino. No determina la aplicación lo que puede hacer
un usuario con una tabla sino el SGBD.

>La aplicación puede entrar de formas desconcidas para el usuario
>en la bbdd. El mismo usuario puede tener un login própio para
>utilizar con otras herramientas. Aunque si el sistema de seguridad
>está bien diseñado no veo ninguna ventaja en ello.
>Con lo de los roles me estoy refiriendo a los roles en la bbdd.
>En definitiva.. se puede uno montar muchos esquemas de seguridad
>distintos.

Como en forma desconocida? tu deberias tener por cada usuario de tu
aplicacion un login en el SQL para poder controlar la seguridad y ademas
monitorear, hacer auditorias, etc. Si usas un usuario generico estamos
hablando de otro esquema de sistemas y por lo general son ambientes Web.

>Y no es eso lo mismo que que entre y que pueda hacer
>un 'execute insert_proc'?

No porque si por ejemplo en el SP de insert tu has definido alguna regla
se
ejecutara no importa de donde lo llames que siempre hara lo mismo. Ademas
hasta podrias el dia de mañana cambiar algo en el proceso de insert y
solo
tocas el SP (si es que no cambian los param de entrada claro)

"Siempre hará lo mismo" no es una ventaja. Y las reglas de integridad
también se pueden poner sobre la tabla para determinar lo que puede
hacer con ella. (no ves que andamos en círculos?)

>El código de las queries (o el de las llamadas a procedimentos
>almacenados) es la interfaz entre aplicaciones y el SGBD.
>En cuanto a 'la capa de acceso a datos' creía yo que estaba esta
>en el SGBD.
>Yo le digo al SGBD 'SELECT Esto FROM LoOtro WHERE EstoOtro' y el
>SGBD 'accede a los datos' (a este nivel no me interesa como) y me
>los devuelve.

Bueno aca hay un error de conceptos,

Eso es algo seguro! :)

la capa de acceso a datos es la que se
encarga de interactuar con la capa de datos (esta si es la base en si),
en
la capa de acceso a datos te puede conectar con la capa de datos via
Select
o via Stores.

Lo que si te interesa que si vos tenes un select * from clientes y lo
usas
en mas de un modulo o en mas de una aplicacion, si armas un SP lo podes
reutilizar en cualquier aplicacion en cualquier sitio y no te interesa
como
programador que haga ese SP solo lo llamas, con lo cual te abstraes aun
mas.

A mi no me interesa cuantos programadores ni desde cuantas
aplicaciones hagan ese select. Solo me interesa que sea cual sea la
forma que tenga el select/insert/update/delete, siempre se cumpla
con las reglas de integridad.

>Yo no digo que sean o no sean parte del modelo relacional. Digo que
>no son parte de la solución al problema que trata de solucionar el
>modelo. Esconder la estructura de la base de datos y un lenguaje
>relacional detrás de una biblioteca de procedimientos no es la
>solución.

A ver, tu deberias manejar un patron denominado Capas ok, seria la forma
correcta de hacer una aplicacion, entonces aqui tiene

OK!

UI -BI - DAL - DataBase

Esto es una tontería que desgraciadamente está muy extendida. En un
sistema tenemos Aplicaciones y Servidor. Aplicaciones pueden ser
muchas y el Servidor (SGBD) puede representar una base de datos
distribuida por toda la organización o hasta fuera de ella. Estas
son dos capas lógicas.

Ahora cada una de estas dos capas puedes dividirlas en todas las
capas físicas que tu quieras, pero el 'acceso a datos' pertenece al
lado del SGBD. En cuanto al business layer (supongo que eso quieres
decir con 'BI') será para implementar 'business rules'. Este es un
término que si se analiza bien, lo que realmente significa viene a
no ser más que 'reglas de integridad de datos'. Esta capa física es
también responsabilidad del SGBD.

Al lado del las Aplicaciones solo queda el UI (user interface)
entonces, y al lado del servidor solo queda el SGBD que es el
responsable de 'la integridad' (BI) y debajo de esto el 'acceso a
datos'. La integridad la definimos con 'integrity constraints' y
del acceso a datos no nos temenos que preocupar para nada, aparte
de a nivel físico tratar de elevar la eficiencia de cierto tipo de
consultas (a veces a costa de otras) con ciertos mecanismos,
como por ejemplo índices.

Los Store procedure te ayudan mucho porque desde tu DAL solamente haces
un
llamado a una caja negra y es menos acoplable.

Un select * ... no es un 'acceso a datos'. Es una interfaz de mucho
mayor nivel de abstracción que cualquier procedimiento (me repito otra
vez!)

Por qué insistes en llamarle a eso 'acceso a datos' y a una llamada
a un procedimiento que es mucho mas limitado y solo hace lo mismo
para un pequeño número de casos, no le llamas lo mismo?

Si queres reutilizar ese SP
lo podes hacer de N aplicaciones en N lenguajes de programacion.

Si quieres reutilizar un select * ... de mil maneras distintas lo
puedes hacer desde N+M aplicaciones y desde N+M lenguages de
programación. :)

Ahora bien
vos a que solucion de modelo hablas? aca estamos hablando de programacion
y
de arquitectura de aplicaciones.

Arquitectura de 'systemas'. Busca información sobre la arquitectura
ANSI-SPARC. En el libro de Date (yo tengo la edición 8) viene una
buena introducción, creo que el segundo capítulo.

no me queda claro que solucion no te da el
SP al modelo.

>Pues el que utiliza SQL Server para eso.
>Por cierto son las consultas en el SP las que tienen planes de
>ejecución no el SP mismo. El plan de ejecución del SP lo programmo
>yo diciendole: 'primero haces esto, después si esto es verdad
>haces esto otro y si no repites esta otra cosa X veces'.

Esto si no te lo comprendo, yo estoy hablando del plan de ejecucion
interno
de SQL por toda query que uno realiza, el evalua cual es el mejor camino
a
realizar (que indices usar, como usarlos etc) Este calculo SQL lo hace
por
cada ejecucion, en un SP ese calculo queda compilado y no debe calcularlo
siempre.

Como bien dices 'por toda query'! El plan es por query, no por SP.
Porque todo el mundo hable de planes para SP's habrá que seguir
pensando cada uno por si mismo, y tratar de saber que es lo que se
está diciendo exactamente.

>Para 'verificar cosas' tenemos los constraints. Y cuando estos
>no den mas de sí, los triggers.

Si claro, primero hay que tener un bien diseño con sus constraint. Pero
los
trigger no son siempre utiles para hacer verificaciones, por ejemplo
debes
saber que si correc un proceso BCP o DTS los trigger se deshabilitan por
default con lo cual si has puesto logica ahi puedes estar en problemas.

Pues muy mal por los DTS!

Otro de los lugares donde se pone logica o verificaciones en el los Store
Procedures, entonces si tenemos un SP de grabar factura y antes de eso
hay
que verificar si el cliente tiene credito por ejemplo, lo puedes poner en
el
SP.

Y lo puedes poner en un check, o en un trigger. Entonces para eso no
hace falta denegar acceso a la tabla.

Es cierto que la logica de negocios puede ir fuera y eso no esta mal,

Si que está mal! Debe ir con la bbdd y el SGBD es el que debe
asegurar que se cumpla esa lógica (integridad de datos!).

pero si la pones en un SP estas centralizandola.

y en check o trigger también.

En los triggers tambien se suele poner logica de negocios, pero como
veras
no es una cosa si y la otra no, pueden ser ambas, yo por lo general lo
prefiero en los SP porque el trigger esta dentro de una transaccion y si
me
pongo ahi a aplicar logica voy a tener transacciones mas largas y por
ende
mayores bloqueos que hasta pueden derivar en un interbloqueo.

Todo lo que lógicamente tengas que hacer en una transación no es menos
por ponerlo en un SP.

>Además nadie está diciendo (yo no por lo menos) que no tenga ninguna
>aplicación los SP's. Pero el esconder la estructura de los datos
>de las aplicaciones y los usuarios no es una de ellas.

Bueno como que no, es una forma de abstraccion y de seguridad para que
nadie
acceda de forma directa a los objetos.

Estos *objetos* son una estructura lógica que es (debe ser) pública
en la organización. (Dependiendo que la seguridad y identidad de cada
uno claro!)

Tambien comente otros factores,
reutilizacion, administracion, etc.

Toda la estructura es 'reutilizable', etc.

Hasta analisis de problemas, imaginate que tu servidor de base de datos
tiene problemas de performance, entonces se puede para ver las causas
analizar los procesos, se puede montar un profiler y ademas un
performance
monitor, pero si tenemos SP hasta podriamos verificar si hay malas
practicas
en ellos con el Best Practice Analyzer de Microsoft.

Bueno no creo que llegemos a un punto en comun pero si me gustaria
aclarar
algunos conceptos.

No vamos a llegar a ese punto común Maxi. Con este último mensage
tuyo nos hemos separado mas. Ya estamos muy en desacuerdo sobre lo
que es una base de datos y un sgbd; pero ahora nos hemos salido
a la arquitectura del sistema y las diferencias son abismales en
cuanto a conceptos. Y (obviamente) yo creo, sé :), que eres tu
el que está equivocado.

Saludos

Te recomiendo los doc de arquitectura en capas de Microsoft, son muy
buenos
y tambien estan en español :-)

Lo que pienso sobre esas capas ya lo comenté arriba. He sido miembro
el el pasado de un equipo (con gente y empresas de tres países
en Europa) que ha desarrollado un enorme projecto con esas ideas.
Estoy hablando de ya antes del 2000. No te lo puedo demostrar a tí
(ni a nadie) que así sea claro, pero yo sé ahora con total seguridad
que esa ha sido la causa de que resultó en un desastre total. Pero
bueno esa es una experiencia personal, y en esta discusión solo una
anécdota.

Saludos,
Carlos

Hola Maxi,

On 26 apr, 00:03, "Maxi Accotto"
wrote:

> Yo no me trago todo lo que leo. Ni voy a darte un link donde puedas
> leer eso. Si quieres me monto yo una página web, lo pongo allí y tu
> lo lees. :)

Yo tampoco me trago todo lo que leo, pero si lo analizo y veo quienes lo
escriben, mis links no son de cualquier paginita, son de empresas como
Microsoft IBM y de personas expertas en bases de datos. Ahora bien no creo
que tengas el derecho a decir que son cualquier cosa

Por qué no tengo ese derecho? Tu crees posible que haya una remota
posiblidad de que mucha gente escribe de lo que no entiende?

Maxi, a mi muchos 'expertos' me hacen reir. O dependiendo de mi
estado de ánimo, 'casi llorar'.

, quizas no te gusta lo
que dicen pero son referencias importantes, no es Doña Rosa quien lo dice y
lo publica, son las empresas numero 1 y numero 2 de tecnologia quienes lo
exponen, son los gurues de SQLServer quienes opinan igual. Esta muy bien no
opinar lo mismo pero las cosas se deben demostrar amigo!

La ideas y 'opiniones' expresadas aquí no son mías. Son el resultado
de muchos años de busqueda y aprendizaje. Yo no me se expresar muy
bien, y por eso se te han dado referencias Maxi.

> No, no me los imagino. No determina la aplicación lo que puede hacer
> un usuario con una tabla sino el SGBD.

Perdona no, pero tu has trabajo en empresas donde tengan el departamento de
seguridad informatica?

Es las segunda vez que me preguntas eso y es totalmente irrelevante
lo que yo haga o deje de hacer.

Tengo 20+ años de experiencia como desarrollador de software y por
casulidad ahora estoy trabajando para un banco. Y tienen que pagar
bastante por mí que estoy allí por medio de otra (mi) empresa.
Sigue siendo totalmente irrelevante y no demuestra nada.

es cierto que las aplicaciones deben hacer uso de las
tablas pero en si no lo hace la aplicacion sino un login, el que tiene
permisos es un login, y lo que se busca a nivel seguridad informatica en
cualquier empresa seria (Bancos, organismos internaciones, etc) es que a los
datos no se acceda de cualquier lado, entonces si tu aplicacion usa el login
X, el X1 y asi por cada usuario, tu le tienes que dar permisos a las tablas
para poder hacer un select verdad? ahora bien, ese login podria ser usado
fuera de tu sistema por ese usuario y acceder a los datos, no es algo que
cumpla con los standares de seguridad esto en ningun lugar de estos que te
comente, ahora bien, en los sistemas para la casa de Doña Rosa que tiene un
SQL y ni DBA o ni gente de sistemas cualquier cosa es lo mismo.

En banco donde yo trabajo ahora no es de la Doña Rosa.
Y hay DBA's por todos los lados.

ME gustaria si tienes otra experiencia que me cuentes en que empresa de
primer nivel a ti te dejan que los usuarios sql puedan desde cualquier
terminal (por ejemplo con un Excel) bajar informacion, insertar datos, etc.

Te repito que es totalmente irrelevante mi expreriencia.

Ahora bien si tu diseñas la aplicacion con un solo usuario a nivel SQL
entonces estamos en otro problema de seguridad mas grave, pero es importante
diferenciar una cosa de la otra, si es un solo usuario lo que dije no tiene
sentido porque la seguridad la terminas controlando a nivel aplicacion, pero
eso no es un motor de base de datos seguro, no podes hacer auditorias
serias, no podes hacer buenos monitoreos, etc, en fin perdes funcionalidad
importante que cualquier departamento de seguridad informatica necesida y
que ademas son auditados

Y tu todo eso lo resuelves con SP's.
Vale! Esa es tu experiencia.

Sigue las referencias que se te han dado y deja mi
experiencia o la tuya de lado. No son representativas.

>> >Y no es eso lo mismo que que entre y que pueda hacer
>> >un 'execute insert_proc'?

No, no es lo mismo y te explico porque, suponete que en tu SP de insert has
definido alguna regla de negocios, si lo hace por medio del SP la regla de
negocios (leer bien por favor, dije negocios y no integridad) se ejecutara,
si el usuario hace solo el insert la regla no existe a menos que la tengas
implementada en un trigger.

Lee tu bien:
'Regla de negocios' es en el contexto de sistemas de
información un termino informal para 'regla de integridad'.

> A mi no me interesa cuantos programadores ni desde cuantas
> aplicaciones hagan ese select. Solo me interesa que sea cual sea la
> forma que tenga el select/insert/update/delete, siempre se cumpla
> con las reglas de integridad.

Eso no esta en discusion amigo, si las reglas de integridad estan en la base
de datos no problem. Ahora bien, yo aca hablaba de otra cosa, te deberia en
principio si importar en donde tienes el codigo y que aplicaciones hacen uso
de cual o tal tabla, es una cuestion de control y para hacer cambios en la
estructura de base de datos es fundamental

Te recuerdo que la estructura es parte de la interfaz con el resto
del sistema. Me refiero a la estructura del modelo lógico.
Cambiar esa estructura va a tener muchas consencuencias.
Te remito otra vez a la arquitectura ansi-sparc.

Si ademas de que quieras que no importa de donde llamen se cumplan las
reglas de negocio es en donde los Store te dan una mejor mano.

vease arriba 'regla de negocio'

> "Siempre hará lo mismo" no es una ventaja. Y las reglas de integridad
> también se pueden poner sobre la tabla para determinar lo que puede
> hacer con ella. (no ves que andamos en círculos?)

Si las de integirdad si y eso no tiene discusion, pero las de negocio no a
menos que uses triggers.

'El número de cliente debe ser un 'número' ente 1 y 1000000'
Esto es una regal de integridad. Informalmente se le puede
llama una 'regla de nogocio', pero a mi no me gusta ese
término.

Para esta 'regla de negocio' no me hace falta ningún trigger.

> Ahora cada una de estas dos capas puedes dividirlas en todas las
> capas físicas que tu quieras, pero el 'acceso a datos' pertenece al
> lado del SGBD. En cuanto al business layer (supongo que eso quieres
> decir con 'BI') será para implementar 'business rules'. Este es un
> término que si se analiza bien, lo que realmente significa viene a
> no ser más que 'reglas de integridad de datos'. Esta capa física es
> también responsabilidad del SGBD.

Mmm BL = businnes rules eso en español significa (Regla de negocios y no
regla de datos)

No.. es que tu habías puesto BI, no BL !!

'regla de integidad de datos' Qué problema hay con eso?

Viendo todo tu texto creo que hay confusion entre una regla
de datos o integridad y una regla de negocios.

De eso estoy seguro! Pero ahora creo que ya estará claro no? ;-)

Ejemplos de BL: Para poder vender este producto el cliente no debe tener
una mora
No se permiten pedidos de clientes que tengan
deudas
No se puede hacer una venta de un producto si
no hay en inventario

Eso son reglas de integridad como cualquier otra.

Reglas de integridad: En el campo Fecha solo se admiten valores datetime
El campo edad debe ir desde 1 a 99
En campo de la tabla detalle debe
corresponder con un pk de cabecera.

Estas también.
Y hay quien tanto a estas últimas como la las anteriores les llama
'reglas de nogocios'. Yo prefiero reglas de integridad. Y si todo
el mundo hiciera lo mismo no tendríamos ahora esta discusión.

El acceso a datos no esta dentro del SGBD por eso se llama acceso a datos
DAL (Data Access Layer) es la capa que permite conectarnos con la capa de
datos, el mismo nombre lo indica.

Un SGBD no es un capa de datos. Esta una de las cosas que esta
precisamente encapsula. Para que las aplicaciones puedan conseguir
independencia física de datos. Te remito aquí otra vez al libro de
Date.

> Un select * ... no es un 'acceso a datos'. Es una interfaz de mucho
> mayor nivel de abstracción que cualquier procedimiento (me repito otra
> vez!)

Aca no te entiendo, un select es un acceso a datos,

No no no! Es un programa!! y su 'plan de ejecución' del que tu
tanto sabes es el que a un mucho mas bajo nivel determina como se
accede a los datos.
(independencia física de datos!)

no es ninguna inerfaz,

Si es un interfaz. Es un lenguage para acoplar aplicaciones
de todo tipo con SGBD's

cuando haces un select obtenes datos de la capa de datos, ese select esta en
la capa de acceso a datos.

Obtienes datos del SGBD, este encapsula la capa de datos.

Esto de las capas UI-BL-DAL-SGBD realmente hace estragos con la gente.

> Por qué insistes en llamarle a eso 'acceso a datos' y a una llamada
> a un procedimiento que es mucho mas limitado y solo hace lo mismo
> para un pequeño número de casos, no le llamas lo mismo?

Si es lo mismo, un EXEC SP es acceso a datos pero por medio de otro
componente, en este caso los Store Procedures y no los objetos directos de
tu aplicacion.

A este nivel el EXEC SP es lo mismo que un Select (en este aspecto)

> Como bien dices 'por toda query'! El plan es por query, no por SP.
> Porque todo el mundo hable de planes para SP's habrá que seguir
> pensando cada uno por si mismo, y tratar de saber que es lo que se
> está diciendo exactamente.

A ver el SP guarda el plan precompilado amigo, te has leido los libros
online sobre la arquitectura de Store Procedures? te recomiendo una leida
asi ves como funciona.

Si, para el SP podrá guardar el plan que he programado yo. Para
la consultas que yo use en ese plan mío podrá determininar el
SGBD sus planes.

> Pues muy mal por los DTS!

Por tu aplicacion y diseño si no contemplas algunos factores

Mi aplicación no tumba los triggers.

> Y lo puedes poner en un check, o en un trigger. Entonces para eso no
> hace falta denegar acceso a la tabla.

Si pero que tiene que ver el acceso a la tabla desde cualquier lado con el
login de SQL que estes usando (seguridad) a reglas de integridad?

Esta pregunta no tiene sentido.
"Si pero que tiene que ver el acceso a una sp desde cualquier lado
con
el login de SQL que estés usando (seguridad) a reglas de integridad?"

Tu le ves algo de sentido en esa pregunta? yo no!

> Si que está mal! Debe ir con la bbdd y el SGBD es el que debe
> asegurar que se cumpla esa lógica (integridad de datos!).

>> pero si la pones en un SP estas centralizandola.

> y en check o trigger también.

Estasmos hablando de cosas distintas, tu hablas de reglas de integridad y yo
de negocios, las de integridad ya te dije que coincido contigo, pero las de
negocio pueden estar dentro o fuera de la bdd, si estan dentro para hacerlas
podes o usar trigger o Store, si usas trigger haras que las transacciones
duren mas y tengas mas bloqueos, imaginate si por cada factura a grabar hay
que verificar si el cliente tiene saldo deudor y de ser asi no permitir
grabar la factura, si comprobas durante una transaccion (como es el caso del
trigger) tus bloqueos aumentan de forma innecesaria haciendo el sistema mas
lento entre otros tantos problemas

Mas de los mismo: "regla de negocio" = "regla de integridad"

> Toda la estructura es 'reutilizable', etc.

No es cierto, si la consulta la haces desde la aplicacion es mas dificil de
reutilizar, quizas seas muy bueno y la hayas hecho con objetos y puedas
reutilizar ese objeto en si, pero los

Es muchísimo mas flexible y reutilzable justamente por medio de SQL.

Cerrando:

Creo que en muchas cosas estamos hablando de lo mismo pero sin
interpretarnos, cuando yo hable de reglas de negocio no eran las de
integridad y todo lo que tu explicas esta basado en reglas de integirdad lo
cual comparto 100% contigo.

Cuando entiendas que lógica de negocio = integridad de datos
estaremos 100% de acuendo entonces :)

Te mostre las ventajas del uso de Stores,

Ventajas con respecto a qué.
Con respecto a las alternativas que te han dado solo veo desventajas.

te mostre documentos tecnicos de
las empresas mas importantes, bueno mi parte esta terminada aqui, a partir
de este momento puedo pensar algunas cosas

1) No has leido los documentos

No has leido un buen libro de theoria de bases de datos.
Estoy cansado de ver documentos de ese tipo Maxi.

2) No los has interpretado

idem

3) Los has leido y los has interpretado pero a ti no te gustan los Store
Procedures (y estaria muy bien :-)

No es questión de gustos. Es questión de saber cual es su función.
Y su función no es esconder la estructura lógica de los datos para
que no puedan 'verla' las aplicaciones.
Eso no tiene ningún sentido.

Ahora bien, es mejor decir yo no programo con Store porque en mi
arquitectura no me es util a decir que las ventajas que si estan documentas
son falsas,

Las ventajas que tu has 'documentado' aquí son falsas.

son cosas distintas, uno puede hacer su aplicacion como mas le
guste, aplicar una u otra cosa, lo que no puede uno hacer sin fundamentos o
demostraciones es contradecir lo que otro si ha demostrado y escrito, mas si
ese otro es un ente importante o algun referente, podriamos tambien
contradecir a varios matematicos y fisicos con ese criterios, pero para
poder hacerlo (que estaria bueno) seria cuestion de demostrar la otra teoria
:-)

Que se yo, desde lo tecnico esta todo dicho y con documentacion que avala lo
que exprese en todo este enorme hilo, de ahora en mas queda en ti, tu puedes
decirnos a todos que la tierra es cuadrada pero todos cuando vemos fotos,
leemos los libros, etc vemos que es redonda :-)

Pues a esos libros te mandé. Por favor lee Date y trata en
el proceso de desactivar todo lo que tienes aprendido.

Un abrazo y espero verte pronto

Otro abrazo, (ya te había dicho que no íbamos a llegar a acuerdo)
Carlos

Carlos, por mas que no coindicamos en conceptos fue un placer la platica! el
ultimo libro que he lei de diseño de base de datos es este y esta muy bueno
(te lo recomiendo)

http://www.amazon.com/Server-2005-D...ks&qid09168149&sr=1-24

Un abrazo


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Carlos M. Calvelo" escribió en el mensaje de
noticias:

Hola Maxi,

On 26 apr, 00:03, "Maxi Accotto"
wrote:

> Yo no me trago todo lo que leo. Ni voy a darte un link donde puedas
> leer eso. Si quieres me monto yo una página web, lo pongo allí y tu
> lo lees. :)

Yo tampoco me trago todo lo que leo, pero si lo analizo y veo quienes lo
escriben, mis links no son de cualquier paginita, son de empresas como
Microsoft IBM y de personas expertas en bases de datos. Ahora bien no
creo
que tengas el derecho a decir que son cualquier cosa

Por qué no tengo ese derecho? Tu crees posible que haya una remota
posiblidad de que mucha gente escribe de lo que no entiende?

Maxi, a mi muchos 'expertos' me hacen reir. O dependiendo de mi
estado de ánimo, 'casi llorar'.

, quizas no te gusta lo
que dicen pero son referencias importantes, no es Doña Rosa quien lo dice
y
lo publica, son las empresas numero 1 y numero 2 de tecnologia quienes lo
exponen, son los gurues de SQLServer quienes opinan igual. Esta muy bien
no
opinar lo mismo pero las cosas se deben demostrar amigo!

La ideas y 'opiniones' expresadas aquí no son mías. Son el resultado
de muchos años de busqueda y aprendizaje. Yo no me se expresar muy
bien, y por eso se te han dado referencias Maxi.

> No, no me los imagino. No determina la aplicación lo que puede hacer
> un usuario con una tabla sino el SGBD.

Perdona no, pero tu has trabajo en empresas donde tengan el departamento
de
seguridad informatica?

Es las segunda vez que me preguntas eso y es totalmente irrelevante
lo que yo haga o deje de hacer.

Tengo 20+ años de experiencia como desarrollador de software y por
casulidad ahora estoy trabajando para un banco. Y tienen que pagar
bastante por mí que estoy allí por medio de otra (mi) empresa.
Sigue siendo totalmente irrelevante y no demuestra nada.

es cierto que las aplicaciones deben hacer uso de las
tablas pero en si no lo hace la aplicacion sino un login, el que tiene
permisos es un login, y lo que se busca a nivel seguridad informatica en
cualquier empresa seria (Bancos, organismos internaciones, etc) es que a
los
datos no se acceda de cualquier lado, entonces si tu aplicacion usa el
login
X, el X1 y asi por cada usuario, tu le tienes que dar permisos a las
tablas
para poder hacer un select verdad? ahora bien, ese login podria ser usado
fuera de tu sistema por ese usuario y acceder a los datos, no es algo que
cumpla con los standares de seguridad esto en ningun lugar de estos que
te
comente, ahora bien, en los sistemas para la casa de Doña Rosa que tiene
un
SQL y ni DBA o ni gente de sistemas cualquier cosa es lo mismo.

En banco donde yo trabajo ahora no es de la Doña Rosa.
Y hay DBA's por todos los lados.

ME gustaria si tienes otra experiencia que me cuentes en que empresa de
primer nivel a ti te dejan que los usuarios sql puedan desde cualquier
terminal (por ejemplo con un Excel) bajar informacion, insertar datos,
etc.

Te repito que es totalmente irrelevante mi expreriencia.

Ahora bien si tu diseñas la aplicacion con un solo usuario a nivel SQL
entonces estamos en otro problema de seguridad mas grave, pero es
importante
diferenciar una cosa de la otra, si es un solo usuario lo que dije no
tiene
sentido porque la seguridad la terminas controlando a nivel aplicacion,
pero
eso no es un motor de base de datos seguro, no podes hacer auditorias
serias, no podes hacer buenos monitoreos, etc, en fin perdes
funcionalidad
importante que cualquier departamento de seguridad informatica necesida y
que ademas son auditados

Y tu todo eso lo resuelves con SP's.
Vale! Esa es tu experiencia.

Sigue las referencias que se te han dado y deja mi
experiencia o la tuya de lado. No son representativas.

>> >Y no es eso lo mismo que que entre y que pueda hacer
>> >un 'execute insert_proc'?

No, no es lo mismo y te explico porque, suponete que en tu SP de insert
has
definido alguna regla de negocios, si lo hace por medio del SP la regla
de
negocios (leer bien por favor, dije negocios y no integridad) se
ejecutara,
si el usuario hace solo el insert la regla no existe a menos que la
tengas
implementada en un trigger.

Lee tu bien:
'Regla de negocios' es en el contexto de sistemas de
información un termino informal para 'regla de integridad'.

> A mi no me interesa cuantos programadores ni desde cuantas
> aplicaciones hagan ese select. Solo me interesa que sea cual sea la
> forma que tenga el select/insert/update/delete, siempre se cumpla
> con las reglas de integridad.

Eso no esta en discusion amigo, si las reglas de integridad estan en la
base
de datos no problem. Ahora bien, yo aca hablaba de otra cosa, te deberia
en
principio si importar en donde tienes el codigo y que aplicaciones hacen
uso
de cual o tal tabla, es una cuestion de control y para hacer cambios en
la
estructura de base de datos es fundamental

Te recuerdo que la estructura es parte de la interfaz con el resto
del sistema. Me refiero a la estructura del modelo lógico.
Cambiar esa estructura va a tener muchas consencuencias.
Te remito otra vez a la arquitectura ansi-sparc.

Si ademas de que quieras que no importa de donde llamen se cumplan las
reglas de negocio es en donde los Store te dan una mejor mano.

vease arriba 'regla de negocio'

> "Siempre hará lo mismo" no es una ventaja. Y las reglas de integridad
> también se pueden poner sobre la tabla para determinar lo que puede
> hacer con ella. (no ves que andamos en círculos?)

Si las de integirdad si y eso no tiene discusion, pero las de negocio no
a
menos que uses triggers.

'El número de cliente debe ser un 'número' ente 1 y 1000000'
Esto es una regal de integridad. Informalmente se le puede
llama una 'regla de nogocio', pero a mi no me gusta ese
término.

Para esta 'regla de negocio' no me hace falta ningún trigger.

> Ahora cada una de estas dos capas puedes dividirlas en todas las
> capas físicas que tu quieras, pero el 'acceso a datos' pertenece al
> lado del SGBD. En cuanto al business layer (supongo que eso quieres
> decir con 'BI') será para implementar 'business rules'. Este es un
> término que si se analiza bien, lo que realmente significa viene a
> no ser más que 'reglas de integridad de datos'. Esta capa física es
> también responsabilidad del SGBD.

Mmm BL = businnes rules eso en español significa (Regla de negocios y no
regla de datos)

No.. es que tu habías puesto BI, no BL !!

'regla de integidad de datos' Qué problema hay con eso?

Viendo todo tu texto creo que hay confusion entre una regla
de datos o integridad y una regla de negocios.

De eso estoy seguro! Pero ahora creo que ya estará claro no? ;-)

Ejemplos de BL: Para poder vender este producto el cliente no debe
tener
una mora
No se permiten pedidos de clientes que
tengan
deudas
No se puede hacer una venta de un producto
si
no hay en inventario

Eso son reglas de integridad como cualquier otra.

Reglas de integridad: En el campo Fecha solo se admiten valores datetime
El campo edad debe ir desde 1 a 99
En campo de la tabla detalle debe
corresponder con un pk de cabecera.

Estas también.
Y hay quien tanto a estas últimas como la las anteriores les llama
'reglas de nogocios'. Yo prefiero reglas de integridad. Y si todo
el mundo hiciera lo mismo no tendríamos ahora esta discusión.

El acceso a datos no esta dentro del SGBD por eso se llama acceso a datos
DAL (Data Access Layer) es la capa que permite conectarnos con la capa de
datos, el mismo nombre lo indica.

Un SGBD no es un capa de datos. Esta una de las cosas que esta
precisamente encapsula. Para que las aplicaciones puedan conseguir
independencia física de datos. Te remito aquí otra vez al libro de
Date.

> Un select * ... no es un 'acceso a datos'. Es una interfaz de mucho
> mayor nivel de abstracción que cualquier procedimiento (me repito otra
> vez!)

Aca no te entiendo, un select es un acceso a datos,

No no no! Es un programa!! y su 'plan de ejecución' del que tu
tanto sabes es el que a un mucho mas bajo nivel determina como se
accede a los datos.
(independencia física de datos!)

no es ninguna inerfaz,

Si es un interfaz. Es un lenguage para acoplar aplicaciones
de todo tipo con SGBD's

cuando haces un select obtenes datos de la capa de datos, ese select esta
en
la capa de acceso a datos.

Obtienes datos del SGBD, este encapsula la capa de datos.

Esto de las capas UI-BL-DAL-SGBD realmente hace estragos con la gente.

> Por qué insistes en llamarle a eso 'acceso a datos' y a una llamada
> a un procedimiento que es mucho mas limitado y solo hace lo mismo
> para un pequeño número de casos, no le llamas lo mismo?

Si es lo mismo, un EXEC SP es acceso a datos pero por medio de otro
componente, en este caso los Store Procedures y no los objetos directos
de
tu aplicacion.

A este nivel el EXEC SP es lo mismo que un Select (en este aspecto)

> Como bien dices 'por toda query'! El plan es por query, no por SP.
> Porque todo el mundo hable de planes para SP's habrá que seguir
> pensando cada uno por si mismo, y tratar de saber que es lo que se
> está diciendo exactamente.

A ver el SP guarda el plan precompilado amigo, te has leido los libros
online sobre la arquitectura de Store Procedures? te recomiendo una leida
asi ves como funciona.

Si, para el SP podrá guardar el plan que he programado yo. Para
la consultas que yo use en ese plan mío podrá determininar el
SGBD sus planes.

> Pues muy mal por los DTS!

Por tu aplicacion y diseño si no contemplas algunos factores

Mi aplicación no tumba los triggers.

> Y lo puedes poner en un check, o en un trigger. Entonces para eso no
> hace falta denegar acceso a la tabla.

Si pero que tiene que ver el acceso a la tabla desde cualquier lado con
el
login de SQL que estes usando (seguridad) a reglas de integridad?

Esta pregunta no tiene sentido.
"Si pero que tiene que ver el acceso a una sp desde cualquier lado
con
el login de SQL que estés usando (seguridad) a reglas de integridad?"

Tu le ves algo de sentido en esa pregunta? yo no!

> Si que está mal! Debe ir con la bbdd y el SGBD es el que debe
> asegurar que se cumpla esa lógica (integridad de datos!).

>> pero si la pones en un SP estas centralizandola.

> y en check o trigger también.

Estasmos hablando de cosas distintas, tu hablas de reglas de integridad y
yo
de negocios, las de integridad ya te dije que coincido contigo, pero las
de
negocio pueden estar dentro o fuera de la bdd, si estan dentro para
hacerlas
podes o usar trigger o Store, si usas trigger haras que las transacciones
duren mas y tengas mas bloqueos, imaginate si por cada factura a grabar
hay
que verificar si el cliente tiene saldo deudor y de ser asi no permitir
grabar la factura, si comprobas durante una transaccion (como es el caso
del
trigger) tus bloqueos aumentan de forma innecesaria haciendo el sistema
mas
lento entre otros tantos problemas

Mas de los mismo: "regla de negocio" = "regla de integridad"

> Toda la estructura es 'reutilizable', etc.

No es cierto, si la consulta la haces desde la aplicacion es mas dificil
de
reutilizar, quizas seas muy bueno y la hayas hecho con objetos y puedas
reutilizar ese objeto en si, pero los

Es muchísimo mas flexible y reutilzable justamente por medio de SQL.

Cerrando:

Creo que en muchas cosas estamos hablando de lo mismo pero sin
interpretarnos, cuando yo hable de reglas de negocio no eran las de
integridad y todo lo que tu explicas esta basado en reglas de integirdad
lo
cual comparto 100% contigo.

Cuando entiendas que lógica de negocio = integridad de datos
estaremos 100% de acuendo entonces :)

Te mostre las ventajas del uso de Stores,

Ventajas con respecto a qué.
Con respecto a las alternativas que te han dado solo veo desventajas.

te mostre documentos tecnicos de
las empresas mas importantes, bueno mi parte esta terminada aqui, a
partir
de este momento puedo pensar algunas cosas

1) No has leido los documentos

No has leido un buen libro de theoria de bases de datos.
Estoy cansado de ver documentos de ese tipo Maxi.

2) No los has interpretado

idem

3) Los has leido y los has interpretado pero a ti no te gustan los Store
Procedures (y estaria muy bien :-)

No es questión de gustos. Es questión de saber cual es su función.
Y su función no es esconder la estructura lógica de los datos para
que no puedan 'verla' las aplicaciones.
Eso no tiene ningún sentido.

Ahora bien, es mejor decir yo no programo con Store porque en mi
arquitectura no me es util a decir que las ventajas que si estan
documentas
son falsas,

Las ventajas que tu has 'documentado' aquí son falsas.

son cosas distintas, uno puede hacer su aplicacion como mas le
guste, aplicar una u otra cosa, lo que no puede uno hacer sin fundamentos
o
demostraciones es contradecir lo que otro si ha demostrado y escrito, mas
si
ese otro es un ente importante o algun referente, podriamos tambien
contradecir a varios matematicos y fisicos con ese criterios, pero para
poder hacerlo (que estaria bueno) seria cuestion de demostrar la otra
teoria
:-)

Que se yo, desde lo tecnico esta todo dicho y con documentacion que avala
lo
que exprese en todo este enorme hilo, de ahora en mas queda en ti, tu
puedes
decirnos a todos que la tierra es cuadrada pero todos cuando vemos fotos,
leemos los libros, etc vemos que es redonda :-)

Pues a esos libros te mandé. Por favor lee Date y trata en
el proceso de desactivar todo lo que tienes aprendido.

Un abrazo y espero verte pronto

Otro abrazo, (ya te había dicho que no íbamos a llegar a acuerdo)
Carlos

Maxi,

On 26 apr, 02:04, "Maxi Accotto"
wrote:

Carlos, por mas que no coindicamos en conceptos fue un placer la platica! el
ultimo libro que he lei de diseño de base de datos es este y esta muy bueno
(te lo recomiendo)

http://www.amazon.com/Server-2005-D.../dp/159...

Reconozco que tengo que profundizar en el producto (SQL Server),
sobre todo a nivel físico.

Mis reconmendaciones:
http://www.amazon.com/Introduction-...ks&qid09169099&sr=1-2

http://www.amazon.com/Practical-Iss...ks&qid09169162&sr=1-1

http://www.amazon.com/Fundamentals-...ks&qid09169205&sr=1-1
(de este yo tengo la 3a edición)

http://www.amazon.com/Logic-Databas...ks&qid09169245&sr=1-4

http://www.amazon.com/Date-Database...ks&qid09169357&sr=1-1


Y prepárate!!!

http://www.amazon.com/Databases-Typ...ks&qid09169357&sr=1-3

Saludos,
Carlos