Store Procedure ¿ ?

Gracias Juan, pero como he comentado un poco mas arriba, no suelo visitar
estas news y, además, intento no dejarme llevar por 'la corriente', me formo
mi opinión en base a mis experiencias con los demás.
El caso es que tengo algunos sistemas en producción donde la capa de
negocios la mantengo con SP en un 80%, y me resulta cómodo trabajar así. Por
suspuesto, pondré a prueba algunas de las técnicas que se han comentado en
algunos procedimientos no críticos, y si como supongo todo va bien, empezaré
a adoptar otras maneras.

Saludos.

Víctor B.
Desarrollador independiente
"Juan Diego Bueno" escribió en el mensaje
news:

Hola Víctor:

"Victor B." escribió en el mensaje de
noticias:

Pues dame algo de luz al respecto, como ves el tema me interesa bastante.

Víctor B.
Desarrollador independiente
"Alfredo Novoa" escribió en el mensaje
news:1f5qplwrkokts$.11ro41uawdkdg$

Hola Victor

El Tue, 4 Nov 2008 13:12:23 +0100, Victor B. escribió:

Ajá, entonces es seguro que me falta un reciclaje a fondo. En cualquier
caso, no me gustaría pensar que 'las buenas maneras' en programación se
han
perdido. Si hasta hace poco tiempo (relativamente) era casi
deontológico
hacer uso de los SP para lograr mejor perfomance y dotar de cierto
nivel de
seguridad a nuestros sistemas

Según de que escuela vengas. Lo del rendimiento ya ves que se ha
desvanecido y con respecto a la seguridad también hay otras
alternativas.

, mi hábito es tan fuerte como el fumar (que
también lo tengo) y, si bien es cierto que hoy en día las consultas
parametrizadas ya son tan eficaces me pregunto lo siguiente:
Si la capa de negocio la desarrollamos mayormente con SP en en la BBDD,
y no
a nivel de programación con sentencias T-SQL implementadas en el
código, en
un sistema donde la interfaz de usuario es de escritorio, cuando haya
cambios en las reglas, no sería mejor hacer el cambio en los SP
solamente
una vez, que hacer el cambio en el ejecutable y tener que volver a
actualizar todos los terminales?

Si claro, pero se puede hacer aun mejor, en muchos cases se puede
conseguir
lo mismo sin usar SP con menor esfuerzo.


Saludos
Alfredo

Aunque a veces no se les entienda mucho (a mi me cuesta, sinceramente),
ten muy en cuenta la opinión de este par de trolls. Son un poco
tocapelotas (en el buen sentido), pero se aprende mucho de ellos.

Yo solo uso SP's para operaciones muy concretas, pero nada que ver con
trabajo directo sobre las tablas. Desde que les leí, investigué un poco.
Únicamente recurro a vistas, vistas indexadas, triggers "instead of",
funciones de usuario para las checks y preparado de consultas en .NET, y
con esas cinco cosas no he tenido apenas que recurrir a un SP. No al menos
como parece que se propone muchas veces su uso.

Pero eso es sólo mi experiencia...

Un saludo

El Tue, 4 Nov 2008 15:56:10 +0100, Victor B. escribió:

Pues dame algo de luz al respecto, como ves el tema me interesa bastante.

Pues ya te ha contado Juan Diego. Tu diseñas tu base de datos
tranquilamente y cuando haya que hacer cambios siempre puedes hacer que no
afecten a las aplicaciones usando vistas.

Por ejemplo si decides partir una tabla en 2 lo haces creando dos tablas
nuevas y luego borras la tabla antígua y creas una vista con el mismo
nombre que se comporte igual que la tabla antígua.

Si necesitas actualizar vistas no actualizables eso se consigue fácilmente
con triggers instead of, que en realidad son SP, pero que son invisibles
para los usuarios.

También deberías de diseñar las aplicaciones de forma que no rompan por
añadirle nuevos campos a las tablas o las vistas. Cosa que es bastante
fácil.

Los SP están bien para abstraer secuencias de opereraciones de
actualización, pero no deben de usarse para ocultar la estructura
relacional a las aplicaciones por sistema.

Y para entender bien todo esto, el libro que te recomienda Carlos es una
lectura imprescindible.

Ahora probablemente te llegará un correo privado de Maxi si no te ha
llegado ya, diciendo que Carlos y yo (y a lo mejor también Juan Diego)
somos unos troles mundialmente conocidos en todos los grupos y que solo
buscamos confundir a la gente :-)


Saludos

Hola Juan Diego,

El Tue, 4 Nov 2008 21:41:07 +0100, Juan Diego Bueno escribió:

Únicamente recurro a vistas, vistas indexadas, triggers "instead of",
funciones de usuario para las checks

Lo de las funciones de usuario para las "check" es un truco bastante sucio
para rodear las limitaciones de SQL en las restricciones de integridad.

Lo malo es que tiene un alto coste en las inserciones de datos por lotes
:-(, así que hay que tener cuidado con esto.


Saludos

Hola, el uso de SP es un mecanizmo para mejorar:

Seguridad
Reutilizacion de codigo
Performance

Ahora hay quienes no lo usan nunca y quienen lo usan siempre.
Hay tambien otros objetos como las funciones pero no son iguales a los SP

Este es un tema que dara para discutir mucho y no voy a entrar en esa ya que
aparecera el troll de este grupo y no se podra armar algo concreto y serio.

Si le interesa discutir el tema lo invito a que lo hagamos de forma privada
y le cuente en donde le conviene y donde no usar sp.

maxi(punto)accotto(arroba)gmail.com




Saludos
Maxi Accotto
Microsoft MVP en SQLServer
SQltotalconsulting
-

"JNM" escribió en el mensaje de
noticias:

Que tal

E buscado por varios lados pero la verdad aun no me queda claro cuando y
como usar un store procedure, si alguien me puede recomendar algún
documento
o dar una breve explicación de cuando usarlo y para que se usan, ya que
he
visto que muchos los usan para insertar registros, validar información,
consultas para reportes impresos etc.

Gracias

On 5 nov, 18:21, Alfredo Novoa wrote:
Hola Alfredo:

Hola Juan Diego,

El Tue, 4 Nov 2008 21:41:07 +0100, Juan Diego Bueno escribió:

> Únicamente recurro a vistas, vistas indexadas, triggers "instead of",
> funciones de usuario para las checks

Lo de las funciones de usuario para las "check" es un truco bastante sucio
para rodear las limitaciones de SQL en las restricciones de integridad.

Lo malo es que tiene un alto coste en las inserciones de datos por lotes
:-(, así que hay que tener cuidado con esto.

Sí, se que es sucio, pero a mi me vienen de lujo para poder sortear
esas limitaciones, tal como indicas.

En principio, no me han dado guerra en ningún momento, ni siquiera en
inserciones por lotes, las cuales se dan en mi caso, con muy poca
frecuencia.

Supongo que otra opción podría ser "sacar" esas restricciones de la
tabla y chequearlas en la vista que finalmente presento a la
aplicación. Sobre la vista no se va a dar nunca el caso de inserciones
por lotes. Si tengo problemas, supongo que esa podría ser una
solución.

Un saludo